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.

In my tests, x264 produced slightly higher quality than the H.264 files produced by Squeeze with the Main Concept encoder, which was slightly better than WebM (Figure 4; click on the image for a larger version). In my view, however, slight differences in quality are irrelevant if the typical viewer wouldn't notice the difference absent side by side comparisons at normal data rates.

To explain, I produce my 720p test file at 800Kbps, which means that I'm allocating .029 bits per pixel in the 29.97 frame per second file. In comparison, YouTube produces their 720p H.264 video at about 2Mbps, which means an allocation of .072 bits per pixel, 2.5 times higher than mine. Why are my test files compressed so highly? Because if the data rate is high enough, all technologies look good and it's impossible to differentiate.

Ozer WebM Figure 4

Figure 4. Three comparison images produced with x264, WebM and H.264 using the Main Concept codec (click image to see a larger version). 

What's the most relevant test? In my recent review of video files produced by a range of broadcast and corporate sites, the lowest bits per pixel allocation that I found was 0.43, with most well above .07. Apple produces their iPad advertisements at .168 bits per pixel, about five times higher than my test file, while ESPN produces at .173 and CNN at .106. The notoriously penurious Tiger Woods publishes at .136, though perhaps he'll tighten this up after losing $750 million in his divorce.

Long story short, if YouTube produces their WebM-based 720p files at 2Mbps at 720p, only the most discriminating viewer will be able to distinguish it from H.264, and then, only with side by side comparisons, which, of course, viewers never have. It's not whether one technology is better than another; it's whether it's sufficiently better to make a difference for the typical viewer.

I should point out that some highly respected sources don't share this opinion. For example, the Graphics and Media Lab of Moscow State University produces a codec comparison every year; this year it included VP8. In terms of H.264 encoding quality, the report concludes that "The x264 encoder demonstrates better quality on average, and MainConcept shows slightly lower quality," which was my primary motivation for including x264 in this evaluation. Regarding VP8, the report concludes "When comparing VP8 and x264 VP8 also shows 5-25 lower encoding speed with 20-30% lower quality at average." I just didn't see that.

Then there's x264 developer Jason Garrett-Glaser's extensive analysis of VP8 and comparison to x264, which concludes that x264 is 28% better than VP8, though his comparisons seem to focus on 1080p delivery, so it's unclear how much you can generalize these results to streaming. In any event, Garrett-Glaser's analysis is wonderful reading for anyone who wants to understand the inner workings of the VP8 codec and WebM spec, as well as the patent issues that WebM may be facing.

Both these comparisons rely primarily on automated quality measurements like Peak Signal to Noise ratio (PSNR) and Structured Similarly (SSIM) which compare the encoded frame to the original and produce a comparative numerical score. I produce the files with the different technologies, making sure that they're within 5% of target data rate without dropped frames. I then grab frames for comparison purposes and watch the files side by side to assess the presence of motion artifacts. You can view my HD comparisons and my SD Comparisons—and comparative frame grabs—and draw your own conclusions.

Overall, I'm sure that Garrett-Glaser can coax more quality out of x264 than I can, but find comfort in the fact that the Moscow study concluded that MainConcept "shows slightly lower quality" than x264, which is consistent with my results. Certainly if you're using a MainConcept-based tool like Squeeze, the quality difference between VP8 and H.264 will be meaningless at most relevant data rates.

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