Reverse Engineering an MPEG Driver

An anonymous reader writes "Following on from the recent spate of reverse engineering articles, there is an interesting summary of the reverse engineering of a binary only Linux driver. The driver is for the integrated MPEG decoder on VIA's popular EPIA-M boards. At the moment VIA has not publicly released the source code for the MPEG chipset on these boards and will only make the code available under NDA saying that "Typically, only requests from companies developing product for sale will be approved." As a result this is holding back development of open source tools (e.g. xine, mplayer, vdr) that would be able to make use of the interesting hardware on these boards."

Comments

Re:Software decoding works fine

[MikeFM]

My lil epia box does better than my parents faster Wintel box at playing dvd's and vob's. Sure a lot of that is because MPlayer and Linux are so much better but you're mistaken if you think the epia systems don't have the muscle for the job. If they could enable the hardware decoding it might even make the playback better. They also run much cooler, more energy effecient, and quieter.. something that IMO is a mark of quality.. not of being 'cheap'. Besides, price compare the CPU's.. you'll find they aren't that cheap. :)

Re:Free, but not Free

[Svartalf]

In actuality, they released everything BUT the driver info for the MPEG stuff. They handed the 2D and 3D over to the DRI and XFree86 people- Alan Cox was working on making the drivers all nice and clean up until recently.

From what I got from my contacts at SiS and VIA when I was working on set-top box designs using their chipsets was that the stuff was being held to an NDA because of contractual reasons. My ignorant guess would be that there's something with regards to the MPEG patent licensing that prevents the details being released for piracy prevention reasons because the use of these accelerators would enable real-time/near real-time transcoding of DVDs, etc.

This is not to say that I'm right, or if I am, that it's a good reason.

Re:Is this reverse engineering?

[yellowstone]

He took the binary code and inferred a C language program that would produce the same code. Very clever, but I thought reverse engineering worked on a functional level.

Well, this is definitely not a 'clean room' reverse engineering.

To do a clean room implementation, you need to have two teams:

1. The first team digs into the implementation, and produces a document specifying the interface.
2. The second team uses the specification produced by the first team to create an implementation.

This is a clean-room implementation when the only communication between the two teams is via the specification: A) No one who sees the original implementation works on the new implementation and B) No one who works on the new implementation looks at the original implementation

Re:NOT reverse engineering

[orv]

The copyright statement in the driver from via states:-

* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sub license,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the
* next paragraph) shall be included in all copies or substantial portions
* of the Software.


It's just that they didn't actually release the code for the driver. So the port doesn't need to be a proper clean room reverse engineer.