On 09/13/2009 04:42 PM, leandro Costantino wrote:
Actually it based on pac7302. Pac7311/02 also has support ( since gspca1 ).

I checked some old logs of the pac, and the driver init for 7302 seems ok.

The "ff ff ff" sequence, seems to been taken in account on conversion.

/* Special Pixart versions of the *_nbits functions, these remove the special
   ff ff ff xx sequences pixart cams insert from the bitstream */
#define pixart_fill_nbits(reservoir,nbits_in_reservoir,stream,nbits_wanted) \

This is really a tricky cam. I be back on windows to do further test.

Hey All

I thought Hans will come in, in this discussion.......

Anyway, I introduced support for the PAC7311 in gspcaV1 in 2006 [1]

Pixart is using a proprietary JEPG Format to code the image. It took me (and help from Jörg Schummer) more than a year to find out the basics to decode a frame.

They have this 0xffffffxx markers in the stream, I don't know for what this is good, just skip it. And they have a "MCU marker" for each MCU. As we know so far, this MCU marker tells what Quantization table should be used for decoding the MCU.

Hans did implement my findings into lib4vl and improved it :-)

So, when you get this errors, this is due to a unknown format Pixart is using.

I guess we should know what marker you get and how the image should look like.

Don't forget, this is all re-engineered -> guess work!


[1] http://www.kaiser-linux.li/index.php?title=PAC7311
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