On Sun, 30 May 2010, Andy Walls wrote:

> On Sun, 2010-05-30 at 20:13 +0200, Jean-Francois Moine wrote:
> > On Sun, 30 May 2010 19:55:22 +0200
> > Ondrej Zary <li...@rainbow-software.org> wrote:
> > 
> > > That's bad...
> > > 
> > > The driver contains file sp5x_32.dll which is registered in
> > > system.ini file as [drivers32]
> > > VIDC.SP54=SP5X_32.DLL
> > > 
> > > Seems that the codec is called SP54 - hope that it's used to
> > > decompress the data.
> > > 
> > > > All I can do is to code the driver and let you or anyone find the
> > > > decompression function...
> > > 
> > > Maybe we can dump some data, create AVI file from that and try to
> > > decode the file using that codec.
> > 
> > It is easy to get images from the usbsnoop files. I join an image
> > extracted from your file usbsnoop-video-capture-640x480.log. If you
> > want more images, they are in IsoPackets. The first 2 bytes of each isoc
> > packet mean:
> > - '02 80' or '02 81': first of intermediate part of the image ('0' or
> >   '1' is the image sequence number)
> > - '02 82' or '02 83': last part of the image
> > 
> > Someone had an idea to try and guess the compression algorithm: do
> > usbsnoop's with full black and full white images. But this idea did not
> > work with the other webcam: the images were quite the same!
> 
> I have attached an image I constructed from the image data file you
> provided, the MJPEG headers in the AVI file Ondrej provided, and the
> Huffman table in the jpeg.h file in the gspca driver.
> 
> If you zoom in, there is an small pattern in the top left portion of the
> scan.
> 
> I doesn't look quite like an whole image, but it does look like the
> start of one.
> 
> Regards,
> Andy

Downloaded it. And, hmmm. Here are the error messages on trying to look at 
the output:

kilg...@khayyam:~$ display test1.jpg
display: Corrupt JPEG data: premature end of data segment `test1.jpg' @ 
warning/jpeg.c/EmitMessage/228.
display: Unsupported marker type 0x3a `test1.jpg' @ 
error/jpeg.c/EmitMessage/233.
kilg...@khayyam:~$ 

Quite possibly it _is_ going down "strips" or such. That is what the 
JL2005C cameras are doing. Each vertical strip of 16 bytes from the 
picture is in fact a separate JPEG image, and needs to be separately 
processed, and then the results glued together into an image. This is even 
seen in the raw data, once one is so wise that it is all figured out. The 
data for each strip ends with FF D9. So one suggestion here would be to 
see how many times the FF D9 is coming up in the data. There may be a 
pattern to that.

Theodore Kilgore
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to