SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

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)


>From Windows driver:
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

Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Jean-Francois Moine]

On Sat, 29 May 2010 19:09:32 +0200
Ondrej Zary <linux@rainbow-software.org> wrote:

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

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/

Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Ondrej Zary]

On Saturday 29 May 2010 20:24:25 Jean-Francois Moine wrote:
> On Sat, 29 May 2010 19:09:32 +0200
>
> Ondrej Zary <linux@rainbow-software.org> wrote:
> > 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:
>
> 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

-- 
Ondrej Zary

Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Jean-Francois Moine]

On Sat, 29 May 2010 21:32:07 +0200
Ondrej Zary <linux@rainbow-software.org> 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...

Best regards.

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

Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Ondrej Zary]

On Sunday 30 May 2010 13:34:55 Jean-Francois Moine wrote:
> On Sat, 29 May 2010 21:32:07 +0200
>
> Ondrej Zary <linux@rainbow-software.org> 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?

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.

-- 
Ondrej Zary

Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Jean-Francois Moine]

[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]

On Sun, 30 May 2010 19:55:22 +0200
Ondrej Zary <linux@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!

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

[-- Attachment #2: image640.dat --]
[-- Type: application/octet-stream, Size: 28893 bytes --]

Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Andy Walls]

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@rainbow-software.org> 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@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

Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Andy Walls]

On Sun, 2010-05-30 at 19:55 +0200, Ondrej Zary wrote:
> On Sunday 30 May 2010 13:34:55 Jean-Francois Moine wrote:
> > On Sat, 29 May 2010 21:32:07 +0200
> >
> > Ondrej Zary <linux@rainbow-software.org> 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?
> 
> 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...


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/


> 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

Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Ondrej Zary]

On Sunday 30 May 2010 21:26:14 Andy Walls wrote:
> On Sun, 2010-05-30 at 19:55 +0200, Ondrej Zary wrote:
> > On Sunday 30 May 2010 13:34:55 Jean-Francois Moine wrote:
> > > On Sat, 29 May 2010 21:32:07 +0200
> > >
> > > Ondrej Zary <linux@rainbow-software.org> 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?
> >
> > 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...
>
> 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/
>
> > 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. ;)

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

Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Andy Walls]

[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]

On Sun, 2010-05-30 at 23:28 +0200, Ondrej Zary wrote:
> On Sunday 30 May 2010 21:26:14 Andy Walls wrote:
> > On Sun, 2010-05-30 at 19:55 +0200, Ondrej Zary wrote:
> > > On Sunday 30 May 2010 13:34:55 Jean-Francois Moine wrote:

> >
> > 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/
> >
> > > 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. ;)
> 
> 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

[-- Attachment #2: frame_one.jpg --]
[-- Type: image/jpeg, Size: 8944 bytes --]

Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Ondrej Zary]

On Sunday 30 May 2010 23:58:11 Andy Walls wrote:
> On Sun, 2010-05-30 at 23:28 +0200, Ondrej Zary wrote:
> > On Sunday 30 May 2010 21:26:14 Andy Walls wrote:
> > > On Sun, 2010-05-30 at 19:55 +0200, Ondrej Zary wrote:
> > > > On Sunday 30 May 2010 13:34:55 Jean-Francois Moine wrote:
> > >
> > > 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/
> > >
> > > > 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. ;)
> >
> > 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

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

> 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

Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Andy Walls]

[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]

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



[-- Attachment #2: test1.jpg --]
[-- Type: image/jpeg, Size: 29565 bytes --]

[-- Attachment #3: jpeghdr.txt --]
[-- Type: text/plain, Size: 3150 bytes --]

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

Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Theodore Kilgore]

On Mon, 31 May 2010, Ondrej Zary wrote:

> On Sunday 30 May 2010 23:58:11 Andy Walls wrote:
> > On Sun, 2010-05-30 at 23:28 +0200, Ondrej Zary wrote:
> > > On Sunday 30 May 2010 21:26:14 Andy Walls wrote:
> > > > On Sun, 2010-05-30 at 19:55 +0200, Ondrej Zary wrote:
> > > > > On Sunday 30 May 2010 13:34:55 Jean-Francois Moine wrote:
> > > >
> > > > 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/
> > > >
> > > > > 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. ;)
> > >
> > > 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
> 
> > 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.
> 
> > 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

Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Theodore Kilgore]

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@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:

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

Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Jean-Francois Moine]

[-- Attachment #1: Type: text/plain, Size: 1173 bytes --]

On Mon, 31 May 2010 00:03:10 +0200
Ondrej Zary <linux@rainbow-software.org> wrote:

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

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

[-- Attachment #2: image640.jpg --]
[-- Type: image/jpeg, Size: 29506 bytes --]

Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Ondrej Zary]

On Monday 31 May 2010, Jean-Francois Moine wrote:
> On Mon, 31 May 2010 00:03:10 +0200
>
> Ondrej Zary <linux@rainbow-software.org> wrote:
> > > 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
> >
> > > 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.

-- 
Ondrej Zary

Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Andy Walls]

On Mon, 2010-05-31 at 09:19 +0200, Jean-Francois Moine wrote:
> On Mon, 31 May 2010 00:03:10 +0200
> Ondrej Zary <linux@rainbow-software.org> wrote:
> 
> > > 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
> > 
> > > 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