Re: reverse engineering pwcx

From: Clem Taylor
Date: Sat Aug 28 2004 - 01:50:10 EST


QuantumG wrote:
There is no secret algorithm or complex image processing in this
code. Having worked on reverse engineering a complex audio
processing application (see our paper Using a Decompiler for
Real-World Source Recovery, to appear WCRE 2004), I expected to see
some serious floating point calculations or at least something
recognisable as a FFT or some other known algorithm.

I think you need to look a little closer. This type of decompression is surely not going to be done with floating point (can you even do floating point ops in the kernel?).

This class of camera chip uses a greatly simplified JPEG like compression. The compression is a 4x4 DCT (JPEG uses a 8x8 DCT), a quantize step and some sort of simple VLC. The algorithm was chosen to be easy to implement in an absolutely minimal number of gates. At this point true JPEG encode hardware is enough of a commodity that it would be silly not to use JPEG in a new design.

I'm pretty sure this class of camera chip uses a 4x4 DCT and some sort of VLC. Most of the meat of the decoder would be table lookups to decode the symbols and then a small multiply accumulate loop to do the inverse DCT and another series of table lookups and multiplies to do the inverse quant. Pretty basic stuff at this point.

The white paper I read a while back on this chipset family had been out of NDA for a number of years, so I was never sure why the pwcx driver wasn't opened up. A competitor wouldn't gain much knowing the exact details of the decompression algorithm. If I was a competitor designing a new webcam chip, I wouldn't waste my time reverse engineering Philips compression scheme, I'd just use JPEG and be done with it.

Has anyone even asked Philips if they would be willing to open up the algorithm? Maybe they would have said NO a few years ago, but at this point does it matter?

--Clem
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/