On 07/27/2014 06:53 PM, Nicolas Dufresne wrote: > > Le Samedi 26 Juillet 2014 12:37 EDT, Philipp Zabel <philipp.zabel@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
