[gstreamer-bugs] [Bug 571772] Possible issue with v4l2src and libv4l different way of ordering formats

[GStreamer (bugzilla.gnome.org)]

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=571772

  GStreamer | gst-plugins-good | Ver: 0.10.22

Filippo Argiolas changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwrdegoede at fedoraproject.org
         AssignedTo|cheese-maint at gnome.bugs     |gstreamer-
                   |                            |bugs at lists.sourceforge.net
           Severity|normal                      |critical
             Status|UNCONFIRMED                 |NEEDINFO
          Component|general                     |gst-plugins-good
           Priority|Normal                      |High
            Product|cheese                      |GStreamer
          QAContact|cheese-maint at gnome.bugs     |gstreamer-
                   |                            |bugs at lists.sourceforge.net
            Summary|Cheese does not show proper |Possible issue with v4l2src
                   |colors or luminosity        |and libv4l different way of
                   |                            |ordering formats
   Target Milestone|2.24                        |HEAD
            Version|2.25.x                      |0.10.22




------- Comment #2 from Filippo Argiolas  2009-05-17 07:45 UTC -------
Daniel, I think this is the very same issue as yours. Did you contact Hans
about it?

Just to summarize our findings:
The issue happens when libv4l converts UYVY, the native webcam format, to YV12.
It is likely some issue in libv4l conversion code, but it's triggered by a more
tricky issue related to the intimate way gstreamer caps negotiation works:

- libv4l reports a list of supported formats to gstreamer that contains the
actual formats supported by the device plus each format it can handle through a
conversion.

- as far as I can tell that list is ordered with the actual supported formats
on top so that the application can pick just the first reported format and no
conversion will happen

- gstreamer sees this as the list of formats supported by the webcam with no
particular precedence or meaning in its order.

- it reorders the list with its own rules needed for the way caps
negatiotion/fixation works

- with this reordering YV12 is prioritized agains UYVY so that's the format
v4l2src asks to libv4l

- the result is that we have a redundant UYVY->YV12 conversion even if it's not
really needed since we could have just requested the native UYVY format

Hans can you confirm my findings?
IMHO the easiest way to fix this particular issue would be to fix the
UYVY->YV12 conversion code in libv4l (assuming it's actually bugged).

Reassigning to gstreamer so that we can get some feedback there too.


-- 
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=571772.