WebM vs. H.264: A Closer Look
Encoding
For encoding, I looked at encoding speed and video quality; let's start with the former. As mentioned, I used a pre-release version of Sorenson Squeeze 6.0.4.63 to produce both the WebM and H.264 files. I produced two test files-one SD, one HD-using long standardized encoding parameters. For the SD file, this meant a target data rate of 500Kbps (468 video/32Kbps audio), using 2-pass VBR encoding with all quality related settings set to the max. The Squeeze interface makes this simple, with only a few VP8 related encoding controls, like trading off size vs. complexity and compression quality vs. Speed (Figure 1).
Figure 1. Key VP8-related encoding options in the Squeeze interface. Note the Encoding Threads option.
Interestingly, one of the benefits that Google touts about WebM on their web site is "Click and encode. Minimal codec profiles, sub-options; when possible, let the encoder make the tough choices." I was certainly willing to do that and used Sorenson-provided presets for the most part, along with the required adjustments to meet my resolution and data rate targets.
For H.264, I used the High profile, with CABAC enabled, with 3 B-frames and 3-reference frames, and encoding effort set to best. To complete the circle, I configured the HD test files at 720p at a VBR data rate of 800Kbps video/128Kbps audio (Figure 2).
Figure 2. The H.264-related options used in the test comparison.
When producing both WebM and H.264, Squeeze lets you improve encoding speed by using multiple CPUs-WebM via the Encoding Threads option shown in Figure 1, H.264 by using multiple slices (not shown in Figure 2). As you can see in Table 2, I tested using 1 thread/slice and 12 threads/slices on my Hewlett Packard Z800 with two 6-core 3.33 GHz Xeon processors, doubled to 24 total cores via hyper-threaded technology (HTT).
With 1 thread selected, producing the WebM file was very inefficient, with only about 4% of available CPU utilized, and producing the WebM file took almost four times longer than H.264. With 12 threads/slices selected, CPU utilization jumped to as high as 30%, and the differential dropped to under 25% for the SD file, though WebM still took 85% longer for the HD file. Note that I tried encoding with all 24 threads enabled, and it actually slowed encoding time.
The rap against using multiple threads/slices is that it can degrade quality, since the encoder doesn't search for interframe redundancies between slices, just within each slice. However, I compared the two WebM files and saw minimal, if any, quality differential. Run your own comparison on your content to verify this, but if encoding time is a concern for you, buy a 24 core system like the Z800 and use multiple threads when producing your WebM files. Bottom line is that WebM takes longer to encode, but the differential isn't that great, and probably will only impact high volume shops.
Quality Trials
When WebM was first announced, I compared a WebM file against an H.264 file as produced by Sorenson Squish, and concluded that "I'd say H.264 still offers better quality, but the difference wouldn't be noticeable in most applications." Now I've spent a bunch of time producing both formats, and reach the same conclusion.
Note that Sorenson Squeeze uses the MainConcept codec, which has been the highest quality commercially available codec in my comparison tests. To supplement these tests, I also produced comparison files with the x264 codec, using the QuickTime-based x264Encoder version 1.2.13 (dated 6/27/2010) set to the highest quality, slowest encode preset (Figure 3).
Figure 3. Settings used to create the x264 comparison files.
Related Articles
Google's attempt to clarify its decision to drop H.264 from Chrome in favor of WebM creates even more questions than it answers
17 Jan 2011
With Google's announcement that it's dropping H.264 support in Chrome in favor of WebM, it's time to start looking at the format. Here's a look at how to get the best WebM quality.
12 Jan 2011
With WebM, Google hasn't created any new revenue opportunities, opened any new markets or increased the size of the pie. They've just made it more expensive to get your share, all in the highly ethereal pursuit of "open codec technologies."
12 Jan 2011
Pay no attention to the man behind the Mac. HTML5 won't be a serious consideration for at least a few years.
02 Sep 2010
The standards body extended in perpetuity the royalty-free license on internet video that's free to users from 2015
26 Aug 2010
VP8 is now free, but if the quality is substandard, who cares? Well, it turns out that the quality isn't substandard, so that's not an issue, but neither is it twice the quality of H.264 at half the bandwidth. See for yourself.
20 May 2010