WebM vs. H.264: A First Look

WebM: A Brief History
According to www.webmproject.org/about, WebM is a "royalty-free, media file format designed for the web." Briefly, WebM uses the VP8 video codec that Google purchased from On2, the Vorbis audio codec, and a file structure based upon the Matroska container. Though WebM is new, the VP8 codec itself was first launched on Sept. 13, 2008, and comes with some history and some baggage. The history is its predecessor, VP6, which came to prominence when Adobe bundled it into Flash. It is still the most widely used video codec on the internet today. The baggage includes statements in the VP8 press release such as the following:

"With the introduction of On2 VP8, On2 Video now dramatically surpasses the compression performance of all other commercially available formats. For example, leading H.264 implementations require as much as twice the data to deliver the same quality video as On2 VP8 (as measured in objective peak signal to noise ratio [PSNR] testing)."

The press release continues: "In addition, the On2 VP8 bitstream requires fewer processing cycles to decode, so users do not need to have the latest and greatest PC or mobile device to enjoy On2 VP8 video quality."

During the 11 months that followed the release, On2 never made VP8 available for testing, at least not to me or Streaming Media. And after Google signed the agreement to purchase On2 on Aug. 5, 2009, information about VP8 became tougher to find than President Obama's fabled Kenyan birth certificate. Google closed the deal on Feb. 19, 2010, and launched WebM on May 19.

Google has never repeated the exact claims that On2 made in the initial press release. But when Google makes claims such as "highest quality real-time video delivery" and "low computational footprint," it does draw some skepticism. It's also important to note that VP8 is not a new technology-it's actually been around for close to 2 years, so it doesn't get the benefit of the doubt on initial quality or encoding-related issues. That said, you'd have to assume that all browser-related ports began after Google signed the agreement to purchase On2 (August 2009) and perhaps as late as after the deal closed in February, so there certainly could be room for improvement there.

That's the chatty background. Let's start looking at test results.

Encoding
For encoding, I looked at encoding speed and video quality; let's start with the former. As mentioned, I used a prerelease 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 two-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, such as trading off size versus complexity and compression quality versus speed (Figure 1).

Interestingly, one of the benefits that Google touts about WebM on its website 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 three B-frames and three-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).

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 one thread/slice and 12 threads/slices on my HP Z800 with two six-core 3.33GHz Xeon processors, doubled to 24 total cores via hyperthreaded technology (HTT).

With one 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 less than 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 because 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. The bottom line is that WebM takes longer to encode, but the differential isn't that great and probably will only impact high-volume shops.