From: "Németh Márton" <nm127@freemail.hu>
To: Thomas Kaiser <v4l@kaiser-linux.li>
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 19:59:04 +0100 [thread overview]
Message-ID: <4B6875F8.8040100@freemail.hu> (raw)
In-Reply-To: <4B68028D.8000405@kaiser-linux.li>
Hi Thomas,
Thomas Kaiser wrote:
> 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()
Do you remember whether this code was working properly always?
Regards,
Márton Németh
next prev parent reply other threads:[~2010-02-02 18:59 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 ` libv4l: possible problem found in PAC7302 JPEG decoding Thomas Kaiser
2010-02-02 18:59 ` Németh Márton [this message]
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=4B6875F8.8040100@freemail.hu \
--to=nm127@freemail.hu \
--cc=hdegoede@redhat.com \
--cc=linux-media@vger.kernel.org \
--cc=v4l@kaiser-linux.li \
/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 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.