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.
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.
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?
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.
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.
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.
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 [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?
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.
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
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.