reverse engineering pwcx

Having watched the discussion around pwcx since the first posting, I thought I would take a look at libpwcx.a. It consists of 3 .o files each containing full symbol information and in total a *very* small amount of code. 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. There is none of this in the pwcx driver. I could provide complete decompiled source code for this binary, however due to the legal questions I'd rather just say that there is really not a lot of effort required here to black box this driver and replicate what it is doing. The biggest job will be deciphering the two or three large tables used in the decompression operations.

The specific issue of pwcx dealt with I'd really like to ask why companies perfer to release binary drivers over open source drivers. A Linux kernel driver is really easy to decompile. There's a number of factors that make this so, especially the large amount of symbols generally left in binary drivers, but mainly the fact that kernel drivers are by design small contained pieces of code. Also, they are generally written in straight C with the only function pointers being well documented interfaces (and the function pointers are not changed dynamically). Compared to say, a win32 application written in C++ with all that stdcall/fastcall stuff, a linux kernel module is a joy to decompile. So why bother releasing a binary only driver? The company is not protecting its intellectual property. If an amature like me, who knows nothing about web cams, can understand this driver than surely someone at one of Philips' competitors reverse engineered and understood this algorithm within weeks of the drivers for this camera hitting the market. I'm sure Philips' knows this so why force Nemosoft to sign an NDA? And more importantly, why not let the community maintain this driver?

Trent Waddington
Decompiler maintainer, http://boomerang.sourceforge.net/

http://www.amazon.com/exec/obidos/tg/detail/-/B00005R098/102-7619892-0201738?v=glance

claims that the Logitech Quickcam Pro 3000 is a "True 640 x 480 resolution video capture" which is now clearly false.

It would appear I have found an answer to my question. The reason Philips made Nemosoft sign an NDA was not to hide proprietory information from their competitors. It was to hide the fact that they were misrepresenting the resolution of their cameras to their customers. No wonder Nemosoft did not feel right about opening this module even after the NDA expired, he would be telling the world their dirty little secret. Of course I'm sure this was common knowledge to all those people who work in robotics and always demand an uncompressed stream from the camera.

Trent Waddington
Decompiler maintainer, http://boomerang.sourceforge.net/

If the "now clearly false" is meant to be a consequence of the
entropy measurements poster I referred to, I wouldn't jump the gun. On reflection, it's entirely natural for a decompressed stream to examine less entropy than the corresponding compressed stream!

Craig Milo Rogers

Please see this slashdot thread:

http://linux.slashdot.org/comments.pl?sid=119578&threshold=3&mode=flat&commentsort=0&op=Change

The LavaRnd guys examined the pixels on the actual CCD chip. It's 160x120. The 'decompression' is just interpolation.

Lee

First let me apologize to the list. I get carried away now and then :)

Actually I was refering to the fact that these algorithms are not "decompression" in any way shape or form. These cameras don't capture 640x480 images, compress them in hardware, transfer the data over a USB cable for the driver to then "decompress". They capture at some lower resolution (160x120 has been claimed) and the driver simply interpolates the data to produce the claimed resolution. There is nothing "true" about the 640x480 resolution at all.

So yeah, Logitech is making false claims to their customers and seeing as they get their chips from Philips I'm thinking they are responsible.

Trent

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

Well, it's definitely no surprise, you simply can't push the uncompressed stream through USB1.1.

Us in robotics, we use the iBot2 from Orange Micro, which is an USB2.0 webcam working nicely with Linux at 30fps, 640x480, truecolor, uncompressed.

So I don't think that Philips would really be able to "hide" this fact by putting the decompressors into a binary only module - everybody knows the compression must be lossy to allow for this high a compression ratio.

Also, it's quite obvious that there is a big tradeoff between image quality and algorithm complexity - it might be possible do do JPEG compression in the webcam at full framerate and a reasonably low price, but simpler algorithms with worse image quality still be well usable and make the price even lower.

Vojtech Pavlik
SuSE Labs, SuSE CR

It's hard to believe this. I'd believe it if there was supposed to be a 320x240 chip (or even more probably 384x288 (QCIF)), as those are rather common and with proper scaling up from the Bayer RGB pattern you can do a rather good interpolation to 640x480 or 768x576.

But 160x120 sounds pretty ridiculous. It still would be possible to scale that to 640x480 smoothly, but the image would be obviously blurry and just awful even with avanced Bayer-based scaling techniques.

If Philips really does that, and succeeds, then I see the reason to protect those methods, as it would allow the competition with better sensors to scale to even higher resolutions (heh, my iBot2 webcam would then be a 2560x1920 camera - that's 5 megapixels!).

Vojtech Pavlik
SuSE Labs, SuSE CR

I tried yesterday by phone and email, so far I have been unable to obtain a definite phone number for someone who actually is responsible for the drivers; and I have not yet received any answers to my email to their customer service. I will try again on Monday, through their Belgian division (so as to not piss off the same people too much), as I don't think there's much going on in the weekend. Their tech support did ask me about the Linux distribution, kernel version and XFree version, so they have at least heard about Linux. :)

It would help a great deal if Nemosoft could give me a contact address. Nemosoft, if you read this, could you help me out? Or perhaps try to reach your contact at Philips yourself with the question if any closed source is still a necessity - a lot of people would be grateful for a definite answer, I'm sure (not in the least yourself, I guess).

Perhaps there is somebody on this list who works at Philips and can give me a reply in private?

That sounds about right. At 640x480 the QuickCam 3000 is an awful blurry mess. Though I think the actual pixel count would be a multiple (divisor) of CIF, because in the nCIF resolutions it seems to expose more pixels.