

Apple ProRes codec reverse engineered - kierank
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=5554de13b29b9bb812ee5cfd606349873ddf0945

======
deweller
From <http://en.wikipedia.org/wiki/ProRes_422>:

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.

~~~
bradly
I believe ffmpeg has been able to decode ProRes 422 for a while now. It is
ProRes 4444 that there hasn't been any decoding available for. It looks like
this adds support for it.

~~~
kierank
ffmpeg has been able to decode neither formats until now.

------
flyosity
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?

~~~
beej71
Codecs are complicated and mathy and optimized for speed. So you might find a
line of code that says something like:

    
    
        val = SHOW_UBITS(re, gb, bits) - (1 << exp_order) + (switch_bits + 1) << rice_order);
    

and you just don't have a clue what it really means (I don't--even though I
can easily read the line of code) because the answer is buried in the details
of the codec design.

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.

~~~
daeken
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.

~~~
kierank
Having done the same thing I would agree entirely. There are lots of similar
patterns in decoders from a similar family.

------
drv
The King lives, and he's keeping busy by reverse engineering codecs...

    
    
      author	Elvis Presley <elvis@e.p>

~~~
bgentry
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?

~~~
jasonwatkinspdx
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.

------
aschwo
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?

~~~
throwaway32
if ffmpeg worried about patents and licensing, they would have stopped
development a long time ago.

~~~
dexen
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.
    

and the second interpretation is quite unfair IMHO.

~~~
throwaway32
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?

------
itsmemario
but the patent licences fees still apply.

~~~
jpdoctor
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?)

~~~
av500
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

