[gstreamer-bugs] [Bug 577963] New: v4l2src doesn't work with yuv420 and a 356x292 resolution

GStreamer (bugzilla.gnome.org) bugzilla-daemon at bugzilla.gnome.org
Sat Apr 4 14:01:05 PDT 2009


If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=577963

  GStreamer | gst-plugins-good | Ver: 0.10.22
           Summary: v4l2src doesn't work with yuv420 and a 356x292
                    resolution
           Product: GStreamer
           Version: 0.10.22
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: erik.andren at gmail.com
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: 2.25/2.26
   GNOME milestone: Unspecified


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:


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=577963.




More information about the Gstreamer-bugs mailing list