Nothing changed in the way we handle the webcam between Intrepid and Jaunty.
It is more likely that something changed in your webcam driver.

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.

Created attachment 134798 [details]
libv4l log

Created attachment 134799 [details]
gstreamer log

a decent workaround is to not use "v4l2src ! ..." but "v4l2src ! videoscale ! ..."

not sure, why that works though...

I've checked the specific conversion routine and I can confirm that there is a bug in libv4l there, I will make a patched version available later today. This will not solve the unneeded conversion problem, but that is minor compared to the fsck-ed up colors problem.

I have some ideas for the unneeded conversion problem too, but that will take more time.

fyi: the last working version was libv4l-0.5.7

Why do we let libv4l* do any colourspace conversion at all again? Because ffmpegcolorspace doesn't handle bayer? Any other reasons?
 

(In reply to comment #8)
> Why do we let libv4l* do any colourspace conversion at all again? Because
> ffmpegcolorspace doesn't handle bayer? Any other reasons?
> 
> 

Because there is nothing else which can handle:
V4L2_PIX_FMT_SN9C10X  v4l2_fourcc('S', '9', '1', '0') /* SN9C10x compression */
V4L2_PIX_FMT_SPCA501  v4l2_fourcc('S', '5', '0', '1') /* YUYV per line */  
V4L2_PIX_FMT_SPCA505  v4l2_fourcc('S', '5', '0', '5') /* YYUV per line */  
V4L2_PIX_FMT_SPCA508  v4l2_fourcc('S', '5', '0', '8') /* YUVY per line */  
V4L2_PIX_FMT_SPCA561  v4l2_fourcc('S', '5', '6', '1') /* compressed GBRG bayer 
V4L2_PIX_FMT_PAC207   v4l2_fourcc('P', '2', '0', '7') /* compressed BGGR bayer 
V4L2_PIX_FMT_MR97310A v4l2_fourcc('M', '3', '1', '0') /* compressed BGGR bayer 
V4L2_PIX_FMT_SQ905C   v4l2_fourcc('9', '0', '5', 'C') /* compressed RGGB bayer 
V4L2_PIX_FMT_PJPG     v4l2_fourcc('P', 'J', 'P', 'G') /* Pixart 73xx JPEG */   
V4L2_PIX_FMT_HM12     v4l2_fourcc('H', 'M', '1', '2') /*  8  YUV 4:2:0 16x16 mac
V4L2_PIX_FMT_SN9C20X_I420 v4l2_fourcc('S', '9', '2', '0') /* sn9c20xcompression

And indeed 4 variants of raw bayer too.

And as we add support for more video grabbing devices the list grows and grows,
so handling this in a single video4linux specific library and then making other
stuff use that, makes perfect sense. I agree we need to extend the API, so
that gstreamer can differentiate between real and emulated formats. And in
cases like this specific one can then prefer a real format over an emulated
one.

Here is a fixed version of libv4l, which hopefully fixes the messed up colors:

Glenn, can you please give this version a try please ? :
http://people.atrpms.net/~hdegoede/libv4l-0.5.98test.tar.gz

Here are simple installation instructions

Preparation:
1. Download it
2. Check if your current version is installed as
   /usr/lib/libv4l2.so.0
   or:
   /usr/lib64/libv4l2.so.0

Install:
tar xvfz libv4l-0.5.98test.tar.gz
cd libv4l-0.5.97
make

And then depending on wether you have it in lib or lib64 do:
make install PREFIX=/usr LIBDIR=/usr/lib
or:
make install PREFIX=/usr LIBDIR=/usr/lib64

After this try using cheese again and hopefully things are fixed now.

i can confirm that it works now on my macbook with the isight. thanks hans!

*** Bug 583022 has been marked as a duplicate of this bug. ***

Ok, looks to me like we can close this as NOTGNOME, correct? If not, please re-open.

Open action items for libv4l:

 - provide API to differentiate between emulated
   and native formats? (please file new bug once
   that exists)

 - would be nice if there was a .pc file for
   libv4l, so we can require a specific minimum
   version

(In reply to comment #13)
> Ok, looks to me like we can close this as NOTGNOME, correct? If not, please
> re-open.
> 
> Open action items for libv4l:
> 
>  - provide API to differentiate between emulated
>    and native formats? (please file new bug once
>    that exists)
> 

Since libv4l essentially mimicks the raw v4l2 /dev/video# API I need to coordinate this with upstream I'll put this on my todo list.

>  - would be nice if there was a .pc file for
>    libv4l, so we can require a specific minimum
>    version
> 

There already is a .pc file for libv4l, depending on the API you are using you want to check for either libv4l2 or libv4l1

(In reply to comment #13)
> Ok, looks to me like we can close this as NOTGNOME, correct? If not, please
> re-open.
> 
> Open action items for libv4l:
> 
>  - provide API to differentiate between emulated
>    and native formats? (please file new bug once
>    that exists)
> 

Done, the new libv4l-0.6.1 release (made minutes ago) now has an API for this:
http://linuxtv.org/hg/~hgoede/libv4l/rev/38927bb366e0
http://linuxtv.org/hg/~hgoede/gspca/rev/58a65a9e65af