On Sun, 2010-05-30 at 13:34 +0200, Jean-Francois Moine wrote: > On Sat, 29 May 2010 21:32:07 +0200 > Ondrej Zary <linux@xxxxxxxxxxxxxxxxxxxx> wrote: > > > The Color Space/Compression reported by the driver is only one: RGB 24 > > The driver also uses these files which may (or may not) be related to > > used compression: iyuv_32.dll, msh263.drv, msyuv.dll, tsbyuv.dll > > In standalone mode, the camera records video in MJPEG format. > > Hello Ondrej, > > Bad news, the images are compressed by an unknown algorithm (unknown > from Linux point of vue). The decompression function could be found in > some part of the ms-win driver, but: > - first, I have no time to search and disassemble this function, > - then, I did have this problem with an other webcam (17a1:0118), and > after searching for a long time, nobody could find the function, and > the driver is in stand-by since 2 years, > - eventually, is this legal? > > All I can do is to code the driver and let you or anyone find the > decompression function... I ran into this with my daughetr's cheap little Sakar webcam based on a Jeilin chip. After some investigation about the chip and learning it being only able to perform JPEG compression, it was rather easy to figure out it was just sending MJPEG data with the headers stripped off. This thread from last year tells most of the story http://www.mail-archive.com/linux-media@xxxxxxxxxxxxxxx/msg06766.html (Many thanks to Theodore for doing the legwork on experiments and a new GSPCA driver - jeilinj) Since your camera records MJPEG in stand-alone mode (mine recorded MJPEG in an AVI container in stand-alone mode), it stands to reason, your camera may be doing the same sort of thing. The payload of MJPEG data will look very random since the compressed data is Huffman (entropy) encoded in the final step of encoding. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
