Re: [PATCH 2/3] [media] coda: fix coda_g_selection

[Hans Verkuil <hverkuil@xs4all.nl>]

On 07/27/2014 06:53 PM, Nicolas Dufresne wrote:
>  
> Le Samedi 26 Juillet 2014 12:37 EDT, Philipp Zabel <philipp.zabel@gmail.com> a écrit: 
> 
>> I have tried the GStreamer v4l2videodec element with the coda driver and
>> noticed that GStreamer calls VIDIOC_CROPCAP to obtain the pixel aspect
>> ratio. This always fails with -EINVAL because of this issue. Currently GStreamer
>> throws a warning if the return value is an error other than -ENOTTY.
> 
> But for now, this seems like a fair thing to do. We currently assume that if your
> driver is not implementing CROPCAP, then pixel aspect ratio at output will be
> unchanged at capture. If there is an error though, it's not good sign, and we report
> it. If that is wrong, let us know why and how to detect your driver error isn't a an error.

If cropcap returns -EINVAL then that means that the current input or output does
not support cropping (for input) or composing (for output). In that case the
pixel aspect ratio is undefined and you have no way to get hold of that information,
which is a bug in the V4L2 API.

In the case of an m2m device you can safely assume that whatever the pixel aspect
is of the image you give to the m2m device, it will still be the same pixel
aspect when you get it back. In fact, I would say that if an m2m device returns
cropcap information, then the pixel aspect ratio information is most likely not
applicable to the device and will typically be 1:1.

Pixel aspect ratio is only relevant if the video comes in or goes out to a physical
interface (sensor, video receiver/transmitter).

Regards,

	Hans