v4l2_mbus_framefmt and v4l2_pix_format

v4l2_mbus_framefmt and v4l2_pix_format

[Scott Jiang]

Hi Hans and Laurent,

I got fmt info from a video data source subdev, I thought there should
be a helper function to convert these two format enums.
However, v4l2_fill_pix_format didn't do this, why? Should I do this in
bridge driver one by one?
I think these codes are common use, I prefer adding them in
v4l2_fill_pix_format.

Thanks,
Scott

Re: v4l2_mbus_framefmt and v4l2_pix_format

[Hans Verkuil]

On Wednesday, May 25, 2011 11:56:23 Scott Jiang wrote:
> Hi Hans and Laurent,
> 
> I got fmt info from a video data source subdev, I thought there should
> be a helper function to convert these two format enums.
> However, v4l2_fill_pix_format didn't do this, why? Should I do this in
> bridge driver one by one?
> I think these codes are common use, I prefer adding them in
> v4l2_fill_pix_format.

Only the bridge driver knows how these two enums relate. The mediabus enum
as used by subdevs describes the format of the video data as is transferred
over the physical bus between the subdev and the bridge. The V4L2_PIX_FMT*
formats describe what the video data looks like in memory. Depending on the
DMA engine those may or may not have a simple one on one mapping.

In other words, it is indeed the bridge driver that has to do the mapping.

That said, soc_camera has such a mapping. If it turns out that it can be
reused elsewhere for certain bridges, then that code should probably be
made a generic helper function. (See soc_mediabus.c/h)

Regards,

	Hans

Re: v4l2_mbus_framefmt and v4l2_pix_format

[Guennadi Liakhovetski]

Hi Scott

On Wed, 25 May 2011, Scott Jiang wrote:

> Hi Hans and Laurent,
> 
> I got fmt info from a video data source subdev, I thought there should
> be a helper function to convert these two format enums.
> However, v4l2_fill_pix_format didn't do this, why? Should I do this in
> bridge driver one by one?

Because various camera hosts (bridges) can produce different pixel formats 
in memory from the same mediabus code. However, there is a very common way 
to handle such video data in the bridge: store it in RAM in a "natural" 
way. This mode is called in soc-camera the pass-through mode and there is 
an API to handle this mode in drivers/media/video/soc_mediabus.c. If this 
functionality is considered useful also outside of soc-camera, that API 
can easily be made generic.

> I think these codes are common use, I prefer adding them in
> v4l2_fill_pix_format.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: v4l2_mbus_framefmt and v4l2_pix_format

[Sylwester Nawrocki]

Hi Guennadi,

On 05/25/2011 12:11 PM, Guennadi Liakhovetski wrote:
> Hi Scott
> 
> On Wed, 25 May 2011, Scott Jiang wrote:
> 
>> Hi Hans and Laurent,
>>
>> I got fmt info from a video data source subdev, I thought there should
>> be a helper function to convert these two format enums.
>> However, v4l2_fill_pix_format didn't do this, why? Should I do this in
>> bridge driver one by one?
> 
> Because various camera hosts (bridges) can produce different pixel formats 
> in memory from the same mediabus code. However, there is a very common way 
> to handle such video data in the bridge: store it in RAM in a "natural" 
> way. This mode is called in soc-camera the pass-through mode and there is 
> an API to handle this mode in drivers/media/video/soc_mediabus.c. If this 

Sorry about getting off the topic a bit.

As some media bus formats require different conversion process in the bridge
to obtain specific format in memory (fourcc) I was wondering whether it would
be reasonable to indicate the "natural" fourccs for the applications when
enumerating formats supported by the bridge/DMA with VIDIOC_ENUM_FMT?
So applications are aware what are the "natural" formats and which require
lossy conversion. And in this way could choose formats that yield better
quality. 

Now there are following flags available for struct v4l2_fmtdesc::flags

V4L2_FMT_FLAG_COMPRESSED
V4L2_FMT_FLAG_EMULATED

I thought about something like V4L2_FMT_HW_EMULATED or V4L2_FMT_FLAG_LOW_QUALITY.

I not happy with those exact names but I hope that gives a basic idea what
I am talking about.  
Possibly I am missing other ways to achieve the same.

Regards,
-- 
Sylwester Nawrocki
Samsung Poland R&D Center

Re: v4l2_mbus_framefmt and v4l2_pix_format

[Guennadi Liakhovetski]

On Wed, 25 May 2011, Sylwester Nawrocki wrote:

> Hi Guennadi,
> 
> On 05/25/2011 12:11 PM, Guennadi Liakhovetski wrote:
> > Hi Scott
> > 
> > On Wed, 25 May 2011, Scott Jiang wrote:
> > 
> >> Hi Hans and Laurent,
> >>
> >> I got fmt info from a video data source subdev, I thought there should
> >> be a helper function to convert these two format enums.
> >> However, v4l2_fill_pix_format didn't do this, why? Should I do this in
> >> bridge driver one by one?
> > 
> > Because various camera hosts (bridges) can produce different pixel formats 
> > in memory from the same mediabus code. However, there is a very common way 
> > to handle such video data in the bridge: store it in RAM in a "natural" 
> > way. This mode is called in soc-camera the pass-through mode and there is 
> > an API to handle this mode in drivers/media/video/soc_mediabus.c. If this 
> 
> Sorry about getting off the topic a bit.
> 
> As some media bus formats require different conversion process in the bridge
> to obtain specific format in memory (fourcc) I was wondering whether it would
> be reasonable to indicate the "natural" fourccs for the applications when
> enumerating formats supported by the bridge/DMA with VIDIOC_ENUM_FMT?
> So applications are aware what are the "natural" formats and which require
> lossy conversion. And in this way could choose formats that yield better
> quality. 

Yes, in principle this seems like a good idea to me. Of course, somebody 
will have to teach the user-space to use this information:)

> Now there are following flags available for struct v4l2_fmtdesc::flags
> 
> V4L2_FMT_FLAG_COMPRESSED
> V4L2_FMT_FLAG_EMULATED
> 
> I thought about something like V4L2_FMT_HW_EMULATED or V4L2_FMT_FLAG_LOW_QUALITY.
> 
> I not happy with those exact names but I hope that gives a basic idea what
> I am talking about.  
> Possibly I am missing other ways to achieve the same.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/