The King lives, and he's keeping busy by reverse engineering codecs... author Elvis Presley
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?
Apple ProRes codec reverse engineered
21–27 of 27 posts
Re: Apple ProRes codec reverse engineered
#22Earlier quoted context omitted.
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 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…
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…
Having done the same thing I would agree entirely. There are lots of similar patterns in decoders from a similar family.
Re: Apple ProRes codec reverse engineered
#23The King lives, and he's keeping busy by reverse engineering codecs... author Elvis Presley
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.
Re: Apple ProRes codec reverse engineered
#24This 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: val = SHOW_UBITS(re, gb, bits) - (1 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…
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).
Re: Apple ProRes codec reverse engineered
#25but the patent licences fees still apply.
In countries where the patent applies.
Re: Apple ProRes codec reverse engineered
#26This 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.
Re: Apple ProRes codec reverse engineered
#27Earlier quoted context omitted.
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. and the second interpretation is quite unfair IMHO.
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?