* Topro 6800 driver
@ 2009-02-27 22:15 Anders Blomdell
2009-02-28 10:31 ` Jean-Francois Moine
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: Anders Blomdell @ 2009-02-27 22:15 UTC (permalink / raw)
To: video4linux-list
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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Topro 6800 driver 2009-02-27 22:15 Topro 6800 driver Anders Blomdell @ 2009-02-28 10:31 ` Jean-Francois Moine 2009-02-28 15:11 ` Anders Blomdell 2009-02-28 11:54 ` Thomas Kaiser [not found] ` <49B194A7.4030808@kaiser-linux.li> 2 siblings, 1 reply; 22+ messages in thread From: Jean-Francois Moine @ 2009-02-28 10:31 UTC (permalink / raw) To: Anders Blomdell, Thomas Champagne, Linux Media 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Topro 6800 driver 2009-02-28 10:31 ` Jean-Francois Moine @ 2009-02-28 15:11 ` Anders Blomdell 2009-02-28 15:54 ` Thomas Kaiser ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Anders Blomdell @ 2009-02-28 15:11 UTC (permalink / raw) To: Jean-Francois Moine; +Cc: Thomas Champagne, Linux Media, Thomas Kaiser 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Topro 6800 driver 2009-02-28 15:11 ` Anders Blomdell @ 2009-02-28 15:54 ` Thomas Kaiser 2009-03-01 7:26 ` Jean-Francois Moine 2009-03-01 16:33 ` Thomas Champagne 2 siblings, 0 replies; 22+ messages in thread From: Thomas Kaiser @ 2009-02-28 15:54 UTC (permalink / raw) To: Anders Blomdell; +Cc: Jean-Francois Moine, Thomas Champagne, Linux Media 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Topro 6800 driver 2009-02-28 15:11 ` Anders Blomdell 2009-02-28 15:54 ` Thomas Kaiser @ 2009-03-01 7:26 ` Jean-Francois Moine 2009-03-01 16:33 ` Thomas Champagne 2 siblings, 0 replies; 22+ messages in thread From: Jean-Francois Moine @ 2009-03-01 7:26 UTC (permalink / raw) To: Anders Blomdell; +Cc: Thomas Champagne, Linux Media, Thomas Kaiser 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Topro 6800 driver 2009-02-28 15:11 ` Anders Blomdell 2009-02-28 15:54 ` Thomas Kaiser 2009-03-01 7:26 ` Jean-Francois Moine @ 2009-03-01 16:33 ` Thomas Champagne 2009-03-02 13:20 ` Jean-Francois Moine 2 siblings, 1 reply; 22+ messages in thread From: Thomas Champagne @ 2009-03-01 16:33 UTC (permalink / raw) To: Anders Blomdell; +Cc: Jean-Francois Moine, Linux Media, Thomas Kaiser 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 > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Topro 6800 driver 2009-03-01 16:33 ` Thomas Champagne @ 2009-03-02 13:20 ` Jean-Francois Moine 2009-03-02 16:58 ` Anders Blomdell 0 siblings, 1 reply; 22+ messages in thread From: Jean-Francois Moine @ 2009-03-02 13:20 UTC (permalink / raw) To: Thomas Champagne; +Cc: Anders Blomdell, Linux Media, Thomas Kaiser 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Topro 6800 driver 2009-03-02 13:20 ` Jean-Francois Moine @ 2009-03-02 16:58 ` Anders Blomdell 0 siblings, 0 replies; 22+ messages in thread From: Anders Blomdell @ 2009-03-02 16:58 UTC (permalink / raw) To: Jean-Francois Moine; +Cc: Thomas Champagne, Linux Media, Thomas Kaiser 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Topro 6800 driver 2009-02-27 22:15 Topro 6800 driver Anders Blomdell 2009-02-28 10:31 ` Jean-Francois Moine @ 2009-02-28 11:54 ` Thomas Kaiser [not found] ` <49B194A7.4030808@kaiser-linux.li> 2 siblings, 0 replies; 22+ messages in thread From: Thomas Kaiser @ 2009-02-28 11:54 UTC (permalink / raw) To: Anders Blomdell; +Cc: video4linux-list, linux-media 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <49B194A7.4030808@kaiser-linux.li>]
* Re: Topro 6800 driver [not found] ` <49B194A7.4030808@kaiser-linux.li> @ 2009-03-09 12:10 ` Anders Blomdell [not found] ` <49B50E16.8080703@kaiser-linux.li> 0 siblings, 1 reply; 22+ messages in thread From: Anders Blomdell @ 2009-03-09 12:10 UTC (permalink / raw) To: Thomas Kaiser; +Cc: video4linux-list 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <49B50E16.8080703@kaiser-linux.li>]
* Re: Topro 6800 driver [not found] ` <49B50E16.8080703@kaiser-linux.li> @ 2009-03-09 14:06 ` Anders Blomdell 2009-03-09 18:51 ` Anders Blomdell 1 sibling, 0 replies; 22+ messages in thread From: Anders Blomdell @ 2009-03-09 14:06 UTC (permalink / raw) To: Thomas Kaiser; +Cc: video4linux-list 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Topro 6800 driver [not found] ` <49B50E16.8080703@kaiser-linux.li> 2009-03-09 14:06 ` Anders Blomdell @ 2009-03-09 18:51 ` Anders Blomdell 2009-03-09 20:10 ` Thomas Kaiser [not found] ` <49B5786D.4060102@kaiser-linux.li> 1 sibling, 2 replies; 22+ messages in thread From: Anders Blomdell @ 2009-03-09 18:51 UTC (permalink / raw) To: Thomas Kaiser; +Cc: video4linux-list 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Topro 6800 driver 2009-03-09 18:51 ` Anders Blomdell @ 2009-03-09 20:10 ` Thomas Kaiser 2009-03-09 20:29 ` Anders Blomdell [not found] ` <49B5786D.4060102@kaiser-linux.li> 1 sibling, 1 reply; 22+ messages in thread From: Thomas Kaiser @ 2009-03-09 20:10 UTC (permalink / raw) To: Anders Blomdell; +Cc: Linux Media 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Topro 6800 driver 2009-03-09 20:10 ` Thomas Kaiser @ 2009-03-09 20:29 ` Anders Blomdell 2009-03-09 20:43 ` Thomas Kaiser 0 siblings, 1 reply; 22+ messages in thread From: Anders Blomdell @ 2009-03-09 20:29 UTC (permalink / raw) To: Thomas Kaiser; +Cc: Linux Media 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Topro 6800 driver 2009-03-09 20:29 ` Anders Blomdell @ 2009-03-09 20:43 ` Thomas Kaiser [not found] ` <49B62023.2090206@control.lth.se> 0 siblings, 1 reply; 22+ messages in thread From: Thomas Kaiser @ 2009-03-09 20:43 UTC (permalink / raw) To: Anders Blomdell; +Cc: Linux Media 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <49B62023.2090206@control.lth.se>]
[parent not found: <49B65BA7.6070700@kaiser-linux.li>]
[parent not found: <49B68F34.60802@control.lth.se>]
[parent not found: <49B6A495.9060204@kaiser-linux.li>]
* Re: Topro 6800 driver [not found] ` <49B6A495.9060204@kaiser-linux.li> @ 2009-03-11 15:09 ` Anders Blomdell 2009-03-11 19:11 ` Thomas Kaiser 2009-03-17 20:13 ` Topro 6800 driver [JPEG decoding solved] Thomas Kaiser 0 siblings, 2 replies; 22+ messages in thread From: Anders Blomdell @ 2009-03-11 15:09 UTC (permalink / raw) To: Thomas Kaiser; +Cc: Linux Media [-- 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 --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Topro 6800 driver 2009-03-11 15:09 ` Anders Blomdell @ 2009-03-11 19:11 ` Thomas Kaiser 2009-03-17 20:13 ` Topro 6800 driver [JPEG decoding solved] Thomas Kaiser 1 sibling, 0 replies; 22+ messages in thread From: Thomas Kaiser @ 2009-03-11 19:11 UTC (permalink / raw) To: Anders Blomdell; +Cc: Linux Media [-- 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 --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Topro 6800 driver [JPEG decoding solved] 2009-03-11 15:09 ` Anders Blomdell 2009-03-11 19:11 ` Thomas Kaiser @ 2009-03-17 20:13 ` Thomas Kaiser 2009-03-18 20:10 ` Thomas Kaiser 1 sibling, 1 reply; 22+ messages in thread From: Thomas Kaiser @ 2009-03-17 20:13 UTC (permalink / raw) To: Anders Blomdell; +Cc: Linux Media [-- 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 --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Topro 6800 driver [JPEG decoding solved] 2009-03-17 20:13 ` Topro 6800 driver [JPEG decoding solved] Thomas Kaiser @ 2009-03-18 20:10 ` Thomas Kaiser 2009-03-18 21:42 ` Thomas Champagne 2009-03-25 17:10 ` Anders Blomdell 0 siblings, 2 replies; 22+ messages in thread From: Thomas Kaiser @ 2009-03-18 20:10 UTC (permalink / raw) To: Anders Blomdell; +Cc: Linux Media, Thomas Champagne 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Topro 6800 driver [JPEG decoding solved] 2009-03-18 20:10 ` Thomas Kaiser @ 2009-03-18 21:42 ` Thomas Champagne 2009-03-25 17:10 ` Anders Blomdell 1 sibling, 0 replies; 22+ messages in thread From: Thomas Champagne @ 2009-03-18 21:42 UTC (permalink / raw) To: Thomas Kaiser; +Cc: Anders Blomdell, Linux Media 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 > > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Topro 6800 driver [JPEG decoding solved] 2009-03-18 20:10 ` Thomas Kaiser 2009-03-18 21:42 ` Thomas Champagne @ 2009-03-25 17:10 ` Anders Blomdell 1 sibling, 0 replies; 22+ messages in thread From: Anders Blomdell @ 2009-03-25 17:10 UTC (permalink / raw) To: Thomas Kaiser; +Cc: Linux Media, Thomas Champagne 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <49B5786D.4060102@kaiser-linux.li>]
[parent not found: <49B57CB6.8000402@control.lth.se>]
* Mail list, Is WIKI up to date? [not found] ` <49B57CB6.8000402@control.lth.se> @ 2009-03-09 20:38 ` Thomas Kaiser 0 siblings, 0 replies; 22+ messages in thread From: Thomas Kaiser @ 2009-03-09 20:38 UTC (permalink / raw) To: Anders Blomdell; +Cc: Linux Media 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
![[-- Attachment #2: img0.jpg --] [-- Type: image/jpeg, Size: 6017 bytes --]](../../49B7D41B.4040801@control.lth.se/2-img0.jpg){kind=link}
![[-- Attachment #3: img1.jpg --] [-- Type: image/jpeg, Size: 6017 bytes --]](../../49B7D41B.4040801@control.lth.se/3-img1.jpg){kind=link}
![[-- Attachment #2: frame5-1.jpg --] [-- Type: image/jpeg, Size: 2140 bytes --]](../../49B80CDA.8000903@kaiser-linux.li/2-frame5-1.jpg){kind=link}
![[-- Attachment #3: frameA-1.jpg --] [-- Type: image/jpeg, Size: 6020 bytes --]](../../49B80CDA.8000903@kaiser-linux.li/3-frameA-1.jpg){kind=link}
![[-- Attachment #2: frame3-03.jpg --] [-- Type: image/jpeg, Size: 11452 bytes --]](../../49C00484.7060601@kaiser-linux.li/2-frame3-03.jpg){kind=link}
![[-- Attachment #3: frameA-01.jpg --] [-- Type: image/jpeg, Size: 5952 bytes --]](../../49C00484.7060601@kaiser-linux.li/3-frameA-01.jpg){kind=link}
end of thread, other threads:[~2009-03-25 17:10 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-02-27 22:15 Topro 6800 driver Anders Blomdell
2009-02-28 10:31 ` Jean-Francois Moine
2009-02-28 15:11 ` Anders Blomdell
2009-02-28 15:54 ` Thomas Kaiser
2009-03-01 7:26 ` Jean-Francois Moine
2009-03-01 16:33 ` Thomas Champagne
2009-03-02 13:20 ` Jean-Francois Moine
2009-03-02 16:58 ` Anders Blomdell
2009-02-28 11:54 ` Thomas Kaiser
[not found] ` <49B194A7.4030808@kaiser-linux.li>
2009-03-09 12:10 ` Anders Blomdell
[not found] ` <49B50E16.8080703@kaiser-linux.li>
2009-03-09 14:06 ` Anders Blomdell
2009-03-09 18:51 ` Anders Blomdell
2009-03-09 20:10 ` Thomas Kaiser
2009-03-09 20:29 ` Anders Blomdell
2009-03-09 20:43 ` Thomas Kaiser
[not found] ` <49B62023.2090206@control.lth.se>
[not found] ` <49B65BA7.6070700@kaiser-linux.li>
[not found] ` <49B68F34.60802@control.lth.se>
[not found] ` <49B6A495.9060204@kaiser-linux.li>
2009-03-11 15:09 ` Anders Blomdell
2009-03-11 19:11 ` Thomas Kaiser
2009-03-17 20:13 ` Topro 6800 driver [JPEG decoding solved] Thomas Kaiser
2009-03-18 20:10 ` Thomas Kaiser
2009-03-18 21:42 ` Thomas Champagne
2009-03-25 17:10 ` Anders Blomdell
[not found] ` <49B5786D.4060102@kaiser-linux.li>
[not found] ` <49B57CB6.8000402@control.lth.se>
2009-03-09 20:38 ` Mail list, Is WIKI up to date? Thomas Kaiser
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.