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