| 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
|