“It works for me.” These are the words that strike fear into the hearts of developers and users alike. Months of testing and still a file that opens or plays fine on one computer gives a frustrating error on another. More often than not, in the world of ClipWrap, these issues come down to H.264, the video codec behind AVCHD. In this post, we’re going to look at the current state of H.264 decoding on the Mac. Let’s start with a little history.
H.264 came to the Mac with QuickTime 7. A truly modern video codec, it brought amazing quality at reasonable bitrates, and has become the codec of choice for everything from video on mobile phones to satellite uplinks.
When QuickTime 7 first shipped, in mid-2005, content creators were quick to realize the gains, especially as compared to the rather underwhelming MPEG-4 implementation from QuickTime 6. While content creators were happy, content consumers quickly noticed the big downside of H.264 – extremely high CPU requirements during playback. Remember, this was back when $3000 bought you a very nice, very underpowered G4 PowerBook. Many a scorched lap tells the tale of CPUs running at maximum utilization to play a 640×480 H.264 file.
While Moore’s law ensured that someday computers would be fast enough to handle H.264 without trouble (though, in the case of the PowerBook G4, not nearly as fast as Apple might have wished), the iPhone threw a new wrench in the mix. Mobile battery life and CPU limitations meant that just throwing more power at the decoder wasn’t going to work.
The solution came in two forms. First, rather than just moving the QuickTime 7 H.264 decoder from the desktop to the phone, Apple went back to the drawing board. A new software decoder dropped some of the 20-year baggage that comes with adding codecs to the QuickTime framework. Second, hardware acceleration of H.264 moved some of the math from the main iPhone CPU to a chip better suited to the task. Thanks to those two innovations, watching 3 or 4 hours of near-DVD quality H.264 on a device with a 400mhz CPU and a tiny battery became just another part of catching a flight or enduring a long commute.
That was great for the iPhone, but what about the Macintosh? The arrival of Snow Leopard in late 2009 brought the answer. The new QuickTime X architecture leveraged the lessons of the iPhone to dramatically reduce the demands H.264 decoding. Around the same time, most Apple computers began shipping with hardware accelerated H.264 decoding. And of course, Snow Leopard kept the old QuickTime 7 architecture around for backwards compatibility.
So, we arrive at the present, early 2011. Take a brand new (and very svelte) MacBook Air out of the box and double click an H.264 video. Depending on the alignment of the stars, you may be riding one of three H.264 decoding trains. The ultrafast, low power hardware decoding MagLev, the very fast, but slightly less efficient QuickTime X TGV, or the very slow, power hungry QuickTime 7 Amtrak.
What decides? Well, there are as many flavors of H.264 as there are members of the standards committee. Not all decoders are equal. The hardware decoder for example is limited to a subset of H.264 files, and can’t handle some of the more sophisticated flavors. The QuickTime X software path is slightly more capable, but isn’t fully backwards compatible with all QuickTime files. The QuickTime 7 path is old reliable, the fallback when all else fails. Because Quicktime X doesn’t support much more than playback of files, most editing and compression applications are still limited to the QuickTime 7 path. Not all computers support hardware decoding, and of course, not all Macintoshes are running Snow Leopard. Suddenly the permutations start to look pretty complicated.
Let’s throw one or two more wrenches in the mix. Perian, the swiss army knife of QuickTime components, has its own H.264 decoder. While not the king of the hill in terms of performance, it supports a much wider variety of H.264 files than anything that comes out of Cupertino. It also brings its own idiosyncrasies to the party, sometimes taking over for the Apple decoder, even when the Apple decoder is the better choice. Finally, a handful of third party applications and hardware devices ship their own H.264 decoders.
The take away is that some files may open in one program, but not another, or may play smoothly on one computer, but stutter on a very similar computer. Final Cut Pro uses the Quicktime 7-style decoding, whereas newer versions of iMovie, Quicktime X and Finder use the newer paths. Because of this, we recommend Snow Leopard users keep a copy of QuickTime 7 around (http://support.apple.com/kb/dl923) – if you find something that won’t open properly in QuickTime X, try in the older application. Then you’ll have a good idea of whether it’s a decoder issue or a file issue.
A new version of OS X, Lion, is around the corner, and it promises to allow third party applications to take better advantage of the benefits of QuickTime X. It’ll also surely introduce further discrepancies when compared to earlier versions. One more variation, one more opportunity for us to say “It works for me.”
- Colin