SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Ondrej Zary]

Hello,
I got a MD80-clone camera based on SPCA1527A chip. It's webcam-like camera
with battery and microSD slot and can record video on its own. It has two USB
modes - mass storage (USB ID 04fc:0171) and webcam mode (USB ID 04fc:1528).
This chip seems to be used in many other SD card cameras too.

The webcam mode is not supported by gspca so I captured some data to
(hopefully) make support in gspca possible. There seems to be 3 interfaces:

# lsusb -v -d 04fc:1528

Bus 001 Device 003: ID 04fc:1528 Sunplus Technology Co., Ltd
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x04fc Sunplus Technology Co., Ltd
idProduct 0x1528
bcdDevice 1.00
iManufacturer 1 Sunplus Co Ltd
iProduct 2 General Image Devic
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 183
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0080 1x 128 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 2
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0180 1x 384 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 3
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 4
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0280 1x 640 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 5
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0300 1x 768 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 6
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0380 1x 896 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 7
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x03ff 1x 1023 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
interface 0: SPCA1528 Video Interrupt Device (no driver used)
interface 1: SPCA1528 Video Camera Device (ca1528av.sys, dext1528.ax,
sp5x_32.dll)
interface 2: SPCA1528 Still Camera Device (bulk1528.sys)

The camera does not seem to support audio in webcam mode.

Interface 0 seems to be useless and there's no application to test interface 2
(still camera) so the only interesting interface seems to be interface 1.


Some SniffUSB logs are here:
http://www.rainbow-software.org/linux_files/spca1528/

usbsnoop-composite.log - composite device plug&unplug

usbsnoop-still.log - interface 2 plug&unplug

usbsnoop-video-capture-320x240.log - interface 1 plug, capture of about 1
second video at 320x240, unplug

usbsnoop-video-plug.log - interface 1 plug&unplug

[Jean-Francois Moine]

On Sat, 29 May 2010 19:09:32 +0200

Post by Ondrej Zary
I got a MD80-clone camera based on SPCA1527A chip. It's webcam-like
camera with battery and microSD slot and can record video on its own.
It has two USB modes - mass storage (USB ID 04fc:0171) and webcam
mode (USB ID 04fc:1528). This chip seems to be used in many other SD
card cameras too.
=20
The webcam mode is not supported by gspca so I captured some data to=20

Hello Ondrej,

I got your ms-win traces, thank you. The commands seem simple enough,
but I don't know yet the compression algorithm of the images. I will
have a look at this on next week. May you tell me if there are other
resolutions than 320x240 and, also, what are the webcam controls?

Best regards.

--=20
Ken ar c'henta=C3=B1 | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/

[Ondrej Zary]

Post by Jean-Francois Moine
On Sat, 29 May 2010 19:09:32 +0200

Post by Ondrej Zary
I got a MD80-clone camera based on SPCA1527A chip. It's webcam-like
camera with battery and microSD slot and can record video on its own.
It has two USB modes - mass storage (USB ID 04fc:0171) and webcam
mode (USB ID 04fc:1528). This chip seems to be used in many other SD
card cameras too.
The webcam mode is not supported by gspca so I captured some data to

Hello Ondrej,
I got your ms-win traces, thank you. The commands seem simple enough,
but I don't know yet the compression algorithm of the images. I will
have a look at this on next week. May you tell me if there are other
resolutions than 320x240 and, also, what are the webcam controls?

The supported resolutions are:
160x120
176x144
320x240
352x288
640x480

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.


Controls:
Banding Filter - 50Hz/60Hz - bandwidth 3/4/5/6/7 (default=50Hz, 3)
Brightness - 0..255 (default=128)
Contrast - 1..8 (default=1)
Saturation - 0..8 (default=1)
Sharpness - 0..255 (default=0)
Hue - 0..360 (default=0)

I added some more logs to
http://www.rainbow-software.org/linux_files/spca1528/

different resolutions (with default control settings):
usbsnoop-video-capture-160x120.log
usbsnoop-video-capture-176x144.log
usbsnoop-video-capture-352x288.log
usbsnoop-video-capture-640x480.log

160x120 with one control changed (other are at default values):
usbsnoop-controls-brightness-226.log
usbsnoop-controls-brightness-43.log
usbsnoop-controls-contrast-5.log
usbsnoop-controls-hue-91.log
usbsnoop-controls-saturation-4.log
usbsnoop-controls-sharpness-145.log

opening controls window with no capture running:
usbsnoop-open-controls.log

[Jean-Francois Moine]

On Sat, 29 May 2010 21:32:07 +0200

The Color Space/Compression reported by the driver is only one: RGB 2=

4

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

Best regards.

--=20
Ken ar c'henta=C3=B1 | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/

[Ondrej Zary]

Post by Jean-Francois Moine
On Sat, 29 May 2010 21:32:07 +0200

Post by Ondrej Zary
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
- 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?

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.

Post by Jean-Francois Moine
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.

[Jean-Francois Moine]

On Sun, 30 May 2010 19:55:22 +0200

Post by Ondrej Zary
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.

Post by Jean-Francois Moine
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!

[Andy Walls]

Post by Jean-Francois Moine
On Sun, 30 May 2010 19:55:22 +0200

Post by Ondrej Zary
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.

Post by Jean-Francois Moine
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
- '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

[Theodore Kilgore]

Post by Andy Walls

Post by Jean-Francois Moine
On Sun, 30 May 2010 19:55:22 +0200

Post by Ondrej Zary
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.

Post by Jean-Francois Moine
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
- '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:

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

[Andy Walls]

Post by Ondrej Zary

Post by Jean-Francois Moine
On Sat, 29 May 2010 21:32:07 +0200

Post by Ondrej Zary
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
- 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?

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.

Post by Jean-Francois Moine
All I can do is to code the driver and let you or anyone find the
decompression function...

SP54 is Sunplus' ( http://www.sunplus.com.tw/ ) FourCC code for a
version of MJPEG with the headers removed according to

http://www.fourcc.org/

Post by Ondrej Zary
Maybe we can dump some data, create AVI file from that and try to decode the
file using that codec.

FourCC.org points to this page:

http://libland.fr.st/download.html

which points to a utility to conver the data back into an MJPEG:

http://mxhaard.free.fr/spca50x/Download/sp54convert.tar.gz


I have no idea if any of the above is true, 'cause I read it on the
Internet. ;)

Regards,
Andy

[Ondrej Zary]

Post by Andy Walls

Post by Ondrej Zary

Post by Jean-Francois Moine
On Sat, 29 May 2010 21:32:07 +0200

Post by Ondrej Zary
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
- 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?

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.

Post by Jean-Francois Moine
All I can do is to code the driver and let you or anyone find the
decompression function...

SP54 is Sunplus' ( http://www.sunplus.com.tw/ ) FourCC code for a
version of MJPEG with the headers removed according to
http://www.fourcc.org/

Post by Ondrej Zary
Maybe we can dump some data, create AVI file from that and try to decode
the file using that codec.

http://libland.fr.st/download.html
http://mxhaard.free.fr/spca50x/Download/sp54convert.tar.gz
I have no idea if any of the above is true, 'cause I read it on the
Internet. ;)

Modified that utility to work on raw video frame extracted from usbsnoop file.
The bad news is that the resulting jpeg file is not readable.

I also deleted the sp5x_32.dll file and the camera still works...

[Andy Walls]

Post by Ondrej Zary

Post by Andy Walls
SP54 is Sunplus' ( http://www.sunplus.com.tw/ ) FourCC code for a
version of MJPEG with the headers removed according to
http://www.fourcc.org/

Post by Ondrej Zary
Maybe we can dump some data, create AVI file from that and try to decode
the file using that codec.

http://libland.fr.st/download.html
http://mxhaard.free.fr/spca50x/Download/sp54convert.tar.gz
I have no idea if any of the above is true, 'cause I read it on the
Internet. ;)

Modified that utility to work on raw video frame extracted from usbsnoop file.
The bad news is that the resulting jpeg file is not readable.
I also deleted the sp5x_32.dll file and the camera still works...

I would try extracting a JPEG header from one of the files captured by
the camera in stand alone mode (either a JPEG still or MJPEG file), and
put that header together with the image data from the USB capture. It
may not look perfect, but hopefully you will get something you
recognize.

Attached was Theodore's first attempt of such a procedure with a header
extracted from a standalone image file from my Jeilin based camera and
USB snoop data from the same camera. It wasn't perfect, but it was
recognizable.


I did look at the image data file Jean-Francois provided from your
usbsnoop logs. To my eye the data looks like it is Huffman coded
(indicating JPEG). Maybe I'm just seeing what I want to see.


Regards,
Andy

[Ondrej Zary]

Post by Andy Walls

Post by Ondrej Zary

Post by Andy Walls
SP54 is Sunplus' ( http://www.sunplus.com.tw/ ) FourCC code for a
version of MJPEG with the headers removed according to
http://www.fourcc.org/

Post by Ondrej Zary
Maybe we can dump some data, create AVI file from that and try to
decode the file using that codec.

http://libland.fr.st/download.html
http://mxhaard.free.fr/spca50x/Download/sp54convert.tar.gz
I have no idea if any of the above is true, 'cause I read it on the
Internet. ;)

Modified that utility to work on raw video frame extracted from usbsnoop
file. The bad news is that the resulting jpeg file is not readable.
I also deleted the sp5x_32.dll file and the camera still works...

I would try extracting a JPEG header from one of the files captured by
the camera in stand alone mode (either a JPEG still or MJPEG file), and
put that header together with the image data from the USB capture. It
may not look perfect, but hopefully you will get something you
recognize.

Just thought about the same thing so I uploaded a video file:
http://www.rainbow-software.org/linux_files/spca1528/sunp0003.avi

Post by Andy Walls
Attached was Theodore's first attempt of such a procedure with a header
extracted from a standalone image file from my Jeilin based camera and
USB snoop data from the same camera. It wasn't perfect, but it was
recognizable.

Thanks, I'll try that tomorrow.

Post by Andy Walls
I did look at the image data file Jean-Francois provided from your
usbsnoop logs. To my eye the data looks like it is Huffman coded
(indicating JPEG). Maybe I'm just seeing what I want to see.
Regards,
Andy

[Theodore Kilgore]

Post by Ondrej Zary

Post by Andy Walls

Post by Ondrej Zary

Post by Andy Walls
SP54 is Sunplus' ( http://www.sunplus.com.tw/ ) FourCC code for a
version of MJPEG with the headers removed according to
http://www.fourcc.org/

Post by Ondrej Zary
Maybe we can dump some data, create AVI file from that and try to
decode the file using that codec.

http://libland.fr.st/download.html
http://mxhaard.free.fr/spca50x/Download/sp54convert.tar.gz
I have no idea if any of the above is true, 'cause I read it on the
Internet. ;)

Modified that utility to work on raw video frame extracted from usbsnoop
file. The bad news is that the resulting jpeg file is not readable.
I also deleted the sp5x_32.dll file and the camera still works...

I would try extracting a JPEG header from one of the files captured by
the camera in stand alone mode (either a JPEG still or MJPEG file), and
put that header together with the image data from the USB capture. It
may not look perfect, but hopefully you will get something you
recognize.

http://www.rainbow-software.org/linux_files/spca1528/sunp0003.avi

Post by Andy Walls
Attached was Theodore's first attempt of such a procedure with a header
extracted from a standalone image file from my Jeilin based camera and
USB snoop data from the same camera. It wasn't perfect, but it was
recognizable.

Thanks, I'll try that tomorrow.

Post by Andy Walls
I did look at the image data file Jean-Francois provided from your
usbsnoop logs. To my eye the data looks like it is Huffman coded
(indicating JPEG). Maybe I'm just seeing what I want to see.

Naturally, it makes me feel all excited to see my name in print. If anyone
likes, you can send me the following:

-- usbsniff output for one or two frames (it isn't so difficult
for me to convert this to a binary file, actually) and I can fool around
with trying to stick a JPEG header on it.

-- one or two results of svv -gr in case that there is so much
progress already. But the previous item ought to do just fine, too.

I could also comment that there could be some kind of obfuscated JPEG
going on here. As a case in point I can mention the recently cracked
decompression for the JL2005B/C/D based still cameras. The compression
algorithm is pretty much standard JPEG, but two things are unusual. First,
the compression or decompression proceeds down columns of width one block,
not across rows. Second, the thing which is being compressed is the Bayer
pattern, so each block is of width 16, not 8, and there are sub-blocks for
each of R, G1, G2, and B.

If anyone is curious about this, the code can be pulled down from
gphoto.svn.sourceforge.net, in trunk/libgphoto2/camlibs/jl2005c.

Theodore Kilgore

[Jean-Francois Moine]

On Mon, 31 May 2010 00:03:10 +0200

Post by Ondrej Zary

Post by Andy Walls
I would try extracting a JPEG header from one of the files captured
by the camera in stand alone mode (either a JPEG still or MJPEG
file), and put that header together with the image data from the
USB capture. It may not look perfect, but hopefully you will get
something you recognize.

http://www.rainbow-software.org/linux_files/spca1528/sunp0003.avi

Post by Andy Walls
Attached was Theodore's first attempt of such a procedure with a
header extracted from a standalone image file from my Jeilin based
camera and USB snoop data from the same camera. It wasn't perfect,
but it was recognizable.

I could not believe it! I already tried the image as JPEG, but I got
just big colored pixels. I changed the 'samples Y' from 21 to 22 and
I got something coherent! Here is the same image as yesterday with
JPEG 411 header, compression quality 80% and insertion of 0x00 after
0xff.

[Ondrej Zary]

Post by Jean-Francois Moine
On Mon, 31 May 2010 00:03:10 +0200

Post by Ondrej Zary

Post by Andy Walls
I would try extracting a JPEG header from one of the files captured
by the camera in stand alone mode (either a JPEG still or MJPEG
file), and put that header together with the image data from the
USB capture. It may not look perfect, but hopefully you will get
something you recognize.

http://www.rainbow-software.org/linux_files/spca1528/sunp0003.avi

Post by Andy Walls
Attached was Theodore's first attempt of such a procedure with a
header extracted from a standalone image file from my Jeilin based
camera and USB snoop data from the same camera. It wasn't perfect,
but it was recognizable.

I could not believe it! I already tried the image as JPEG, but I got
just big colored pixels. I changed the 'samples Y' from 21 to 22 and
I got something coherent! Here is the same image as yesterday with
JPEG 411 header, compression quality 80% and insertion of 0x00 after
0xff.

That's great - that's what it should look like! It's a part of LCD monitor and
a shelf above it.

[Andy Walls]

Post by Jean-Francois Moine
On Mon, 31 May 2010 00:03:10 +0200

Post by Ondrej Zary

Post by Andy Walls
I would try extracting a JPEG header from one of the files captured
by the camera in stand alone mode (either a JPEG still or MJPEG
file), and put that header together with the image data from the
USB capture. It may not look perfect, but hopefully you will get
something you recognize.

http://www.rainbow-software.org/linux_files/spca1528/sunp0003.avi

Post by Andy Walls
Attached was Theodore's first attempt of such a procedure with a
header extracted from a standalone image file from my Jeilin based
camera and USB snoop data from the same camera. It wasn't perfect,
but it was recognizable.

I could not believe it! I already tried the image as JPEG, but I got
just big colored pixels. I changed the 'samples Y' from 21 to 22 and
I got something coherent! Here is the same image as yesterday with
JPEG 411 header, compression quality 80% and insertion of 0x00 after
0xff.

Very nice work!

I think I understand the 'samples Y' change. According to ITU T.81, you
changed the Vertical sampling factor in the Y component. So, I guess
Luma is undersampled vertically for that mode of the camera (the camera
only really has a 240 line sensor)?

Regards,
Andy

[Andy Walls]

Post by Jean-Francois Moine
On Sat, 29 May 2010 21:32:07 +0200

Post by Ondrej Zary
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
- 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-***@vger.kernel.org/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