Re: reverse engineering pwcx

Clem Taylor
2004-08-28T06:48:30Z

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