public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Kaiser <v4l@kaiser-linux.li>
To: "Németh Márton" <nm127@freemail.hu>
Cc: Hans de Goede <hdegoede@redhat.com>,
	V4L Mailing List <linux-media@vger.kernel.org>
Subject: Re: libv4l: possible problem found in PAC7302 JPEG decoding
Date: Tue, 02 Feb 2010 11:46:37 +0100	[thread overview]
Message-ID: <4B68028D.8000405@kaiser-linux.li> (raw)
In-Reply-To: <4B67466F.1030301@freemail.hu>

On 02/01/2010 10:23 PM, Németh Márton wrote:
> Hello Hans,
> 
> while I was dealing with Labtec Webcam 2200 and with gspca_pac7302 driver I recognised the
> following behaviour. The stream received from the webcam is splitted by the gspca_pac7302
> subdriver when the byte sequence 0xff, 0xff, 0x00, 0xff, 0x96 is found (pac_find_sof()).
> Before transmitting the data to the userspace a JPEG header is added (pac_start_frame())
> and the footer after the bytes 0xff, 0xd9 are removed.
> 
> The data buffer which arrives to userspace looks like as follows (maybe not every detail is exact):
> 
>  1. JPEG header
> 
>  2. Some bytes of image data (near to 1024 bytes)
> 
>  3. The byte sequence 0xff, 0xff, 0xff, 0x01 followed by 1024 bytes of data.
>     This marker sequence and data repeats a couple of time. Exactly how much
>     depends on the image content.
> 
>  4. The byte sequence 0xff, 0xff, 0xff, 0x02 followed by 512 bytes of data.
>     This marker sequence and data also repeats a couple of time.
> 
>  5. The byte sequence 0xff, 0xff, 0xff, 0x00 followed by a variable amount of
>     image data bytes.
> 
>  6. The End of Image (EOI) marker 0xff, 0xd9.
> 
> Now what can be wrong with the libv4l? In libv4lconvert/tinyjpeg.c, line 315 there is a
> huge macro which tries to remove the 0xff, 0xff, 0xff, xx byte sequence from the received
> image. This fails, however, if the image contains 0xff bytes just before the 0xff, 0xff,
> 0xff, xx sequence because one byte from the image data (the first 0xff) is removed, then
> the three 0xff bytes from the marker is also removed. The xx (which really belongs to the
> marker) is left in the image data instead of the original 0xff byte.
> 
> Based on my experiments this problem sometimes causes corrupted image decoding or that the
> JPEG image cannot be decoded at all.
> 

Hello Németh

I remember the problem as I was working on the PAC7311.
http://www.kaiser-linux.li/index.php?title=PAC7311


This is the code I used in the JPEG decoder to remove the 0xff 0xff 0xff 
  0xnn markers.

See http://www.kaiser-linux.li/files/PAC7311/gspcav1-PAC7311-20070425.tar.gz
decoder/gspcadecoder.c pac7311_decode()

Thomas


  parent reply	other threads:[~2010-02-02 10:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-01 21:23 libv4l: possible problem found in PAC7302 JPEG decoding Németh Márton
2010-02-01 22:13 ` [PATCH ] libv4l: skip false Pixart markers Németh Márton
2010-02-02 10:30   ` Hans de Goede
2010-02-02 18:54     ` Németh Márton
2010-02-04  8:22     ` [PATCH libv4l tree, RFC] libv4l: skip false Pixart markers with buffer copy Németh Márton
2010-02-05 13:42       ` Hans de Goede
2010-02-05 16:43         ` Thomas Kaiser
2010-02-02 10:46 ` Thomas Kaiser [this message]
2010-02-02 18:59   ` libv4l: possible problem found in PAC7302 JPEG decoding Németh Márton
2010-02-02 19:48     ` Thomas Kaiser

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=4B68028D.8000405@kaiser-linux.li \
    --to=v4l@kaiser-linux.li \
    --cc=hdegoede@redhat.com \
    --cc=linux-media@vger.kernel.org \
    --cc=nm127@freemail.hu \
    /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