Article rewritten due to further analysis and apparent desire for this information.

Apple has released Mac OS X 10.4 (a.k.a. Tiger) and with it comes a new version of QuickTime and a splendid new codec. Along with the many previous H.26x codecs, this one scales well for a wide variety of resolutions and bitrates. It is also rather hard on the processor, as any good modern codec should be.

So much could be said about this to describe it generally,

A sample of the THX intro teaser from LucasFilm encoded from a DVD to various sub-DVD bitrates in mp4 and h.264. Source DVD content consumed 19 MB.


h.264 1.1MB


mp4 1.8MB


h.264 2.3MB


mp4 3.0MB


h.264 5.0MB

The quality remains surprisingly high between all of these, despite the wide range of compression.

but that's not much fun. I'm going to compare what I've seen of this codec with the mpeg4 standard (including divx and xvid) that so many of us have grown to love. The pressing question in my mind was: "Is it going to be good enough that I should re-rip all of my DVD's?"

The answer is no. Although if support for the codec grows like mpeg4 is growing, I would suggest doing all of your encoding in h.264in the future. And here's why.

Quality: I happen to have found some superb tools for mpeg4 compression leveraging xvid libraries. OpenShiiva outdoes everything else I've seen by a good 30%. It can also produce very plain flavor, QuickTime compatible mpeg4 output. It's quality is about 50% better than the mpeg4 compression done by quicktime pro. So if you do mpeg4 compression without leaving QT6, you're really not feeling the full benefit of the codec. H.264 comes up with roughly the same quality out of quicktime as I've come to expect from my best-of-breed mpeg4 compression pipeline. Perhaps better compression tools will come out and actually make it better than mpeg4, but right now it seems to be roughly equal given the tools I've seen.

So why would I recommend it if the quality is about the same? Because it has some other qualities that make it really sweet. First, the artifacts are far less synthetic than mpeg4 artifacts. So you can scale down your bandwidth and it won't be obvious that you are pushing your codec really hard. The image becomes less clear but you don't see obvious banding or macroblocks as you squeeze your data rate down. H.264 also doesn't blow up on action sequences as severely as mpeg4 does.

The next benefit is that this codec scrubs really well. I've taken to putting a keyframe once roughly every 2 seconds in mpeg4 (rather than the suggested 10 seconds), despite that you can't see any difference in playback, because scrubbing mpeg4 backwards (rewinding) hurts. Like petting a porcupine the wrong way. While I didn't fool around with spacing out the keyframes in H.264 very far (I just took the default of one per second) I found scrubbing to be totally painless. Perhaps putting a keyframe once every 10 seconds would anger the H.264 codec, but it didn't seem like it on initial testing. With the quality being so good at low bandwidth I didn't feel the need to tweak it further.

The processor usage on my machine was 20% - 30% less than mpeg4 for playback (decoding). Encoding seemed to take a bit longer than even my slower and better mpeg4 tools. Anyone expecting real-time encoding with this codec ... will have to wait for quad-processor macs and pervasively multi-threaded quicktime.

Also worth noting is that QT Pro affords a great deal of control over the codec and puts QuickTime back into the top slot in terms of quality video compression tools. Combine that with good AAC audio encoding and the appropriate controls, QT7 is a worthy upgrade just for this codec alone. Other than this codec it looks like the style has been smoothed over a bit, and exports and encodes go into a list of separate threads, but is otherwise much like QT6. QT7-Pro is another $30 upgrade no matter what you've owned before, but is still a bargain in the format interchange arena.

Here is another example. open the images individually to see them at full size. Shown here scaled by your browser.

Pixlet (Original) 40MB file mpeg4 1.4 MB file h.264 55% quality 1.4 MB file
Note the color shift that occured in the mpeg4. Check the macroblock pixels in the emerging E. Look at the fishing line.

Interestingly enough, I actually found mpeg4 to be just a wee bit sharper in some instances than H.264 at the same bitrate, but because the look of H.264 is so natural you'd never know you were missing anything if you didn't have the original to compare with. Compare that with the obvious macroblocks you get from satelite TV or a tightly squeezed divx flick. In the area of making itself invisible, H.264 wins by a large margin over everything else I've seen to date.

The best reason to NOT use this codec is that its adoption rate is not yet certain. If it remains quicktime only, it won't see the usage it deserves. I hope to see support for playback of this codec in RealPlayer and Windows Media Player; then we'll truly have something noteworthy. And if this happens, Quicktime will be just one of many interchangeable playback tools, but will remain a critical piece of multimedia content creation workflows.

Oh, and I suppose it may be worth noting for the legally pedantic and intellectually challenged that the content that was used to make these samples of compression are works of other people. Out of spite for how much lawyers have twisted society's daily actions into arm flailing posturing and the antithesis of "mea culpa," I refuse to name whose works they are.

Comment on this piece