Re: Topro 6800 driver

[Anders Blomdell <anders.blomdell@control.lth.se>]

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