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).
2011-01-13
FFmpeg AAC Decoder Todo List
Seeing as I resigned from being the FFmpeg AAC maintainer, here is my remaining decoder todo list for those interested in hacking on the decoder:
- Add gapless and preroll support. This requires some libavformat integration but the lossless codecs must at least have some sort of gapless support. Support for the iTunSMPB tag is a must.
- Optimize the SBR windowing. The actual transform should be fairly optimal. See the implementation notes from my first blog post.
- Optimize the parametric stereo filterbank. There is a lot of redundant math in there.
- Add fixed point support.
- Consider a more conservative approach to SBR and PS detection. (If there is no signaling and the sample rate is less than or equal to 24 kHz assume SBR. If SBR is used and the stream is mono assume PS).
Subscribe to:
Posts (Atom)