linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Kaiser <v4l@kaiser-linux.li>
To: Anders Blomdell <anders.blomdell@control.lth.se>
Cc: Jean-Francois Moine <moinejf@free.fr>,
	Thomas Champagne <lafeuil@gmail.com>,
	Linux Media <linux-media@vger.kernel.org>
Subject: Re: Topro 6800 driver
Date: Sat, 28 Feb 2009 16:54:08 +0100	[thread overview]
Message-ID: <49A95E20.9000104@kaiser-linux.li> (raw)
In-Reply-To: <49A95428.1090306@control.lth.se>

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

  reply	other threads:[~2009-02-28 15:54 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2009-03-27 18:06 topro 6800 driver Andy Shevchenko
     [not found] ` <49CD2868.9080502@kaiser-linux.li>
     [not found]   ` <5ec8ebd50903311144h316c7e3bmd30ce2c3d5a268ee@mail.gmail.com>
     [not found]     ` <49D4EAB2.4090206@control.lth.se>
2009-04-03 20:07       ` Anders Blomdell
2009-04-03 20:54         ` Erik Andrén
2009-04-04 11:29           ` Anders Blomdell
2009-04-05 17:36             ` Jean-Francois Moine
2009-04-20 15:37               ` Thomas Champagne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49A95E20.9000104@kaiser-linux.li \
    --to=v4l@kaiser-linux.li \
    --cc=anders.blomdell@control.lth.se \
    --cc=lafeuil@gmail.com \
    --cc=linux-media@vger.kernel.org \
    --cc=moinejf@free.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).