Re: Topro 6800 driver

Thomas Kaiser wrote:

Hello Anders

Anders Blomdell wrote:

quoted

quoted

quoted

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.

quoted

quoted

- 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

quoted

quoted

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

quoted

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

quoted

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?

quoted

quoted

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

quoted

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