GNOME Bugzilla – Bug 663580
v4l2src negotiation failure with weird pixel-aspect-ratios
Last modified: 2011-11-14 12:41:01 UTC
Created attachment 200912 [details] [review] proposed patch The following pipeline fails: gst-launch-0.10 v4l2src ! video/x-raw-yuv,width=320,height=240,pixel-aspect-ratio=[1/2147483647, 2147483647/1 ] ! xvimagesink v4l2src tries to fixate the pixel-aspect-ratio to 1/2147483647, which xvimagesink is rightfully unhappy with. v4l2src doesn't support any non-square pixel-aspect-ratios (or at least determining this is the case), so it should exposes 1/1 in its caps
v4l2 actually has an API for non-square pixels. See the VIDIOC_CROPCAP ioctl, especially the pixelaspect member of struct v4l2_cropcap. That said, the UVC driver doesn't properly expose it (even though the UVC spec also exposes the pixel aspect ratio).
Yes, a more complete fix was to add support for that. But as it it's not supported i opted for doing the simple fix now and stop my pipelines from exploding ;)
The patch fixed the problem for me.
Discussed with Wim, seems the best solution for now (until we get the info from v4l) This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
commit e7ae593993af5dcc4b7c46dee25aae23c63864ce Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk> Date: Mon Nov 7 18:43:26 2011 +0000 v4l2: Set pixel-aspect-ratio to 1/1 We don't currently support setting the pixel-aspect-ratio from V4L2. So simply set it to be 1/1 in the caps to prevent negotiation failures when fixating to weird values (e.g. when the downstream caps has pixel-aspect-ratio = [ MIN, MAX ] ) https://bugzilla.gnome.org/show_bug.cgi?id=663580