Apple ProRes codec reverse engineered(git.videolan.org)
git.videolan.org
Apple ProRes codec reverse engineered
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=5554de13b29b9bb812ee5cfd606349873ddf0945
5 comments
This code makes me feel like I'm not even a real software engineer, I'm just a guy playing with kiddie languages working on kiddie problems. Anyone else think that after reading it?
Codecs are complicated and mathy and optimized for speed. So you might find a line of code that says something like:
But trust me--if you go through a complicated spec and implement it yourself, you'll end up with a lot of similar stuff as this guy did, with his mighty-fine-looking piece of work.
val = SHOW_UBITS(re, gb, bits) - (1 << exp_order) + (switch_bits + 1) << rice_order);
But trust me--if you go through a complicated spec and implement it yourself, you'll end up with a lot of similar stuff as this guy did, with his mighty-fine-looking piece of work.
This is especially true when you're reversing a codec. I helped out reversing ALAC (Apple's answer to FLAC), and I didn't know what 99.9% of the code did, I just knew how it needed to do it. Certain things fit common patterns with simple changes (e.g. modified Rice coding), but most of the time you're just matching code behavior directly.
I will say, building an encoder based solely on the reverse-engineered decoder (didn't want to reverse out the encoder as well -- total mess) is a really fun challenge. Good way to dive into codec work.
I will say, building an encoder based solely on the reverse-engineered decoder (didn't want to reverse out the encoder as well -- total mess) is a really fun challenge. Good way to dive into codec work.
Having done the same thing I would agree entirely. There are lots of similar patterns in decoders from a similar family.
Would it be possible to write the same code to make it more readable without incurring a performance penalty? If not, then I guess it's okay, since these people have decided that performance is more important than readability (although there should be comments).
Languages are just tools. What one person can write in Erlang or raw C, someone else can write that in JS or QBasic. What matters is what your code does. Having working on projects ranging from large ERP systems to audio DSP to video startup to joke sites like cakesy.com and iwannamarry.com, I can say that what matters most is how much you enjoy working on the project. That's it. If the twitter-feed-importing-app makes you happy and your users happy, don't feel bad that you're not contributing to OpenSSH.
I get what you're saying, but want to remind you that this kind of math is a skill just like juggling or swallowing swords. Just because some folks train more in web applications, ORM, crazy legacy file formats, whatever, does not automatically make them less of a software engineer.
I also quite often draw the distinction between "programmers" and "software engineers", with "computer scientists" sometimes being their own category, and sometimes a subset of the first two.
I also quite often draw the distinction between "programmers" and "software engineers", with "computer scientists" sometimes being their own category, and sometimes a subset of the first two.
[deleted]
The King lives, and he's keeping busy by reverse engineering codecs...
author Elvis Presley <[email protected]>I thought that was funny. Maybethe author is afraid of being sued over this? Otherwise why wouldn't you want to be recognized for this?
Reverse engineering can be done legally (in most jurisdictions) but that doesn't you want to invite an expensive lawsuit to prove you did it cleanly.
This is a great development for decoding ProRes with non-OSX OSes. What are the legal implications? Will ffmpeg need to pay to license the ProRes codec from Apple? Does Apple even offer a license for the codec?
if ffmpeg worried about patents and licensing, they would have stopped development a long time ago.
Your snarky remark can be read both ways:
- if ffmpeg [developers] were overly scared about even remote risks of being sued, they'd stop.
- if ffmpeg [developers] wanted to abide by the law, they'd have to stop.
I meant it both ways, however the second interpretation is really only true under US law. A lot of parties would want a lot of money to license things, how would they pay?
Haven't they had this for a while (Post Date: August 28, 2008).
http://support.apple.com/downloads/Apple_ProRes_QuickTime_De...
However, it's nice that they have it built into ffmpeg now.
However, it's nice that they have it built into ffmpeg now.
It's read only for Windows, so Win apps can't write out a prores file. (In reference to Apple's decoder)
Windows is read only (although clipster somehow manages to write out prores files). There are two licensed products (hardware) that write out prores that I am aware of - ARRI Alexa cameras and AJA ki pro.
The ARRI Alexa records in Apple ProRes 4444 or Apple ProRes 422. I am not sure if they got a license, but they have been doing it a while.
but the patent licences fees still apply.
It's been over a decade since they haven't paid mpeg fees, so apple shouldn't hold its breath.
(Do folks realize that ffmpeg has never paid such fees intentionally and as a matter of philosophy?)
(Do folks realize that ffmpeg has never paid such fees intentionally and as a matter of philosophy?)
it's not FFmpeg that would need to pay the fees, it would be FFmpeg users. A lot of codec royalties are tied to devices sold or hours of content streamed
In countries where the patent applies.
ProRes 422 is a standard-definition and high-definition lossy video compression format developed by Apple Inc. for use in post production. It was introduced in 2007 with Final Cut Studio 2 [1] and is comparable to Avid's DNxHD codec which has the same purpose and uses similar bit rates.