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 <linux@xxxxxxxxxxxxxxxxxxxx> 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:
kilgota@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.
kilgota@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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
