You're right. It was my fault. However, I saw that format empirically (aka
reverse engineering) from the results of YOUR driver :-) when an
application requests a hardware unsupported format (like a 730/740 philips
webcam under a kernel 2.4.5 requested to deliver CIF or QCIF, while it, in
fact delivers a mixed up SIF or QSIF format).
I wrote down some quick and dirty conversion routines for openh323 stack
and I may tell you that the format is really ugly:
If the application requests QCIF, the driver, rather than failing, it says
it can deliver that format, but it instead delivers a padded/trimmed
format like this:
uuyyyyuuyyyy
vvyyyyvvyyyy
If the application requests CIF, the driver delivers:
yyuuyyyyuuyyyy
yyvvyyyyvvyyyy
If you want I may send you the application (pwlib/openh323/ohphone), my
conversion routines and my philips ToUcam Fun camera (just kidding about
the latter :-)
Regards,
Flavio.
> Stop! You�re mixing two things up: first, packed v.s. planar; I would
> rather call it interlaced v.s. planar. Second, the YYYY bytes go first,
> then
> UU and VV. I�ve never seen _any_ format that puts the chroma values
> first...
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
