WebM vs. H.264: A Closer Look

Google’s decision to open source VP8 in the form of WebM was the opening salvo in yet another codec war. We take a look at encoding efficiency, output quality, and CPU horsepower required for playback of both WebM and H.264.

This article compares H.264 to WebM, Google’s implementation of the VP8 codec, using three variables, encoding time, compressed quality and CPU requirements for playback on three personal computers. Here’s the Cliff’s Notes version of the results: Using Sorenson Squeeze to produce both H.264 and WebM, the latter definitely took longer, but there are techniques that you can use to reduce the spread to under 25%, which is pretty much irrelevant. Though H.264 offers slightly higher quality than the VP8 codec used by WebM using the aggressive (e.g. very low data rate) parameters that I tested, at normal web parameters, you couldn’t tell the difference without a scorecard. Even as compared to H.264 files produces with x264, VP8 holds its own.

The most significant difference between the technologies is the required CPU horsepower to play back the respective files, as shown in Table 1, which contains the results from four different computers. All numbers are “best case,” or the lowest CPU utilization in any of the tested browsers. More on test procedures below.

On a MacBook Pro with GPU acceleration for H.264 decoding, WebM took 38% of total CPU to play back a 720p file, compared to 24% for H.264 played via Flash, and 15% via HTML5 in Apple Safari. On an Acer Aspire One Netbook without GPU acceleration for H.264, WebM was actually slightly more efficient than H.264 played back either via Flash or HTML5, though the difference wasn’t significant. Note that the tests on this small screen netbook involved an 640×480 file, not 720p.

On a Hewlett Packard 8710w mobile workstation with GPU acceleration for H.264 playback, H.264 via Flash required 70% less CPU power than WebM to play back the 720p file, and H.264 via HTML5 took 47% less CPU power. On my daughter’s iMac, WebM and non-accelerated Flash-based H.264 based playback ran neck and neck, while Apple’s Safari, presumably with hardware acceleration, proved 54% more efficient than WebM.

Basically, though there are huge swings with the individual browsers, where GPU acceleration exists for H.264, it’s significantly more efficient than WebM; where it doesn’t, they’re neck and neck. At this point, between Flash Player 10.1 with hardware acceleration on supported graphics cards and platforms, and Apple’s own Safari browser, there’s a lot of hardware-accelerated platforms for H.264 playback, and few if any for WebM, though there may come in time.

Interestingly, on the WebM website, Google says “Note: The initial developer preview releases of browsers supporting WebM are not yet fully optimized and therefore have a higher computational footprint for screen rendering than we expect for the general releases. The computational efficiencies of WebM are more accurately measured today using thedevelopment tools in the VP8 SDKs. Optimizations of the browser implementations are forthcoming.”