Slashdot Mirror
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."
This guy lives in Italy, safe from terrible US IP laws.
"I keep looking in the want-ads under 'revolutionary' but there don't seem to be any listings.. "
Should developers/users be afraid of the iron fist of moronic law in this case?
Or is it perfectly legal and VIA can not do anything about it? They seem to have an interest in suppresing such efforts though, since they've stated they are interested in revealing the code only to entities that want to make a buck off of it.
So, even if DMCA dosn't apply here, are there any chances they could be nasty about it? U-Boot
I've setup a mirror for the source at http://43.244.87.231/cle266.tgz
Be nice to it, and check the original site after slashdot effect goes away.
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. :)
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
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.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Just to prove it exists:
Reverse Engineering Compiler
They're not reverse-engineering the hardware, they're reverse-engineering the driver software that is used to talk to the hardware. In the absence of an authoritative interface document, the driver can serve as one. In the absence of source code for the driver, the reverse-engineered driver code can serve as one.
the decoded mpeg2 cannot be captured, it's decoded directly to the video memory.
This is not reverse engineering, he dissassembled the code and pretty much copied/ported the result to C. I don't think this meets any cleanroom standards and the code is dangerously contaminated. To use this work you would have to get someone else to reimplement the driver without looking at this contaminated code base. That means they need to be passed a description of the hardware interface inferred from observations of how this driver works, and the code produced by dissassebling the driver needs to be tossed in the garbage can.
Who taught anyone that dissassembling someone's proprietary code and doing a line for line port then publishing the result was in any way legitimate?
I believe that if you used dumpster dived code to make a diagram, and then used that to make the code you are open for abuse. Because you could have accidentaly infringed.
The coder and the diagramer should be different people for clean reverse engineering.
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
To do a clean room implementation, you need to have two teams:
- The first team digs into the implementation, and produces a document specifying the interface.
- 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 implementation150 Opening BINARY mode data connection for slashdot.sig (129323052 bytes).
Maybe it doesn't work in Linux or on your specific setup, but my 'suffiently accelerated ATI card' has a hardware MPEG decoder. All of them have had it for years, AFAIK - the original Radeon did, and I am pretty sure later Rage Pros also did. So maybe you actually are using a hardware decoder without realizing it?
There is no excellent beauty that hath not some strangeness in the proportion. -- Francis Bacon
I sold and serviced desktop video editing systems from '89 until '02 and things have gotten a lot faster since then.
> Hardware decoding allows for much higher resolution video.
I'm not sure what you mean by higher resolution--I've sold P4's that do real-time, full screen, uncompressed, CCIR-601 with software RAID 0 on SCSI and Nvidia graphics chips. Throw some more hard drives in the mix and another processor and you can buy software that will deal with two of those streams in real-time along with 2D effects A/B-roll, video processing(filter, keying, color, etc), and an alpha channel/CG.
> fractalize regions that have semi-random "noise" distribution
I'm not sure what you mean by that, either. Video noise that exists before encoding cannot be eliminated during decoding--filters can be used to lessen it but processors that would have difficulty doing that in software, in real-time while decoding a 5MB/s stream, were put out to pasture long ago. Noise that is introduced during the compression phase cannot be satisfactorily eliminated in software or hardware--what is lost is lost.
We have *long* surpassed the point where processing MPEG requires anywhere near 100% CPU utilization. I may be mistaken but I believe even Premiere 6 could do dual channel MPEG2(much more intensive than MPEG) 3DE with an alpha channel in real-time.
Although it did only start about a fortnight ago.