Yesterday I demonstrated how H.264 compares to the Sorenson 3 video compression algorithm. Short answer: favorably. Very favorably.
Today I wanted to see how H.264 would handle a real challenge. So I pulled out my DVD of Saving Private Ryan, selected what I thought might be one of the toughest ten-second clips in the film, and proceeded to encode it in H.264 at various bit rates to see at what point the footage went from excellent to watchable to unwatchable.
The results can be seen here.
At reader request, I’ve added a clip encoded at 512 kilobits per second. I think the phrase “testing to destruction” was taken a little too literally here, as the 512-kilobit clip looks just terrible. But can a different type of subject matter hold up at 512 kilobits? Stay tuned to find out.
The same reader writes, “If 512 looks almost as good as 768, how does 256 look?” The answer, dear reader is, “Terrible.” But here it is, included just for completeness’ sake.
- Encoded at 256 kilobits per second
- Encoded at 512 kilobits per second
- Encoded at 768 kilobits per second
- Encoded at 2,048 kilobits per second
- Encoded at 4,096 kilobits per second
In my opinion, the 768 kilobit-per-second version is not acceptable. While H.264 does a great job of hiding the compression artifacts — you can see blocking artifacts if you look for them, but they’re very subtle compared to what other codecs produce at these bit rates — the result is still too soft overall for me. Too much detail has been lost, particularly in the far backgrounds.
To its credit, H.264 does a spectacular job in the 30 frames or so where the mortar round goes off at camera right. The debris from the explosion is preserved in a way that seems impossible at 768 kilobits per second.
The two-megabit version is more like it. A lot of the detail that disappeared in the 768-kilobit version is back. Check out the texture of the sand in the first shot of the clip. The footprints, absent in the 768-kilobit clip, can be seen clearly.
At four megabits, even some of the film grain is preserved. By design, Saving Private Ryan is a very grainy movie. If you look at the far background in the opening shot of the clip, where the landing craft can be seen just off shore, the grainy look of the DVD transfer is preserved, if not perfectly, surprisingly well given the bit rate.
The original MPEG-2 clip was 30.5 MB and had an average bit rate of 7,870.78 megabits per second. An acceptable simulation of the quality of that clip — not perfect by a long shot, but acceptable — can be created with H.264 at four megabits per second. I think that’s pretty impressive.
Later today, I’m going to add another set of tests to this page. The clip from Saving Private Ryan was obviously intended to test H.264 to destruction; this clip are inherently very difficult to compress due to the camera shake, the grain, and the nature of the shots. To bring the test back toward more typical real-world cases, I’m going to pull some footage from “The West Wing” and run it through H.264 to see how it turns out. The difference between talking heads with fixed cameras and the beaches at Normandy should be revealing. Stay tuned.
Update
If Saving Private Ryan is testing to destruction, then this clip from TV’s “The West Wing” is a slow pitch right down the middle. This eighteen-second clip is composed entirely of fixed-camera talking-head shots, pretty typical stuff for the average scripted TV drama. It should compress fairly well. Compared to Saving Private Ryan, it should compress spectacularly well.
As I noted above, I thought that Saving Private Ryan at 768 kilobits per second was not acceptable, though frankly it looks better than a lot of what passes for Web video these days. To get to the point where it was acceptable, I thought that clip needed two megabits per second, and before it looked good I had to give it four. At 512 kilobits per second, the clip looked pretty awful. At 256 kilobits per second, of course, it was a disaster.
Obviously “The West Wing” won’t require those kinds of bit rates. I decided to start at the low end, at the very lowest limit of what I thought might be acceptable: 512 kilobits per second.
When I saw the resulting clip, I thought I’d screwed up. I thought I’d done something wrong with the settings. Maybe I set it to 5,120 kilobits per second instead. I double-checked. The settings were exactly what I’d told them to be: 512 kilobits per second.
At a casual glance, the clip encoded at 512 kilobits per second — a mere 64 kilobytes per second — is indistinguishable from the DVD.
I’ve been working with H.264 for a while now, so I’m more or less accustomed to what it can do. But this absolutely knocked my socks off. Never in a million years would I have predicted that H.264 at 512 kilobits per second could rival MPEG-2 at 6,400 kilobits per second.
Just for fun, I dialed the bit rate back to 256, then to 128 kilobits per second. Both of those are obviously compressed, of course. But the 256-kilobit clip looks better than what I get out of my venerable TiVo, and even the 128-kilobit clip is better than I would have expected it to be.
Let me point something out here: At 128 kilobits per second, we’ve dedicated as much bandwidth to audio as we have to video. And the video, while not great, is good enough for a lot of purposes. If an editor’s rough cut out of an Avid looked like that, nobody would think twice about it.
(A sample at half-D1 resolution, 320 by 240, at 128 kilobits per second looks pretty darned great if you ignore the fact that it’s the size of a postage stamp.)
- Encoded at 128 kilobits per second (half size)
- Encoded at 128 kilobits per second
- Encoded at 256 kilobits per second
- Encoded at 512 kilobits per second
- Encoded at 768 kilobits per second
Of course, most actual program content will consist of a bit more than just talking heads in front of static backgrounds. So it’s kind of silly to expect that all scripted standard-definition content should be able to be encoded down to half a megabit per second. But it seems to me, based on this series of very informal tests, that most standard-definition content should be able to be encoded somewhere between 512 and 2,048 kilobits per second with picture quality reasonably, more or less, approaching that of a DVD.
Quite a step up from MPEG-2, huh?
Some technical details
To create these clips, I used the program Mac the Ripper to pull a specific chapter off of the respective DVD. The result was a VOB file. I opened that VOB file in a program called MPEG Streamclip and used the “Demux to unscaled M2V and AIFF” menu item to create an M2V and an AIFF file. I opened the M2V file in QuickTime Pro 7 and exported it as a QuickTime movie using the Apple 8-bit 4:2:2 codec. I exported the AIFF as a QuickTime movie with audio only using the AAC encoder at 128 kilobits per second.
At that point, I had one QuickTime movie with video only that was a 720-by-480-pixel uncompressed clip and one QuickTime movie with audio only in AAC format.
To create a clip at a target bit rate, I exported the video movie at the same size — 720 by 480 — to H.264, specifying the bit rate in the exporter options dialog box. The result of that process was a video-only QuickTime movie encoded at the right bit rate at a size of 720 by 480.
I opened this resulting file and pasted the AAC audio track in using the “Add to Movie” menu item. I then used the “Show Movie Properties” menu item to set the playback size of the video track to 850 by 480. This has the effect of stretching the movie during playback in exactly the same way that your TV stretched an anamorphic DVD out to the right aspect ratio during playback.
From there, it was just “Save As” and drag to the iDisk.
If I had chosen, I could have scaled my source media during export by putting in a custom size in the exporter options dialog box. I chose not to do that because I didn’t see much point in encoding noise. I chose to keep the video anamorphic until playback by telling QuickTime to do the non-proportional scaling for me.
Comments
All comments are the property of their owners and do not reflect the opinions of this Web site or, well, basically anybody at all. The author of this Web site reserves the right to edit the hell out of any and all comments. Participate at your own risk.