On 09/13/2009 09:20 AM, Jean-Francois Moine wrote:
On Fri, 11 Sep 2009 09:09:20 +0200
Németh Márton<nm...@freemail.hu>  wrote:

You can find my results at
There are three types of problems: a) Sometimes the picture contains
a 8x8 pixel error, like in image #9
b) Sometimes the brightness of the half picture is changed, like in
images #7, #36 and #37
c) Sometimes the libv4l cannot convert the raw image and the errno is
set to EAGAIN (11), for example image #1, #2 and #3

Do you know how can I fix these problems?

The error EAGAIN is normal when decoding pac7311 images, because they
are rotated 90°. But this error should occur one time only.

I looked at the raw image #1, and it seems that there are JPEG errors
inside (sequences ff ff). There should be a problem in the pac7311
driver. Hans, may you confirm?

The pac7311 / pac7302 are very cheap crap cams (I bought one brand new
for 3 euros, and that was not in the bargain bin).

These cams use a custom jpeg format, and we are very luky to be able to
decompress this at all (thanks to some of the wizards who worked on the
original gspca driver).

Yes there are still some issues, but with no documentation what soever,
and unreliable hardware (I've seen hang cams which needed to be unplugged
/ replugged to start working again), I'm afraid there is nothing we can do.

Still if people want to work on improving support for them more power to
then, I'll gladly help where I can. The ff ff you've found are special
Pixart padding sequences, see tinyjpeg.c: pixart_fill_nbits()

Also interesting is the comment about some of the special Pxiart markers
in the tinyjpeg.c: pixart_decode_MCU_2x1_3planes() function. Which
summaries what i've learned while getting pac7302 cams to work (to a
certain extend).


To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to