Re: Topro 6800 driver

From: Anders Blomdell <anders.blomdell@control.lth.se>
To: Thomas Kaiser <v4l@kaiser-linux.li>
Cc: Linux Media <linux-media@vger.kernel.org>
Subject: Re: Topro 6800 driver
Date: Wed, 11 Mar 2009 16:09:15 +0100	[thread overview]
Message-ID: <49B7D41B.4040801@control.lth.se> (raw)
In-Reply-To: <49B6A495.9060204@kaiser-linux.li>

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