SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

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

Ondrej Zary

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.

Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

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

Ondrej Zary

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.

Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

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.

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

Ondrej Zary

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!

Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

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/[email protected]/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

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/

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

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

Ondrej Zary

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

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

Thanks, I'll try that tomorrow.

Ondrej Zary

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

0000000: ff d8 ff e0 00 10 4a 46 49 46 00 01 01 00 00 01  ......JFIF......
0000010: 00 01 00 00 ff db 00 c5 00 0a 07 07 08 07 06 0a  ................
0000020: 08 08 08 0b 0a 0a 0b 0e 18 10 0e 0d 0d 0e 1d 15  ................
0000030: 16 11 18 23 1f 25 24 22 1f 22 21 26 2b 37 2f 26  ...#.%$"."!&+7/&
0000040: 29 34 29 21 22 30 41 31 34 39 3b 3e 3e 3e 25 2e  )4)!"0A149;>>>%.
0000050: 44 49 43 3c 48 37 3d 3e 3b 01 0a 0b 0b 0e 0d 0e  DIC<H7=>;.......
0000060: 1c 10 10 1c 3b 28 22 28 3b 3b 3b 3b 3b 3b 3b 3b  ....;("(;;;;;;;;
0000070: 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b  ;;;;;;;;;;;;;;;;
0000080: 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b  ;;;;;;;;;;;;;;;;
0000090: 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 02 17 18 18 24 21  ;;;;;;;;;;....$!
00000a0: 24 47 26 26 47 99 66 56 66 99 99 99 99 99 99 99  $G&&G.fVf.......
00000b0: 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99  ................
00000c0: 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99  ................
00000d0: 99 99 99 99 99 99 99 99 99 99 99 ff c4 01 a2 00  ................
00000e0: 00 01 05 01 01 01 01 01 01 00 00 00 00 00 00 00  ................
00000f0: 00 01 02 03 04 05 06 07 08 09 0a 0b 01 00 03 01  ................
0000100: 01 01 01 01 01 01 01 01 00 00 00 00 00 00 01 02  ................
0000110: 03 04 05 06 07 08 09 0a 0b 10 00 02 01 03 03 02  ................
0000120: 04 03 05 05 04 04 00 00 01 7d 01 02 03 00 04 11  .........}......
0000130: 05 12 21 31 41 06 13 51 61 07 22 71 14 32 81 91  ..!1A..Qa."q.2..
0000140: a1 08 23 42 b1 c1 15 52 d1 f0 24 33 62 72 82 09  ..#B...R..$3br..
0000150: 0a 16 17 18 19 1a 25 26 27 28 29 2a 34 35 36 37  ......%&'()*4567
0000160: 38 39 3a 43 44 45 46 47 48 49 4a 53 54 55 56 57  89:CDEFGHIJSTUVW
0000170: 58 59 5a 63 64 65 66 67 68 69 6a 73 74 75 76 77  XYZcdefghijstuvw
0000180: 78 79 7a 83 84 85 86 87 88 89 8a 92 93 94 95 96  xyz.............
0000190: 97 98 99 9a a2 a3 a4 a5 a6 a7 a8 a9 aa b2 b3 b4  ................
00001a0: b5 b6 b7 b8 b9 ba c2 c3 c4 c5 c6 c7 c8 c9 ca d2  ................
00001b0: d3 d4 d5 d6 d7 d8 d9 da e1 e2 e3 e4 e5 e6 e7 e8  ................
00001c0: e9 ea f1 f2 f3 f4 f5 f6 f7 f8 f9 fa 11 00 02 01  ................
00001d0: 02 04 04 03 04 07 05 04 04 00 01 02 77 00 01 02  ............w...
00001e0: 03 11 04 05 21 31 06 12 41 51 07 61 71 13 22 32  ....!1..AQ.aq."2
00001f0: 81 08 14 42 91 a1 b1 c1 09 23 33 52 f0 15 62 72  ...B.....#3R..br
0000200: d1 0a 16 24 34 e1 25 f1 17 18 19 1a 26 27 28 29  ...$4.%.....&'()
0000210: 2a 35 36 37 38 39 3a 43 44 45 46 47 48 49 4a 53  *56789:CDEFGHIJS
0000220: 54 55 56 57 58 59 5a 63 64 65 66 67 68 69 6a 73  TUVWXYZcdefghijs
0000230: 74 75 76 77 78 79 7a 82 83 84 85 86 87 88 89 8a  tuvwxyz.........
0000240: 92 93 94 95 96 97 98 99 9a a2 a3 a4 a5 a6 a7 a8  ................
0000250: a9 aa b2 b3 b4 b5 b6 b7 b8 b9 ba c2 c3 c4 c5 c6  ................
0000260: c7 c8 c9 ca d2 d3 d4 d5 d6 d7 d8 d9 da e2 e3 e4  ................
0000270: e5 e6 e7 e8 e9 ea f2 f3 f4 f5 f6 f7 f8 f9 fa ff  ................
0000280: c0 00 11 08 01 e0 02 80 03 01 21 00 02 11 01 03  ..........!.....
0000290: 11 01 ff da 00 0c 03 01 00 02 11 03 11 00 3f 00  ..............?.

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

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

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.

Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

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

Ondrej Zary

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