GNOME Bugzilla – Bug 577963
[v4l2src] broken image if rowstrides are not as expected by GStreamer
Last modified: 2009-08-10 23:12:46 UTC
Please describe the problem: I'm developing a driver for stv06xx based webcams (Quickcam Web, Dexxa Webcam, Quickcam Express etc.) Some of these webcams contain a vv6410 sensor producing a raw bayer image with a 356x292 resolution. As the camera only supports bayer natively the libv4l [1] library is used to convert the format to rgb or yuv. RGB works fine but I'm having trouble to get yuv conversion working together with gstreamer. This is due to that the U V plane widths are rounded up by 8 in gstv4l2src.c libv4l delivers 356*292+(356*292/2) = 155928 byte frames but gstreamer expects 356+292+(360*292/2) = 156512 byte frames and thus bails out. If I've understood things correctly, gstreamer expects us to pad each line with two bytes, but the v4l2 standard [2] says that the driver may choose to ignore padding and this is as of current not honoured by gstreamer. I've hacked gstv4l2src.c to only round up by 4 but I still get an corrupt image. My take is that the rounding by 8 is presumed elsewhere in the gstreamer stack. Other yuv420 consuming applications (skype for instance) work correctly and doesn't expect this alignment. My questions are as following: 1. Why is the rounding by 8 taking place? Is this defined somewhere in yuv420 specification? 2. How do we resolve this issue? AFAICS the gstreamer stack is currently violating the specs as it expects the padding. Would this be easy to fix? [1] http://hansdegoede.livejournal.com/3636.html [2] http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec/c2030.htm#V4L2-PIX-FORMAT Steps to reproduce: 1. Run the following command from the commandline: gst-launch-0.10 v4l2src queue-size=4 ! ffmpegcolorspace ! xvimagesink Actual results: Gstreamer fails to produce an image Expected results: Normal usage Does this happen every time? Yes Other information:
Ping? Any pointers on who is maintaining this code?
The strides and plane offsets for the various formats are implicit and are as expected by X. GStreamer currently doesn't support any other strides than the implied ones, so v4l*src would need to memcpy the data into a buffer with the expected strides if the driver delivers other strides than the ones we expect. You can query the strides and offsets programmatically using http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-gstvideo.html#gst-video-format-get-row-stride etc.
Issue worked around in current libv4l.