Topro 6800 driver

Topro 6800 driver

[Anders Blomdell]

Hi,

I'm trying to write a driver for a webcam based on Topro TP6801/CX0342
(06a2:0003). My first attempt (needs gspca) can be found on:

http://www.control.lth.se/user/andersb/tp6800.c

Unfortunately the JPEG images (one example dump is in
http://www.control.lth.se/user/andersb/topro_img_dump.txt), seems to be bogus,
they start with (data is very similar to windows data):

00000000: 0xff,0xd8,0xff,0xfe,0x28,0x3c,0x01,0xe8,...
...
0000c340: ...,0xf4,0xc0,0xff,0xd9

Anybody who has a good idea of how to find a DQT/Huffman table that works with
this image data?

Best regards

Anders Blomdell

-- 
Anders Blomdell                  Email: anders.blomdell@control.lth.se
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Topro 6800 driver

[Jean-Francois Moine]

On Fri, 27 Feb 2009 23:15:54 +0100
Anders Blomdell <anders.blomdell@control.lth.se> wrote:

> Hi,
> 
> I'm trying to write a driver for a webcam based on Topro TP6801/CX0342
> (06a2:0003). My first attempt (needs gspca) can be found on:
> 
> http://www.control.lth.se/user/andersb/tp6800.c
> 
> Unfortunately the JPEG images (one example dump is in
> http://www.control.lth.se/user/andersb/topro_img_dump.txt), seems to
> be bogus, they start with (data is very similar to windows data):
> 
> 00000000: 0xff,0xd8,0xff,0xfe,0x28,0x3c,0x01,0xe8,...
> ...
> 0000c340: ...,0xf4,0xc0,0xff,0xd9
> 
> Anybody who has a good idea of how to find a DQT/Huffman table that
> works with this image data?

Hi Anders,

Thomas Champagne (See To:) was also writing a driver for this webcam.
Maybe you may merge your codes...

About the JPEG images, the Huffman table is always the same and the
quantization tables depend on the compression quality.

>From the USB trace I had from Thomas, I saw that:

- when a packet starts with '55 ff d8', it is the first part of the
  image. This one should start at the offset 8 of the packet.

- when a packet starts with 'cc', it is the next part of the image.

In the function pkt_scan, when finding the image start, you must add
the JPEG header: 'ff d8', DQT, huffman table, SOF0 and SOS.

As we don't know the quality used by the webcam, in my test repository,
I added a control for that: the JPEG header is created at streamon
time, and the quantization tables may be modified by the control on the
fly (have a look at stk014.c for an example).

This solution is not the right one: the JPEG quality must be set by the
VIDIOC_S_JPEGCOMP ioctl instead of VIDIOC_S_CTRL. I think I will update
the concerned subdrivers next week.

BTW, don't use the video4linux-list@redhat.com mailing-list anymore: all
the video discussions are now done in linux-media@vger.kernel.org.

Best regards.

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

Re: Topro 6800 driver

[Thomas Kaiser]

Hello Anders

Anders Blomdell wrote:
> Anybody who has a good idea of how to find a DQT/Huffman table that works with
> this image data?

You can search in the Windoz binary driver for JPEG markers (FFxx). 
Maybe, you can find a basic DQT/Huffman table in there.

Regards, Thomas

Re: Topro 6800 driver

[Anders Blomdell]

Jean-Francois Moine wrote:
> On Fri, 27 Feb 2009 23:15:54 +0100
> Anders Blomdell <anders.blomdell@control.lth.se> wrote:
> 
>> Hi,
>>
>> I'm trying to write a driver for a webcam based on Topro TP6801/CX0342
>> (06a2:0003). My first attempt (needs gspca) can be found on:
>>
>> http://www.control.lth.se/user/andersb/tp6800.c
>>
>> Unfortunately the JPEG images (one example dump is in
>> http://www.control.lth.se/user/andersb/topro_img_dump.txt), seems to
>> be bogus, they start with (data is very similar to windows data):
>>
>> 00000000: 0xff,0xd8,0xff,0xfe,0x28,0x3c,0x01,0xe8,...
>> ...
>> 0000c340: ...,0xf4,0xc0,0xff,0xd9
>>
>> Anybody who has a good idea of how to find a DQT/Huffman table that
>> works with this image data?
> 
> Hi Anders,
> 
> Thomas Champagne (See To:) was also writing a driver for this webcam.
> Maybe you may merge your codes...
Thomas, if you have DQT/Huffman tables for this camera, please drop me a 
note.

> 
> About the JPEG images, the Huffman table is always the same 
Does this mean that it's the same for all JPEG images or only for one 
camera?

If it's the same for all images, it should mean that I have a way to 
determine how much I have to chop off after the 0xfffe tag (no illegal 
huffman codes -> possibly chop at the correct position).

Comments anyone?


 > and the
> quantization tables depend on the compression quality.
> 
> From the USB trace I had from Thomas, I saw that:
> 
> - when a packet starts with '55 ff d8', it is the first part of the
>   image. This one should start at the offset 8 of the packet.
> 
> - when a packet starts with 'cc', it is the next part of the image.
This is even in the docs, and is implemented in the driver.

> In the function pkt_scan, when finding the image start, you must add
> the JPEG header: 'ff d8', DQT, huffman table, SOF0 and SOS.
OK, will see if I can find the DQT (and possibly the Huffman table) in 
the windows driver (as suggested by Thomas Kaiser).

> As we don't know the quality used by the webcam, in my test repository,
> I added a control for that: the JPEG header is created at streamon
> time, and the quantization tables may be modified by the control on the
> fly (have a look at stk014.c for an example).
> 
> This solution is not the right one: the JPEG quality must be set by the
> VIDIOC_S_JPEGCOMP ioctl instead of VIDIOC_S_CTRL. I think I will update
> the concerned subdrivers next week.
I'll look into that monday.

> BTW, don't use the video4linux-list@redhat.com mailing-list anymore: all
> the video discussions are now done in linux-media@vger.kernel.org.
OK, so Google hit http://www.linuxtv.org/v4lwiki/index.php/Main_Page is 
no hit then...


Thanks

Anders Blomdell

Re: Topro 6800 driver

[Thomas Kaiser]

Hello Anders

Anders Blomdell wrote:
> Jean-Francois Moine wrote:
>> On Fri, 27 Feb 2009 23:15:54 +0100
>> About the JPEG images, the Huffman table is always the same 
> Does this mean that it's the same for all JPEG images or only for one 
> camera?
> 
> If it's the same for all images, it should mean that I have a way to 
> determine how much I have to chop off after the 0xfffe tag (no illegal 
> huffman codes -> possibly chop at the correct position).
> 
> Comments anyone?
> 

As per definition of JPEG, the Huffman table is always calculated 
especially for each picture to get the best compression. Thus the 
Huffman table and the DQT has to be in the JPEG stream like you see on 
JPEG picture on your HD.
With webcams, it is a bit an other story. The webcam hardware is usually 
not powerful enough to calculate the Huffman table for each frame. 
Therefor a static Huffman table is used. This Huffman table should fit 
more less to the image the camera is producing. With the drawback that 
we cannot achieve the highest compression possible. On the other hand 
the Huffman table is always the same the cam has not to send this in the 
video stream and the stream has less overhead.

In short, the Huffman table is always the same for a given webcam.

I don't think 0xfffe is a valid JPEG marker. 0xfffe is a comment marker 
and the next 2 bytes after this markers tells the length of the comment 
(including the two length byte). So, your comment would be 10300 Bytes 
long. I don't think that such many Bytes are used for a comment when 
they try to have as less as possible overhead.
I think 0xfffe is the start of the compressed data stream and has 
nothing to do with JPEG markers.

Thomas

Re: Topro 6800 driver

[Jean-Francois Moine]

On Sat, 28 Feb 2009 16:11:36 +0100
Anders Blomdell <anders.blomdell@control.lth.se> wrote:

> Jean-Francois Moine wrote:
> > Thomas Champagne (See To:) was also writing a driver for this
> > webcam. Maybe you may merge your codes...
> Thomas, if you have DQT/Huffman tables for this camera, please drop
> me a note.
> 
> > About the JPEG images, the Huffman table is always the same 
> Does this mean that it's the same for all JPEG images or only for one 
> camera?
> 
> If it's the same for all images, it should mean that I have a way to 
> determine how much I have to chop off after the 0xfffe tag (no
> illegal huffman codes -> possibly chop at the correct position).
> 
> Comments anyone?

I already explained it:

- when a packet starts with '55 ff d8', it is the first part of the
  image. This one should start at the offset 8 of the packet.
                                      ~~~~~~~~

>  > and the
> > quantization tables depend on the compression quality.
> > 
> > From the USB trace I had from Thomas, I saw that:
> > 
> > - when a packet starts with '55 ff d8', it is the first part of the
> >   image. This one should start at the offset 8 of the packet.
> > 
> > - when a packet starts with 'cc', it is the next part of the image.
> This is even in the docs, and is implemented in the driver.
> 
> > In the function pkt_scan, when finding the image start, you must add
> > the JPEG header: 'ff d8', DQT, huffman table, SOF0 and SOS.
> OK, will see if I can find the DQT (and possibly the Huffman table)
> in the windows driver (as suggested by Thomas Kaiser).

See below.

> > As we don't know the quality used by the webcam, in my test
> > repository, I added a control for that: the JPEG header is created
> > at streamon time, and the quantization tables may be modified by
> > the control on the fly (have a look at stk014.c for an example).
> > 
> > This solution is not the right one: the JPEG quality must be set by
> > the VIDIOC_S_JPEGCOMP ioctl instead of VIDIOC_S_CTRL. I think I
> > will update the concerned subdrivers next week.
> I'll look into that monday.

In gspca, the file "jpeg.h" contains all the material to build a
complete JPEG header. With the new mechanism of my test repository, you
must:

- at streamon time (function sd_start):
	- allocate a buffer for the JPEG header,
	- set the resolution and number of samplesY (0x22 or 0x21) by
		the function jpeg_define,
	- set the quantization tables by the function jpeg_set_qual,
	  the quality being in percent (15..95).

- when getting the start of a new image in sd_pkt_scan, add the JPEG
  header as the first packet.

- at streamoff time (function sd_stop0), free the JPEG header.

- on VIDIOC_S_JPEGCOMP (function sd_set_jcomp which you must create),
  redefine the quantization tables by jpeg_set_qual.

Cheers.

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

Re: Topro 6800 driver

[Thomas Champagne]

Hi Anders and others,

I have already tried to create a module for my webcam (Topro TP6800).
It have the same usb id (06a2:0003).
But I have the same problem as you about the image data. I don't know
what is the comment tag (FF:FE). I tried to skip the tag or to skip
the comment with the length after this tag but the image is never
good. I don't know where start the image. If you want an example of
the bad result you can download this image :
http://lafeuil.free.fr/webcam/images/1.jpg
So, I am also in the dark.

If you want to take a look to my code, you can download this file :
http://lafeuil.free.fr/webcam/tp6800.c

If somebody have an idea how can I transform the data, Tell me !

Good luck
Thomas Champagne

2009/2/28 Anders Blomdell <anders.blomdell@control.lth.se>:
> Jean-Francois Moine wrote:
>>
>> On Fri, 27 Feb 2009 23:15:54 +0100
>> Anders Blomdell <anders.blomdell@control.lth.se> wrote:
>>
>>> Hi,
>>>
>>> I'm trying to write a driver for a webcam based on Topro TP6801/CX0342
>>> (06a2:0003). My first attempt (needs gspca) can be found on:
>>>
>>> http://www.control.lth.se/user/andersb/tp6800.c
>>>
>>> Unfortunately the JPEG images (one example dump is in
>>> http://www.control.lth.se/user/andersb/topro_img_dump.txt), seems to
>>> be bogus, they start with (data is very similar to windows data):
>>>
>>> 00000000: 0xff,0xd8,0xff,0xfe,0x28,0x3c,0x01,0xe8,...
>>> ...
>>> 0000c340: ...,0xf4,0xc0,0xff,0xd9
>>>
>>> Anybody who has a good idea of how to find a DQT/Huffman table that
>>> works with this image data?
>>
>> Hi Anders,
>>
>> Thomas Champagne (See To:) was also writing a driver for this webcam.
>> Maybe you may merge your codes...
>
> Thomas, if you have DQT/Huffman tables for this camera, please drop me a
> note.
>
>>
>> About the JPEG images, the Huffman table is always the same
>
> Does this mean that it's the same for all JPEG images or only for one
> camera?
>
> If it's the same for all images, it should mean that I have a way to
> determine how much I have to chop off after the 0xfffe tag (no illegal
> huffman codes -> possibly chop at the correct position).
>
> Comments anyone?
>
>
>> and the
>>
>> quantization tables depend on the compression quality.
>>
>> From the USB trace I had from Thomas, I saw that:
>>
>> - when a packet starts with '55 ff d8', it is the first part of the
>>  image. This one should start at the offset 8 of the packet.
>>
>> - when a packet starts with 'cc', it is the next part of the image.
>
> This is even in the docs, and is implemented in the driver.
>
>> In the function pkt_scan, when finding the image start, you must add
>> the JPEG header: 'ff d8', DQT, huffman table, SOF0 and SOS.
>
> OK, will see if I can find the DQT (and possibly the Huffman table) in the
> windows driver (as suggested by Thomas Kaiser).
>
>> As we don't know the quality used by the webcam, in my test repository,
>> I added a control for that: the JPEG header is created at streamon
>> time, and the quantization tables may be modified by the control on the
>> fly (have a look at stk014.c for an example).
>>
>> This solution is not the right one: the JPEG quality must be set by the
>> VIDIOC_S_JPEGCOMP ioctl instead of VIDIOC_S_CTRL. I think I will update
>> the concerned subdrivers next week.
>
> I'll look into that monday.
>
>> BTW, don't use the video4linux-list@redhat.com mailing-list anymore: all
>> the video discussions are now done in linux-media@vger.kernel.org.
>
> OK, so Google hit http://www.linuxtv.org/v4lwiki/index.php/Main_Page is no
> hit then...
>
>
> Thanks
>
> Anders Blomdell
>

Re: Topro 6800 driver

[Jean-Francois Moine]

On Sun, 1 Mar 2009 17:33:32 +0100
Thomas Champagne <lafeuil@gmail.com> wrote:

> I have already tried to create a module for my webcam (Topro TP6800).
> It have the same usb id (06a2:0003).
> But I have the same problem as you about the image data. I don't know
> what is the comment tag (FF:FE). I tried to skip the tag or to skip
> the comment with the length after this tag but the image is never
> good. I don't know where start the image. If you want an example of
> the bad result you can download this image :
> http://lafeuil.free.fr/webcam/images/1.jpg
> So, I am also in the dark.

Hi Thomas and Anders,

I add a look at your image (the samplesY is odd) and also at some other
ones in the USB snoop you sent me, and, yes, the exact start and the
parameters of the image are not easy to find.

I tried to ignore the first 7 to 25 bytes without any success. The
image samplesY should be 0x21 (it is not 0x22 - can it be something
else?).

If the webcam can record photos or if the MS-win driver could output
raw images, it would help. Is it possible?

The last solution is to trace the tiny JPEG decoder changing the input
offset until it does not see error of the Huffman code anymore...

Cheers.

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

Re: Topro 6800 driver

[Anders Blomdell]

Jean-Francois Moine wrote:
> On Sun, 1 Mar 2009 17:33:32 +0100
> Thomas Champagne <lafeuil@gmail.com> wrote:
> 
>> I have already tried to create a module for my webcam (Topro TP6800).
>> It have the same usb id (06a2:0003).
>> But I have the same problem as you about the image data. I don't know
>> what is the comment tag (FF:FE). I tried to skip the tag or to skip
>> the comment with the length after this tag but the image is never
>> good. I don't know where start the image. If you want an example of
>> the bad result you can download this image :
>> http://lafeuil.free.fr/webcam/images/1.jpg
>> So, I am also in the dark.
> 
> Hi Thomas and Anders,
> 
> I add a look at your image (the samplesY is odd) and also at some other
> ones in the USB snoop you sent me, and, yes, the exact start and the
> parameters of the image are not easy to find.
Thanks for trying, though...

> I tried to ignore the first 7 to 25 bytes without any success. The
> image samplesY should be 0x21 (it is not 0x22 - can it be something
> else?).
Beats me.
> 
> If the webcam can record photos or if the MS-win driver could output
> raw images, it would help. Is it possible?
Don't know. The driver states 'TWAIN/VFW/Direct show' compatibility, but if any
of those can be used to get RAW images (do you by this mean JPEG as it comes
from the camera, or truly RAW images [RGB/YUV]).

> The last solution is to trace the tiny JPEG decoder changing the input
> offset until it does not see error of the Huffman code anymore...
Where can I find that?

I have also tried to backtrack through the distributor chain in order to try to
get technical info, since TOPRO doesn't seem to answer emails from ordinary
users. Will see if that gives any results...

Best regards

Anders

-- 
Anders Blomdell                  Email: anders.blomdell@control.lth.se
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

Re: Topro 6800 driver

[Anders Blomdell]

Thomas Kaiser wrote:
> Hello Anders
> 
> Anders Blomdell wrote:
>> Hi,
>>
>> I'm trying to write a driver for a webcam based on Topro TP6801/CX0342
>> (06a2:0003). My first attempt (needs gspca) can be found on:
> 
> I own a cam with a TP6810 USB bridge and a CX0342 sensor (this is 
> written on the driver CD).
> 
>> http://www.control.lth.se/user/andersb/tp6800.c
>>
>> Unfortunately the JPEG images (one example dump is in
>> http://www.control.lth.se/user/andersb/topro_img_dump.txt), seems to be bogus,
>> they start with (data is very similar to windows data):
>>
>> 00000000: 0xff,0xd8,0xff,0xfe,0x28,0x3c,0x01,0xe8,...
>> ...
>> 0000c340: ...,0xf4,0xc0,0xff,0xd9
>>
>> Anybody who has a good idea of how to find a DQT/Huffman table that works with
>> this image data?
> 
> I did some usbsnoops today and see some similar things in the stream as 
> in your trace. Maybe you can comment on my observation?
> 
> When I stop the capturing, the las 2 Bytes are always 0xff 0xd9 which 
> look like a valid JPEG marker (End of Image)
> 
> When I search for 0xffd9, I see the following sequence:
> 
> FF D9 5x FF D8 FF FE 14 1E xx xx xx
Is the 5x directly following the FFD9 (in my camera, the next frame [55] is in a
new ISO frame)?

> - 5x is 55 or 5A
I have only seen ISO frames starting with 55 (new frame) AA (abort frame) CC
(frame continuation), the 5A case is not documented in the manual I have

> - the 3 xx are mostly the same, but they change a lot when I cover the 
> lens of the cam. So I think this is some image information (brightness?).
Or perhaps JPEG encoded data.

> This said, i don't think that FF D8 and FF FE are JPEG markers, just a 
> unique Byte pattern to mark the start of a new frame.
Since the manual states that the chip does JPEG compression, and the frames are
significantly smaller than 640*480 and varies in size, I expect it to be in some
compressed format, and so far I expect JPEG (but with unknown Huffman/DQT tables).

> I guess 5x FF D8 FF FE 14 1E xx xx xx and may be some more bytes is the 
> frame marker.
> 
> Comments?
It would be interesting to know if somebody well versed in windows programming
could write a program to get JPEG frames out of the driver directly (provided
this is possible of course), if the image part of such a frame matches the data
seen on USB, we would then have the Huffman/DQT tables.

At the moment I'm stuck, since I see no way to find out what Huffman/DQT tables
that are used.

/Anders

-- 
Anders Blomdell                  Email: anders.blomdell@control.lth.se
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Topro 6800 driver

[Anders Blomdell]

Thomas Kaiser wrote:
> Hello Anders
> 
> Anders Blomdell wrote:
>>>> Anybody who has a good idea of how to find a DQT/Huffman table that works with
>>>> this image data?
>>> I did some usbsnoops today and see some similar things in the stream as 
>>> in your trace. Maybe you can comment on my observation?
>>>
>>> When I stop the capturing, the las 2 Bytes are always 0xff 0xd9 which 
>>> look like a valid JPEG marker (End of Image)
>>>
>>> When I search for 0xffd9, I see the following sequence:
>>>
>>> FF D9 5x FF D8 FF FE 14 1E xx xx xx
>> Is the 5x directly following the FFD9 (in my camera, the next frame [55] is in a
>> new ISO frame)?
> 
> Actually, the 5x is always the first byte in the IsoPacket. In my 
> snoops, it is mostly 5A.
> 
>>> - 5x is 55 or 5A
>> I have only seen ISO frames starting with 55 (new frame) AA (abort frame) CC
>> (frame continuation), the 5A case is not documented in the manual I have
> 
> Can you send this manual to me (private)?
Will do (TP6801 manual), also available at:

http://www.topro.com.tw/Product_Show.asp?Product_ID=39
> 
>>> - the 3 xx are mostly the same, but they change a lot when I cover the 
>>> lens of the cam. So I think this is some image information (brightness?).
>> Or perhaps JPEG encoded data.
>>
>>> This said, i don't think that FF D8 and FF FE are JPEG markers, just a 
>>> unique Byte pattern to mark the start of a new frame.
>> Since the manual states that the chip does JPEG compression, and the frames are
>> significantly smaller than 640*480 and varies in size, I expect it to be in some
>> compressed format, and so far I expect JPEG (but with unknown Huffman/DQT tables).
>>
>>> I guess 5x FF D8 FF FE 14 1E xx xx xx and may be some more bytes is the 
>>> frame marker.
> 
> I did some more studying over the weekend....
> 
> In my snoops, I think:
> 5a ff d8 ff fe 14 1e 00 fd f5 45 7e e8 f8 b8 df 49 57
> 
> is the frame header, so at offset 18, the JPEG streams starts.
What do you base that on (just curious, I'm not in a position to argument)?

> And I am 100% sure that the stream is JPEG coded.
What makes you so sure? FF00 perhaps?

> 
>>> Comments?
>> It would be interesting to know if somebody well versed in windows programming
>> could write a program to get JPEG frames out of the driver directly (provided
>> this is possible of course), if the image part of such a frame matches the data
>> seen on USB, we would then have the Huffman/DQT tables.
> 
> Might be possible for some one you knows how to interact with the Windoz 
> driver, I don't.
> Or you can get the sensor in saturation (only white picture), then you 
> know how the picture should look like. When the whole picture is only 
> white, each MCU has to be the same ;-)
Hmm, perhaps setting all entries in the gammatables to the same value would give
some useful information then. See more below...

> 
>> At the moment I'm stuck, since I see no way to find out what Huffman/DQT tables
>> that are used.
> 
> I found some interesting file in a TP6810 folder on my Windoz box after 
> I installed the driver. See Attachment ;-)
Looks like 17 DQT tables to me, if one assumes that the description for register
79 (QUALITY):

  JPEG compression quality factor 0 ~ 31
    0: good quality
    15: smallest size
    16 ~ 31: ultra fine quality

can be interpreted as that there are 17 different quality levels, that should
mean that we have some information. If we then set the gammatables (Bulk-Out
with prefix) to constant values, we should know what data goes into the Huffman
encoding, which might give some additional information.
> 
> Hope this helps, I will study some more....
Don't know, but it's new data to chew on...


-- 
Anders Blomdell                  Email: anders.blomdell@control.lth.se
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Topro 6800 driver

[Anders Blomdell]

Thomas Kaiser wrote:
> Hello Anders
> 
> Anders Blomdell wrote:
>>>> Anybody who has a good idea of how to find a DQT/Huffman table that works with
>>>> this image data?
>>> I did some usbsnoops today and see some similar things in the stream as 
>>> in your trace. Maybe you can comment on my observation?
>>>
>>> When I stop the capturing, the las 2 Bytes are always 0xff 0xd9 which 
>>> look like a valid JPEG marker (End of Image)
>>>
>>> When I search for 0xffd9, I see the following sequence:
>>>
>>> FF D9 5x FF D8 FF FE 14 1E xx xx xx
>> Is the 5x directly following the FFD9 (in my camera, the next frame [55] is in a
>> new ISO frame)?
> 
> Actually, the 5x is always the first byte in the IsoPacket. In my 
> snoops, it is mostly 5A.
> 
>>> - 5x is 55 or 5A
>> I have only seen ISO frames starting with 55 (new frame) AA (abort frame) CC
>> (frame continuation), the 5A case is not documented in the manual I have
> 
> Can you send this manual to me (private)?
> 
>>> - the 3 xx are mostly the same, but they change a lot when I cover the 
>>> lens of the cam. So I think this is some image information (brightness?).
>> Or perhaps JPEG encoded data.
>>
>>> This said, i don't think that FF D8 and FF FE are JPEG markers, just a 
>>> unique Byte pattern to mark the start of a new frame.
>> Since the manual states that the chip does JPEG compression, and the frames are
>> significantly smaller than 640*480 and varies in size, I expect it to be in some
>> compressed format, and so far I expect JPEG (but with unknown Huffman/DQT tables).
>>
>>> I guess 5x FF D8 FF FE 14 1E xx xx xx and may be some more bytes is the 
>>> frame marker.
> 
> I did some more studying over the weekend....
> 
> In my snoops, I think:

When I set the RGB/YUV gains to zero, I get:
> 5a ff d8 ff fe 14 1e 00 fd f5 45 7e e8 f8 b8 df 49 57
     ff d8 ff fe 28 3c 01 fc ff 00 45 66 9a 69 a2 95 4d 2a 12 d1 00 a2 b4

followed by a big number of repeated (0x152c bytes total):

  02 8a 00 a2 80 28 a0 0a 28

and ending with:

  02 8a 00 a2 80 ff d9

In binary the repeating sequence can be diveded in half:

  0000 0010 1000 1010 0000 0000 1010 0010 1000
  0000 0010 1000 1010 0000 0000 1010 0010 1000

Which approximately adds up to 1200 repetitions of this bitpattern 2*(0x152c -
23)/9.

And a 640*480 image divided in 8*8 subframes gives (640*480/(8*8)) 1200
subframes, so now the question is how much info about the Huffman table this
gives us?

When I change the quality setting of the camera, the bitpattern changes, but
size stays approximately the same, here follows the start of the frames at
different quality settings. Notable facts:

  1. Byte 6 seems to be currently used quality setting
  2. Byte 4 & 5 are exactly twice as big as in Thomas dump, could it be related
     to size?
  3. Quality settings 0x10 to 0x1f seems to generate the same bit-patter, which
     indicates that the file Thomas found might be the DQT, now the quistion is
     if my dumps together with those tables are enough to determine the huffman
     table used (hopefully the same for all quality settings)

sd_setquality
0 = write(79, 0)
Size=1539, quality=0
ff d8 ff fe 28 3c 00 fc 01 45 73 c1 c1 c3 c1 c3
a7 0b 0a 95 4d 34 a4 92 4a 12 4a c9 24 b4 4b 64
02 8a e8 02 8a 00 a2 80 28 a0 0a 28 02 8a 00 a2
80 28 a0 0a 28 02 8a 00 a2 80 28 a0 0a 28 02 8a
00 a2 80 28 a0 0a 28 02 8a 00 a2 80 28 a0 0a 28
02 8a 00 a2 80 28 a0 0a 28 02 8a 00 a2 80 28 a0
0a 28 02 8a 00 a2 80 28 a0 0a 28 02 8a 00 a2 80
28 a0 0a 28 02 8a 00 a2 80 28 a0 0a 28 02 8a 00
sd_setquality
0 = write(79, 1)
Size=152d, quality=1
ff d8 ff fe 28 3c 01 fc ff 00 45 66 9a 69 a2 95
4d 2a 12 d1 00 a2 b4 02 8a 00 a2 80 28 a0 0a 28
02 8a 00 a2 80 28 a0 0a 28 02 8a 00 a2 80 28 a0
0a 28 02 8a 00 a2 80 28 a0 0a 28 02 8a 00 a2 80
28 a0 0a 28 02 8a 00 a2 80 28 a0 0a 28 02 8a 00
a2 80 28 a0 0a 28 02 8a 00 a2 80 28 a0 0a 28 02
8a 00 a2 80 28 a0 0a 28 02 8a 00 a2 80 28 a0 0a
28 02 8a 00 a2 80 28 a0 0a 28 02 8a 00 a2 80 28
sd_setquality
0 = write(79, 2)
Size=152a, quality=2
ff d8 ff fe 28 3c 02 f9 55 15 29 a5 52 95 34 a8
48 05 15 40 51 40 14 50 05 14 01 45 00 51 40 14
50 05 14 01 45 00 51 40 14 50 05 14 01 45 00 51
40 14 50 05 14 01 45 00 51 40 14 50 05 14 01 45
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
sd_setquality
0 = write(79, 3)
Size=1526, quality=3
ff d8 ff fe 28 3c 03 f9 fd 15 12 49 42 01 45 50
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
51 40 14 50 05 14 01 45 00 51 40 14 50 05 14 01
45 00 51 40 14 50 05 14 01 45 00 51 40 14 50 05
14 01 45 00 51 40 14 50 05 14 01 45 00 51 40 14
50 05 14 01 45 00 51 40 14 50 05 14 01 45 00 51
40 14 50 05 14 01 45 00 51 40 14 50 05 14 01 45
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
sd_setquality
0 = write(79, 4)
Size=1526, quality=4
ff d8 ff fe 28 3c 04 f9 fd 15 12 49 42 01 45 50
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
51 40 14 50 05 14 01 45 00 51 40 14 50 05 14 01
45 00 51 40 14 50 05 14 01 45 00 51 40 14 50 05
14 01 45 00 51 40 14 50 05 14 01 45 00 51 40 14
50 05 14 01 45 00 51 40 14 50 05 14 01 45 00 51
40 14 50 05 14 01 45 00 51 40 14 50 05 14 01 45
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
sd_setquality
0 = write(79, 5)
Size=1526, quality=5
ff d8 ff fe 28 3c 05 f9 fd 15 12 49 42 01 45 50
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
51 40 14 50 05 14 01 45 00 51 40 14 50 05 14 01
45 00 51 40 14 50 05 14 01 45 00 51 40 14 50 05
14 01 45 00 51 40 14 50 05 14 01 45 00 51 40 14
50 05 14 01 45 00 51 40 14 50 05 14 01 45 00 51
40 14 50 05 14 01 45 00 51 40 14 50 05 14 01 45
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
sd_setquality
0 = write(79, 6)
Size=1526, quality=6
ff d8 ff fe 28 3c 06 f1 94 54 49 25 08 05 15 40
51 40 14 50 05 14 01 45 00 51 40 14 50 05 14 01
45 00 51 40 14 50 05 14 01 45 00 51 40 14 50 05
14 01 45 00 51 40 14 50 05 14 01 45 00 51 40 14
50 05 14 01 45 00 51 40 14 50 05 14 01 45 00 51
40 14 50 05 14 01 45 00 51 40 14 50 05 14 01 45
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
sd_setquality
0 = write(79, 7)
Size=1525, quality=7
ff d8 ff fe 28 3c 07 f1 94 54 4a 2c 80 51 54 05
14 01 45 00 51 40 14 50 05 14 01 45 00 51 40 14
50 05 14 01 45 00 51 40 14 50 05 14 01 45 00 51
40 14 50 05 14 01 45 00 51 40 14 50 05 14 01 45
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
sd_setquality
0 = write(79, 8)
Size=1524, quality=8
ff d8 ff fe 28 3c 08 f2 94 54 d0 05 15 40 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
51 40 14 50 05 14 01 45 00 51 40 14 50 05 14 01
45 00 51 40 14 50 05 14 01 45 00 51 40 14 50 05
14 01 45 00 51 40 14 50 05 14 01 45 00 51 40 14
50 05 14 01 45 00 51 40 14 50 05 14 01 45 00 51
40 14 50 05 14 01 45 00 51 40 14 50 05 14 01 45
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
sd_setquality
0 = write(79, 9)
Size=1523, quality=9
ff d8 ff fe 28 3c 09 f2 94 54 01 45 50 14 50 05
14 01 45 00 51 40 14 50 05 14 01 45 00 51 40 14
50 05 14 01 45 00 51 40 14 50 05 14 01 45 00 51
40 14 50 05 14 01 45 00 51 40 14 50 05 14 01 45
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
sd_setquality
0 = write(79, a)
Size=1523, quality=a
ff d8 ff fe 28 3c 0a f3 54 54 01 45 50 14 50 05
14 01 45 00 51 40 14 50 05 14 01 45 00 51 40 14
50 05 14 01 45 00 51 40 14 50 05 14 01 45 00 51
40 14 50 05 14 01 45 00 51 40 14 50 05 14 01 45
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
sd_setquality
0 = write(79, b)
Size=1523, quality=b
ff d8 ff fe 28 3c 0b f3 54 54 01 45 50 14 50 05
14 01 45 00 51 40 14 50 05 14 01 45 00 51 40 14
50 05 14 01 45 00 51 40 14 50 05 14 01 45 00 51
40 14 50 05 14 01 45 00 51 40 14 50 05 14 01 45
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
sd_setquality
0 = write(79, c)
Size=1523, quality=c
ff d8 ff fe 28 3c 0c f3 f4 50 05 14 01 45 00 51
40 14 50 05 14 01 45 00 51 40 14 50 05 14 01 45
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
51 40 14 50 05 14 01 45 00 51 40 14 50 05 14 01
45 00 51 40 14 50 05 14 01 45 00 51 40 14 50 05
sd_setquality
0 = write(79, d)
Size=1523, quality=d
ff d8 ff fe 28 3c 0d f3 f4 50 05 14 01 45 00 51
40 14 50 05 14 01 45 00 51 40 14 50 05 14 01 45
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
51 40 14 50 05 14 01 45 00 51 40 14 50 05 14 01
45 00 51 40 14 50 05 14 01 45 00 51 40 14 50 05
sd_setquality
0 = write(79, e)
Size=1522, quality=e
ff d8 ff fe 28 3c 0e e2 d1 40 14 50 05 14 01 45
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
51 40 14 50 05 14 01 45 00 51 40 14 50 05 14 01
45 00 51 40 14 50 05 14 01 45 00 51 40 14 50 05
14 01 45 00 51 40 14 50 05 14 01 45 00 51 40 14
sd_setquality
0 = write(79, f)
Size=1522, quality=f
ff d8 ff fe 28 3c 0f e2 d1 40 14 50 05 14 01 45
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
51 40 14 50 05 14 01 45 00 51 40 14 50 05 14 01
45 00 51 40 14 50 05 14 01 45 00 51 40 14 50 05
14 01 45 00 51 40 14 50 05 14 01 45 00 51 40 14
sd_setquality
0 = write(79, 10)
Size=1557, quality=10
ff d8 ff fe 28 3c 10 fc 01 45 73 c1 c1 c2 f0 f8
58 58 18 18 58 78 18 18 18 74 60 e0 e0 e0 d1 4e
1e 16 0e 16 1d 2a 8c 3c 2c 2c 3a 15 34 61 e1 e1
d1 4d 34 51 45 14 aa 68 a5 2a 69 49 24 80 51 5d
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
sd_setquality
0 = write(79, 11)
Size=1557, quality=11
ff d8 ff fe 28 3c 11 fc 01 45 73 c1 c1 c2 f0 f8
58 58 18 18 58 78 18 18 18 74 60 e0 e0 e0 d1 4e
1e 16 0e 16 1d 2a 8c 3c 2c 2c 3a 15 34 61 e1 e1
d1 4d 34 51 45 14 aa 68 a5 2a 69 49 24 80 51 5d
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
sd_setquality
0 = write(79, 12)
Size=1557, quality=12
ff d8 ff fe 28 3c 12 fc 01 45 73 c1 c1 c2 f0 f8
58 58 18 18 58 78 18 18 18 74 60 e0 e0 e0 d1 4e
1e 16 0e 16 1d 2a 8c 3c 2c 2c 3a 15 34 61 e1 e1
d1 4d 34 51 45 14 aa 68 a5 2a 69 49 24 80 51 5d
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
sd_setquality
0 = write(79, 13)
Size=1557, quality=13
ff d8 ff fe 28 3c 13 fc 01 45 73 c1 c1 c2 f0 f8
58 58 18 18 58 78 18 18 18 74 60 e0 e0 e0 d1 4e
1e 16 0e 16 1d 2a 8c 3c 2c 2c 3a 15 34 61 e1 e1
d1 4d 34 51 45 14 aa 68 a5 2a 69 49 24 80 51 5d
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
sd_setquality
0 = write(79, 14)
Size=1557, quality=14
ff d8 ff fe 28 3c 14 fc 01 45 73 c1 c1 c2 f0 f8
58 58 18 18 58 78 18 18 18 74 60 e0 e0 e0 d1 4e
1e 16 0e 16 1d 2a 8c 3c 2c 2c 3a 15 34 61 e1 e1
d1 4d 34 51 45 14 aa 68 a5 2a 69 49 24 80 51 5d
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
sd_setquality
0 = write(79, 15)
Size=1557, quality=15
ff d8 ff fe 28 3c 15 fc 01 45 73 c1 c1 c2 f0 f8
58 58 18 18 58 78 18 18 18 74 60 e0 e0 e0 d1 4e
1e 16 0e 16 1d 2a 8c 3c 2c 2c 3a 15 34 61 e1 e1
d1 4d 34 51 45 14 aa 68 a5 2a 69 49 24 80 51 5d
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
sd_setquality
0 = write(79, 16)
Size=1557, quality=16
ff d8 ff fe 28 3c 16 fc 01 45 73 c1 c1 c2 f0 f8
58 58 18 18 58 78 18 18 18 74 60 e0 e0 e0 d1 4e
1e 16 0e 16 1d 2a 8c 3c 2c 2c 3a 15 34 61 e1 e1
d1 4d 34 51 45 14 aa 68 a5 2a 69 49 24 80 51 5d
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
sd_setquality
0 = write(79, 17)
Size=1557, quality=17
ff d8 ff fe 28 3c 17 fc 01 45 73 c1 c1 c2 f0 f8
58 58 18 18 58 78 18 18 18 74 60 e0 e0 e0 d1 4e
1e 16 0e 16 1d 2a 8c 3c 2c 2c 3a 15 34 61 e1 e1
d1 4d 34 51 45 14 aa 68 a5 2a 69 49 24 80 51 5d
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
sd_setquality
0 = write(79, 18)
Size=1557, quality=18
ff d8 ff fe 28 3c 18 fc 01 45 73 c1 c1 c2 f0 f8
58 58 18 18 58 78 18 18 18 74 60 e0 e0 e0 d1 4e
1e 16 0e 16 1d 2a 8c 3c 2c 2c 3a 15 34 61 e1 e1
d1 4d 34 51 45 14 aa 68 a5 2a 69 49 24 80 51 5d
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
sd_setquality
0 = write(79, 19)
Size=1557, quality=19
ff d8 ff fe 28 3c 19 fc 01 45 73 c1 c1 c2 f0 f8
58 58 18 18 58 78 18 18 18 74 60 e0 e0 e0 d1 4e
1e 16 0e 16 1d 2a 8c 3c 2c 2c 3a 15 34 61 e1 e1
d1 4d 34 51 45 14 aa 68 a5 2a 69 49 24 80 51 5d
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
sd_setquality
0 = write(79, 1a)
Size=1557, quality=1a
ff d8 ff fe 28 3c 1a fc 01 45 73 c1 c1 c2 f0 f8
58 58 18 18 58 78 18 18 18 74 60 e0 e0 e0 d1 4e
1e 16 0e 16 1d 2a 8c 3c 2c 2c 3a 15 34 61 e1 e1
d1 4d 34 51 45 14 aa 68 a5 2a 69 49 24 80 51 5d
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
sd_setquality
0 = write(79, 1b)
Size=1557, quality=1b
ff d8 ff fe 28 3c 1b fc 01 45 73 c1 c1 c2 f0 f8
58 58 18 18 58 78 18 18 18 74 60 e0 e0 e0 d1 4e
1e 16 0e 16 1d 2a 8c 3c 2c 2c 3a 15 34 61 e1 e1
d1 4d 34 51 45 14 aa 68 a5 2a 69 49 24 80 51 5d
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
sd_setquality
0 = write(79, 1c)
Size=1557, quality=1c
ff d8 ff fe 28 3c 1c fc 01 45 73 c1 c1 c2 f0 f8
58 58 18 18 58 78 18 18 18 74 60 e0 e0 e0 d1 4e
1e 16 0e 16 1d 2a 8c 3c 2c 2c 3a 15 34 61 e1 e1
d1 4d 34 51 45 14 aa 68 a5 2a 69 49 24 80 51 5d
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
sd_setquality
0 = write(79, 1d)
Size=1557, quality=1d
ff d8 ff fe 28 3c 1d fc 01 45 73 c1 c1 c2 f0 f8
58 58 18 18 58 78 18 18 18 74 60 e0 e0 e0 d1 4e
1e 16 0e 16 1d 2a 8c 3c 2c 2c 3a 15 34 61 e1 e1
d1 4d 34 51 45 14 aa 68 a5 2a 69 49 24 80 51 5d
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
sd_setquality
0 = write(79, 1e)
Size=1557, quality=1e
ff d8 ff fe 28 3c 1e fc 01 45 73 c1 c1 c2 f0 f8
58 58 18 18 58 78 18 18 18 74 60 e0 e0 e0 d1 4e
1e 16 0e 16 1d 2a 8c 3c 2c 2c 3a 15 34 61 e1 e1
d1 4d 34 51 45 14 aa 68 a5 2a 69 49 24 80 51 5d
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00
sd_setquality
0 = write(79, 1f)
Size=1557, quality=1f
ff d8 ff fe 28 3c 1f fc 01 45 73 c1 c1 c2 f0 f8
58 58 18 18 58 78 18 18 18 74 60 e0 e0 e0 d1 4e
1e 16 0e 16 1d 2a 8c 3c 2c 2c 3a 15 34 61 e1 e1
d1 4d 34 51 45 14 aa 68 a5 2a 69 49 24 80 51 5d
00 51 40 14 50 05 14 01 45 00 51 40 14 50 05 14
01 45 00 51 40 14 50 05 14 01 45 00 51 40 14 50
05 14 01 45 00 51 40 14 50 05 14 01 45 00 51 40
14 50 05 14 01 45 00 51 40 14 50 05 14 01 45 00



> 
> is the frame header, so at offset 18, the JPEG streams starts.
> And I am 100% sure that the stream is JPEG coded.
> 
>>> Comments?
>> It would be interesting to know if somebody well versed in windows programming
>> could write a program to get JPEG frames out of the driver directly (provided
>> this is possible of course), if the image part of such a frame matches the data
>> seen on USB, we would then have the Huffman/DQT tables.
> 
> Might be possible for some one you knows how to interact with the Windoz 
> driver, I don't.
> Or you can get the sensor in saturation (only white picture), then you 
> know how the picture should look like. When the whole picture is only 
> white, each MCU has to be the same ;-)
> 
>> At the moment I'm stuck, since I see no way to find out what Huffman/DQT tables
>> that are used.
> 
> I found some interesting file in a TP6810 folder on my Windoz box after 
> I installed the driver. See Attachment ;-)
> 
> Hope this helps, I will study some more....
> 
> Thomas
> 
> 


-- 
Anders Blomdell                  Email: anders.blomdell@control.lth.se
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Topro 6800 driver

[Thomas Kaiser]

Hello Anders

Anders Blomdell wrote:
 > When I set the RGB/YUV gains to zero, I get:
 >> 5a ff d8 ff fe 14 1e 00 fd f5 45 7e e8 f8 b8 df 49 57
 >      ff d8 ff fe 28 3c 01 fc ff 00 45 66 9a 69 a2 95 4d 2a 12 d1 00 a2 b4
 >
 > followed by a big number of repeated (0x152c bytes total):
 >
 >   02 8a 00 a2 80 28 a0 0a 28
 >
 > and ending with:
 >
 >   02 8a 00 a2 80 ff d9
 >
 > In binary the repeating sequence can be diveded in half:
 >
 >   0000 0010 1000 1010 0000 0000 1010 0010 1000
 >   0000 0010 1000 1010 0000 0000 1010 0010 1000

That is more less the same sequence I get when I do my saturation stuff 
(white picture) :-) . As of coincidence, the same Bit pattern is found 
in the PAC7311 when I do the saturation stuff. And I know the PAC7311 
stream. That's the reason why I wrote I am 100% sure that this is JPEG 
;-) PAC7311 has a special marker between each MCU which has to be 
removed. I don't see such thing in this stream. So it must be pure JPEG.

 >
 > Which approximately adds up to 1200 repetitions of this bitpattern 
2*(0x152c -
 > 23)/9.
 >
 > And a 640*480 image divided in 8*8 subframes gives (640*480/(8*8)) 1200
 > subframes, so now the question is how much info about the Huffman 
table this
 > gives us?

I think nothing :-( , but you found the MCUs :-) As it looks quite the 
same as on the PAC7311, why not just try the Huffman table from the PAC7311?

The frame header on the PAC7311 is ff ff 00 ff 96 62 + 1 Byte MCU Marker 
44, then the JPEG data starts. Look at this:
ff ff 00 ff 96 62 44 f7 ca 28 01 10 a2 80 11 0a 28 01 10 a2 80 11 0a 28
Side note: the first 01 10 is the MCU marker 44 embedded in the Bit stream.

TP8610, first few Bytes with frame header:
5a ff d8 ff fe 14 1e 00 fd f5 45 7e e8 f8 b8 df 49 57 ab 0a 28 73 0a 28 
02 8a 00 a2 80 28 a0 0a

Therefor I think this is the start of the stream:
ab 0a 28 73 0a 28 02 8a 00 a2 80 28 a0 0a

Don't know why we have 73 in between :-(

Hope this one helps....

Thomas

Re: Topro 6800 driver

[Anders Blomdell]

Thomas Kaiser wrote:
> Hello Anders
> 
> Anders Blomdell wrote:
>  > When I set the RGB/YUV gains to zero, I get:
>  >> 5a ff d8 ff fe 14 1e 00 fd f5 45 7e e8 f8 b8 df 49 57
>  >      ff d8 ff fe 28 3c 01 fc ff 00 45 66 9a 69 a2 95 4d 2a 12 d1 00 a2 b4
>  >
>  > followed by a big number of repeated (0x152c bytes total):
>  >
>  >   02 8a 00 a2 80 28 a0 0a 28
>  >
>  > and ending with:
>  >
>  >   02 8a 00 a2 80 ff d9
>  >
>  > In binary the repeating sequence can be diveded in half:
>  >
>  >   0000 0010 1000 1010 0000 0000 1010 0010 1000
>  >   0000 0010 1000 1010 0000 0000 1010 0010 1000
> 
> That is more less the same sequence I get when I do my saturation stuff 
> (white picture) :-) . As of coincidence, the same Bit pattern is found 
> in the PAC7311 when I do the saturation stuff. And I know the PAC7311 
> stream. That's the reason why I wrote I am 100% sure that this is JPEG 
> ;-) PAC7311 has a special marker between each MCU which has to be 
> removed. I don't see such thing in this stream. So it must be pure JPEG.
> 
>  >
>  > Which approximately adds up to 1200 repetitions of this bitpattern 
> 2*(0x152c -
>  > 23)/9.
>  >
>  > And a 640*480 image divided in 8*8 subframes gives (640*480/(8*8)) 1200
>  > subframes, so now the question is how much info about the Huffman 
> table this
>  > gives us?
> 
> I think nothing :-( , but you found the MCUs :-) As it looks quite the 
> same as on the PAC7311, why not just try the Huffman table from the PAC7311?
Which seems to be encoded in the stream and not defined in the sourcecode (but
I'm tired, so I might well be wrong). Do you think you could extract it somehow?

> 
> The frame header on the PAC7311 is ff ff 00 ff 96 62 + 1 Byte MCU Marker 
> 44, then the JPEG data starts. Look at this:
> ff ff 00 ff 96 62 44 f7 ca 28 01 10 a2 80 11 0a 28 01 10 a2 80 11 0a 28
> Side note: the first 01 10 is the MCU marker 44 embedded in the Bit stream.
> 
> TP8610, first few Bytes with frame header:
> 5a ff d8 ff fe 14 1e 00 fd f5 45 7e e8 f8 b8 df 49 57 ab 0a 28 73 0a 28 
> 02 8a 00 a2 80 28 a0 0a
> 
> Therefor I think this is the start of the stream:
> ab 0a 28 73 0a 28 02 8a 00 a2 80 28 a0 0a
> 
> Don't know why we have 73 in between :-(
> 
> Hope this one helps....
/Anders
-- 
Anders Blomdell                  Email: anders.blomdell@control.lth.se
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

Mail list, Is WIKI up to date?

[Thomas Kaiser]

Anders Blomdell wrote:
> Thomas Kaiser wrote:
>> Hello Anders
>>
>> You should send your messages to linux-media@vger.kernel.org. 
>> video4linux-list@redhat.com is deprecated. The new mail list for V4L is 
>>   linux-media@vger.kernel.org.
>>
>> I just send my reply by mistake to video4linux-list@redhat.com because I 
>> just hit replay all without checking the Email address.
> And so did I, got the wrong adress first time since I followed:
> 
>   http://www.linuxtv.org/v4lwiki/index.php/Main_Page
> 
> guess I can't expect Google to find the right page always...
> 
> /Anders
> 

Looks like the WIKI page you found is not up to date.

Thomas

Re: Topro 6800 driver

[Thomas Kaiser]

Hello Anders

Anders Blomdell wrote:
> Thomas Kaiser wrote:
>>  > And a 640*480 image divided in 8*8 subframes gives (640*480/(8*8)) 1200
>>  > subframes, so now the question is how much info about the Huffman 
>> table this
>>  > gives us?
>>
>> I think nothing :-( , but you found the MCUs :-) As it looks quite the 
>> same as on the PAC7311, why not just try the Huffman table from the PAC7311?
> Which seems to be encoded in the stream and not defined in the sourcecode (but
> I'm tired, so I might well be wrong). Do you think you could extract it somehow?

I think it should be in the gspca source or in the v4l_library? I didn't 
follow gspca code and v4l_library code lately. Anyway PAC7311 is working 
AFAIK.

I'll check and try.

Thomas

Re: Topro 6800 driver

[Anders Blomdell]

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

Thomas Kaiser wrote:
> Hello Anders
> 
> Anders Blomdell wrote:
>> Thomas Kaiser wrote:
>>> Hello Anders
>>>
>>> Anders Blomdell wrote:
>>>> Thomas Kaiser wrote:
>>>> which indicates that both DQT and Huffman is present in the stream.
>>> It is _not_ present in the stream.
>> Then I don't understand where it comes from...
> 
> I do, because I implemented it into gspca V1 ;-)
> 
> The cam only streams the picture data. To code the stream a _static_ 
> JPEG header is used. The cam and the driver know this header. Therefor, 
> the driver just builds a valid JPEG image with the known header and the 
> stream from the cam.
> 
>>> Anyway I did not found time to try with the JPEG header from PAC7311.
>>> And I have to apologize because I did not tell you what work I did for 
>>> the PAC7311. See this: http://www.kaiser-linux.li/index.php?title=PAC7311
>>>
>>> You should find the PAC7311 JPEG header in this source:
>>> http://www.kaiser-linux.li/files/PAC7311/gspcav1-PAC7311-20070425.tar.gz
>> Will look into it.
> 
> Check decoder/gspcadecoder.c and search for pac7311_jpeg_header.
> 
>>>>> Anyway PAC7311 is working AFAIK.
>>>> Which doesn't contradict that it's encoded in the stream from the camera.
>>> BTW, can you send me the header and some Bytes from your stream, the 02 
>>> 8a 00 a2 80 28 a0 0a 28 thing. As ASCII in Email is OK.
>> The entire (white?) image is in the attachment (QUALITY=0).
> 
> I tried the PAC7311 header. See the result in the attached files :-(
Thanks for trying though.

I tested some more, and by starting at offset 7 (based on that ff00 indicates
jpeg stream, and that byte 8 differs between quality 1 & 2, [byte 7 follows
quality])

  Size=152d, quality=1
  ff d8 ff fe 28 3c 01 fc ff 00 45 66 9a 69 a2 95
  ...
  Size=152a, quality=2
  ff d8 ff fe 28 3c 02 f9 55 15 29 a5 52 95 34 a8

I get img0 with the DQT you found on your installation disk, while img1 is what
you get with the standard DQT. Could it be that yuv=0,0,0 implies a black image?
Length is still bogus though, and with yuv != 0 I still get garbage, so I assume
there is some problem with the huffman coding still!

I guess what I have to do, is to transform a yuv=0,0,0 image using the 17
different DQT tables you found and try to generate a huffman table that matches
that data and the 17 different samples I have (of course this table will have
unknowns, but it might be a starting point).

/Anders

-- 
Anders Blomdell                  Email: anders.blomdell@control.lth.se
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

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

[-- Attachment #3: img1.jpg --]
[-- Type: image/jpeg, Size: 6017 bytes --]

Re: Topro 6800 driver

[Thomas Kaiser]

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

Anders Blomdell wrote:
> Thomas Kaiser wrote:
>> Hello Anders
>>
>> Anders Blomdell wrote:
>>> Thomas Kaiser wrote:
>>>> Hello Anders
>>>>
>>>> Anders Blomdell wrote:
>>>>> Thomas Kaiser wrote:
>>>>> which indicates that both DQT and Huffman is present in the stream.
>>>> It is _not_ present in the stream.
>>> Then I don't understand where it comes from...
>> I do, because I implemented it into gspca V1 ;-)
>>
>> The cam only streams the picture data. To code the stream a _static_ 
>> JPEG header is used. The cam and the driver know this header. Therefor, 
>> the driver just builds a valid JPEG image with the known header and the 
>> stream from the cam.
>>
>>>> Anyway I did not found time to try with the JPEG header from PAC7311.
>>>> And I have to apologize because I did not tell you what work I did for 
>>>> the PAC7311. See this: http://www.kaiser-linux.li/index.php?title=PAC7311
>>>>
>>>> You should find the PAC7311 JPEG header in this source:
>>>> http://www.kaiser-linux.li/files/PAC7311/gspcav1-PAC7311-20070425.tar.gz
>>> Will look into it.
>> Check decoder/gspcadecoder.c and search for pac7311_jpeg_header.
>>
>>>>>> Anyway PAC7311 is working AFAIK.
>>>>> Which doesn't contradict that it's encoded in the stream from the camera.
>>>> BTW, can you send me the header and some Bytes from your stream, the 02 
>>>> 8a 00 a2 80 28 a0 0a 28 thing. As ASCII in Email is OK.
>>> The entire (white?) image is in the attachment (QUALITY=0).
>> I tried the PAC7311 header. See the result in the attached files :-(
> Thanks for trying though.
> 
> I tested some more, and by starting at offset 7 (based on that ff00 indicates
> jpeg stream, and that byte 8 differs between quality 1 & 2, [byte 7 follows
> quality])
> 
>   Size=152d, quality=1
>   ff d8 ff fe 28 3c 01 fc ff 00 45 66 9a 69 a2 95
>   ...
>   Size=152a, quality=2
>   ff d8 ff fe 28 3c 02 f9 55 15 29 a5 52 95 34 a8
> 
> I get img0 with the DQT you found on your installation disk, while img1 is what
> you get with the standard DQT. Could it be that yuv=0,0,0 implies a black image?
> Length is still bogus though, and with yuv != 0 I still get garbage, so I assume
> there is some problem with the huffman coding still!
> 
> I guess what I have to do, is to transform a yuv=0,0,0 image using the 17
> different DQT tables you found and try to generate a huffman table that matches
> that data and the 17 different samples I have (of course this table will have
> unknowns, but it might be a starting point).
> 
> /Anders
> 

Hello Anders

What is the resolution of your black frame?

I changed the component subsampling to 4:2:0 and the image size to 
320x240. No your black frame looks OK :-)

The black one is frameA-1.jpg and I attached my almost white one 
frame5-1.jpg.

Thomas


[-- Attachment #2: frame5-1.jpg --]
[-- Type: image/jpeg, Size: 2140 bytes --]

[-- Attachment #3: frameA-1.jpg --]
[-- Type: image/jpeg, Size: 6020 bytes --]

Re: Topro 6800 driver [JPEG decoding solved]

[Thomas Kaiser]

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

Hello Anders

Good news, I could decode a frame which I extracted from the usbsnoobs I 
did :-). See attached picture frame3-03.jpg. It uses the quality 0.

Your black frame you sent me gets now correctly decode, too (frameA-01.jpg)

I found the Huffman table in the Windoz driver file (TP6810.sys) at 
offset 0x2a59c. The QTable which I found in a text file on my Windoz box 
can be found in this driver file, also.

I attached some binary files which I used to build the 2 attached jpeg.

For example use:
cat FFD8-Q0-320x240.bin huffman1.bin FFDA.bin frame3-3.bin >frame3-03.jpg
to make the picture frame3-03.jpg.

This information should the cam get going in Linux ;-)

Happy Hacking,

Thomas

PS: I sent this to the linux-media mail list, because somebody else is 
interested about this information, too.


[-- Attachment #2: frame3-03.jpg --]
[-- Type: image/jpeg, Size: 11452 bytes --]

[-- Attachment #3: frameA-01.jpg --]
[-- Type: image/jpeg, Size: 5952 bytes --]

[-- Attachment #4: FFD8-Q0-320x240.bin --]
[-- Type: application/octet-stream, Size: 160 bytes --]

[-- Attachment #5: FFD8-Q0-640x480.bin --]
[-- Type: application/octet-stream, Size: 160 bytes --]

[-- Attachment #6: FFD8-Q1-320x280.bin --]
[-- Type: application/octet-stream, Size: 160 bytes --]

[-- Attachment #7: FFD8-Q1-640x480.bin --]
[-- Type: application/octet-stream, Size: 160 bytes --]

[-- Attachment #8: FFDA.bin --]
[-- Type: application/octet-stream, Size: 14 bytes --]

[-- Attachment #9: huffman1.bin --]
[-- Type: application/octet-stream, Size: 352 bytes --]

[-- Attachment #10: frame3-3.bin --]
[-- Type: application/octet-stream, Size: 10926 bytes --]

Re: Topro 6800 driver [JPEG decoding solved]

[Thomas Kaiser]

Thomas Kaiser wrote:
> Hello Anders
> 
> Good news, I could decode a frame which I extracted from the usbsnoobs I 
> did :-). See attached picture frame3-03.jpg. It uses the quality 0.
> 
> Your black frame you sent me gets now correctly decode, too (frameA-01.jpg)
> 
> I found the Huffman table in the Windoz driver file (TP6810.sys) at 
> offset 0x2a59c. The QTable which I found in a text file on my Windoz box 
> can be found in this driver file, also.
> 
> I attached some binary files which I used to build the 2 attached jpeg.
> 
> For example use:
> cat FFD8-Q0-320x240.bin huffman1.bin FFDA.bin frame3-3.bin >frame3-03.jpg
> to make the picture frame3-03.jpg.
> 
> This information should the cam get going in Linux ;-)
> 
> Happy Hacking,
> 
> Thomas
> 
> PS: I sent this to the linux-media mail list, because somebody else is 
> interested about this information, too.
> 

Just some comments about the observation you made on the frame header:

ff d8 ff fe 28 3c 01

- Byte 6: Yes, it is the current quality setting
- Byte 4 & 5: I think it is related to resolution. My snoops were done with 320x240 (0x141e) and Anders were made with 640x480 (0x283c), twice as big!
- The rest is static

Thomas

Re: Topro 6800 driver [JPEG decoding solved]

[Thomas Champagne]

Youhhhouuu ! You are the King of the snoop ! How did you find an
huffman table in the middle of a file ?
But, I don't have received any file with the mail ? Have you correctly
attached the files in the mail ?
Thank you again for this good news !
Thomas

2009/3/18 Thomas Kaiser <v4l@kaiser-linux.li>:
> Thomas Kaiser wrote:
>>
>> Hello Anders
>>
>> Good news, I could decode a frame which I extracted from the usbsnoobs I
>> did :-). See attached picture frame3-03.jpg. It uses the quality 0.
>>
>> Your black frame you sent me gets now correctly decode, too
>> (frameA-01.jpg)
>>
>> I found the Huffman table in the Windoz driver file (TP6810.sys) at offset
>> 0x2a59c. The QTable which I found in a text file on my Windoz box can be
>> found in this driver file, also.
>>
>> I attached some binary files which I used to build the 2 attached jpeg.
>>
>> For example use:
>> cat FFD8-Q0-320x240.bin huffman1.bin FFDA.bin frame3-3.bin >frame3-03.jpg
>> to make the picture frame3-03.jpg.
>>
>> This information should the cam get going in Linux ;-)
>>
>> Happy Hacking,
>>
>> Thomas
>>
>> PS: I sent this to the linux-media mail list, because somebody else is
>> interested about this information, too.
>>
>
> Just some comments about the observation you made on the frame header:
>
> ff d8 ff fe 28 3c 01
>
> - Byte 6: Yes, it is the current quality setting
> - Byte 4 & 5: I think it is related to resolution. My snoops were done with
> 320x240 (0x141e) and Anders were made with 640x480 (0x283c), twice as big!
> - The rest is static
>
> Thomas
>
>

Re: Topro 6800 driver [JPEG decoding solved]

[Anders Blomdell]

Thomas Kaiser wrote:
> Thomas Kaiser wrote:
>> Hello Anders
>>
>> Good news, I could decode a frame which I extracted from the usbsnoobs I 
>> did :-). See attached picture frame3-03.jpg. It uses the quality 0.
>>
>> Your black frame you sent me gets now correctly decode, too (frameA-01.jpg)
>>
>> I found the Huffman table in the Windoz driver file (TP6810.sys) at 
>> offset 0x2a59c. The QTable which I found in a text file on my Windoz box 
>> can be found in this driver file, also.
>>
>> I attached some binary files which I used to build the 2 attached jpeg.
>>
>> For example use:
>> cat FFD8-Q0-320x240.bin huffman1.bin FFDA.bin frame3-3.bin >frame3-03.jpg
>> to make the picture frame3-03.jpg.
>>
>> This information should the cam get going in Linux ;-)
>>
>> Happy Hacking,
>>
>> Thomas
>>
>> PS: I sent this to the linux-media mail list, because somebody else is 
>> interested about this information, too.
>>
> 
> Just some comments about the observation you made on the frame header:
> 
> ff d8 ff fe 28 3c 01
> 
> - Byte 6: Yes, it is the current quality setting
> - Byte 4 & 5: I think it is related to resolution. My snoops were done with 320x240 (0x141e) and Anders were made with 640x480 (0x283c), twice as big!
> - The rest is static

OK,

Things are looking brighter, I can capture single images with a slightly
modified uvccapture and streaming with mplayer (with bogus colors, but
identifiable image data)

ucview doesn't work though; complains on huffman, but I'll look into colors first...

Regards

/Anders


-- 
Anders Blomdell                  Email: anders.blomdell@control.lth.se
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden