Why an Open Source ProRes Decoder Matters

ProRes 422 is Apple's lossy video high quality video compression format. It is the native format of Apple's popular Final Cut Pro video editing software. ProRes is also the format requested for HD Television and HD and SD Film to be delivered to the iTunes Store.

Apple favors its own OS X when releasing the ProRes. Apple updated the ProRes decoder for Mac OS X in June 2011, and Final Cut Pro X only for Macintosh provides a 64-bit ProRes implementation. The Windows download is 32-bit only and stuck in 2008 (not to mention the sorry state of QuickTime for Windows in general), and there is no ProRes decoder for Linux despite the growing cloud transcoding industry. Some Linux users have even resorted to loading a Windows DLL into MPlayer and Mencoder to handle ProRes content. There do appear to be a small handful of third party products that by hook or by crook include ProRes support.

Still Apple products and tools are the only first class citizens of the ProRes ecosystem or were until now. Today an intrepid hacker released an open source reverse engineered ProRes decoder for FFmpeg. Now everyone trying ingest ProRes files is on an equal footing. The iTunes Store's unfair ingestion advantage over Hulu, Netflix, YouTube, and the cloud transcoding industry is over. The days of loading a 32-bit Windows DLL are over. ProRes can now be decoded on ARM, in a 64-bit process, or on any platform with a C compiler. Hopefully someday this decoder will be extended into an encoder as well to end Apple's advantage in authoring ProRes not just consuming it.

These opinions are strictly mine and not those of my employer (YouTube).

In Defense of Lossy+Lossless Hybrid Audio Codecs

There have been many complaints leveled against lossy+lossless hybrid audio codecs lately. A lossy+lossless codec is one that codes a lossy layer, and has an optional enhancement layer to bring the quality up to lossless. Some examples of hybrid lossy+lossess audio formats are HD-AAC (MPEG-4 SLS), mp3HD, and WavPack. WavPack and MPEG-4 SLS can also run in pure lossless mode.

Lossy+lossless audio codecs do have many shortcomings. They require a canonical bit-exact version of the lossy decoder. This doesn't align well with modern popular pure lossy codecs. They (generally, WavPack does not) require a completely different coding scheme for the lossless enhancement layer that has similar complexity to a pure lossless coder on its own. They need to keep the lossless correction layers synchronized to the lossy file either on the file system or with special tools to attach and separate them. The sum filesize of both the lossy and lossless content is generally larger than what you would get using a pure lossless coder. All of these things certainly serve as barriers to adoption and good reasons to avoid lossy+lossless codecs should you not need their particular benefits.

The biggest benefit of lossy+lossless is that if you need to have a lossy copy as well as a lossless copy the sum space consumed will be less than having a lossy copy and a pure lossless copy (assuming you are using a good lossy+lossless codec).

The reason you might want a lossy copy rather than transcoding on the fly is for syncing a portable device where the whole library doesn't fit. In that case the user may swap music in and out on a regular basis. Transcoding 72 hours of music (72 hours * 128 kbps = 3.96 GB) well is a slow process, even on a fast machine.

I do recognize that this is a niche use case and that lossy+lossless adds a lot of complexity to the system. As storage on portables keeps getting larger and larger this advantage seems less and less important.

I think if anybody could have popularized such a codec it would have been Apple during the heyday of the iPod shuffle. iPods use a database with a syncing tool (iTunes) rather than USB mass storage making the single file solution an obvious choice. Remuxing on the fly is much faster than transcoding on the fly. But seeing as they haven't adopted lossy+lossless yet, I doubt they will bother with it at all.