Re: Topro 6800 driver

[Thomas Kaiser <v4l@kaiser-linux.li>]

[-- 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 --]