Streaming Media

Streaming Media on Facebook Streaming Media on Twitter Streaming Media on LinkedIn Streaming Media on YouTube

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.

Ozer WebM Table 1

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 640x480 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 the development tools in the VP8 SDKs. Optimizations of the browser implementations are forthcoming."

Truth be told, I'm not that much of a geek, so the low-level development tools were a non-starter for me. However, I did download the DirectShow components to my two Windows computers and played the WebM file via Windows Media Player. On the HP 8710w, CPU load during playback of the same HD WebM file was 18%, with all acceleration disabled, compared to a low of 70% on any of the tested browsers, and 21% for hardware-accelerated Flash H.264 playback. On the Acer Aspire One, CPU load dropped to 24%, 30% with hardware acceleration disabled, down from a low of 51% with any of the tested browsers, and compared to 53% for non-hardware accelerated Flash-based H.264 playback.

I'm from Missouri (the "Show Me" state) when it comes to all codec-related claims, so I'm not willing to assume that subsequent updates will reduce browser-based WebM playback loads to these levels. If that occurs, however, the value proposition for WebM as compared to H.264 changes to similar quality, a bit slower encode, but much lower playback requirements, which could be pretty compelling, particularly for low powered mobile markets.

Now you know the end of the story, let's dive in at the beginning.

WebM-A Brief History
According to, 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 September 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, and is still the most widely used video codec on the Internet today. The baggage are statements in the VP8 press release like:

"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 next 11 months, On2 never made VP8 available for testing, at least to me or Streaming Media, and after the Google signed the agreement to purchase On2 on August 5, 2009, information about VP8 became tougher to find than President Obama's fabled Kenyan birth certificate. Google closed the deal on February 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 like "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 two 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. 

Posted By harsha on 8/2/2010 11:35:00 PM:

being involved in various codecs (from mpeg1/2 to avc), i can attest that vp8 could at the most match to h264 quality/performance. the only takeaway here that entices is "royalty free". however, there is no point to believe h264 baseline would be charged, i'm sure it would remain so.

Posted By BEN WAGGONER on 8/1/2010 9:41:37 PM

An interesting take on the current generation of web codecs.

I don't know that x264 got a fair shake, however, as normally using "Film" as the tuning mode yields superior results for this kind of content.

It is also notable that VP8 had so much better performance running as a DirectShow component rather than in a browser; there's a lot of overhead of doing media playback within a browser. It'd be interesting to compare playback of the H.264 files via Windows Media Player as well; most Vista and Windows 7 systems shipped with hardware accelerated H.264 decoding, so the CPU use would probably be much lower than even VP8 on newer machines; this is particularly important with Netbooks.

It would be also helpful to provide more details on the specific encoding settings used for each encode within each tool. Profile, Level, GOP length, and VBV would help make it a lot clearer that these are apples-to-apples comparisons.

Also, the VPx series of codecs have long been notable for aggressively throwing away detail. A low bitrate encode using very noisy source might tend to be biased towards VP8 simply because it throws away a lot of the noise which other encoders may try to retain. x264 has a noise reduction parameter that can be tuned to get a similar effect.

But it's certainly interesting to see where VP8 and WebM are today, and where they go over the next few years compared with H.264 implementations (and probably H.265 in a few years).

-Ben Waggoner

Posted By Jan Ozer on 7/31/2010 9:37:18 AM:

Hey FC:

Thanks for your note and compliment. I did mention in the article:

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 the development tools in the VP8 SDKs. Optimizations of the browser implementations are forthcoming."

That's why I looked at and reported on Windows Media Player results and concluded:

If the browser vendors and Google can reduce CPU playback requirements to levels shown in Media Player, however, the story changes considerably,.

As to Libvpx, as a competitor to H.264 in the streaming space, I though that readers would care most about VP8's browser performance with streaming-sized files. That said, I would have pointed out the x264 findings had they been available when I was researching, since they certainly are relevant. Thanks for pointing it out. 



Posted By FC Truter on 7/30/2010 9:02:01 PM

Very good and informative article. I'd just like to point out that just like H264 and x264, there is an alternative WebM encoder/decoder in the form of ffvp8. FFmpeg released this a short while ago, read further here:, and it boasts significantly better resource usage over libvpx. It might be fairer to include this encoder/decoder in the article, as Google themselves have said that they are not done optimizing their decoder.

Related Articles
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.
The standards body extended in perpetuity the royalty-free license on internet video that's free to users from 2015
Pay no attention to the man behind the Mac. HTML5 won't be a serious consideration for at least a few years.
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."
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.
Google's attempt to clarify its decision to drop H.264 from Chrome in favor of WebM creates even more questions than it answers