WebM vs. H.264: A Closer Look
Which takes us neatly back to playback requirements, which is where we started. Let's introduce the computers and browsers.
Briefly, I tested on four computers. The MacBook Pro has a 3.06 GHz Core 2 Duo CPU, 8 GB RAM and was running OS 10.6.2, with an NVIDIA GeForce 9600M graphic chip. The iMac has a 2.0 GHz Core 2 Duo CPU with 2.5 GB of RAM, and an ATI Radeon X1600 graphics chip while running OS 10.6.
The Hewlett Packard 8710w was running a 64-bit version of Windows 7 on a 2.2 GHz Intel Core 2 Duo CPU with 2 GB of RAM, and an NVIDIA Quadro FX 1600M graphics controller. The Acer Aspire One is a netbook running Windows XP Home Edition, with a 1.60 GHz Intel Atom CPU, 1 GB of RAM and an integrated Intel 945 Express Chipset for graphics. All computers except the Aspire netbook were measured playing back the 720p file and Table 3 shows the browsers used in the respective tests.
During testing, I followed this procedure:
• Turned off as many background processes as possible
• Updated my graphics card drivers
• First I loaded the page, and waited until the video completely downloaded (watching the progress bar on the bottom of the player)
• Then I played the file, monitoring and recording the CPU usage on Windows Task Manager and % Idle on Activity Monitor. Obviously, to compute CPU utilization for the Macs, I subtracted the % Idle from 100%.
Table 4 shows the results grouped by format and playback environment. Pulling some conclusions out of these disparate numbers is challenging, but here goes. Most obvious is the fractured nature of the HTML5 market, which still lacks a single codec that can play across all platforms. With Microsoft only supporting VP8 playback on IE 9 if the codec is otherwise installed, and Apple squarely in the H.264 camp, Google's open sourcing of VP8 has done nothing to reduce this logjam. As you probably have heard, Adobe has announced that a future version of the Flash Player will support WebM at some point in the future; that may end up being the only easy way to display WebM video across all relevant browsers. However, one suspects that you could buy a Tastee Freez in Hades before WebM will play on the walled garden of Apple iDevices.
If you're a Mac owner who consumes lots of video, you can see that results vary by browser and whether your Flash implementation is hardware accelerated. If it is, Safari is your best option; if not, go with Chrome. As a random thought, someone watching Flash-video on a non-accelerated Mac via Opera or Safari probably considers Flash a CPU Hog -- I wonder if their opinion would change if they did switch to Chrome. Ditto for HTML5-based H.264 playback on the Mac, where Safari is the efficiency king, and Chrome the laggard.
Regarding WebM, on the platforms without Flash GPU acceleration (the iMac and Aspire), the most efficient WebM implementation required less CPU than the most efficient Flash implementation, though the WebM implementations varied more widely. Absent hardware acceleration, CPU utilization on playback appears to be a wash.
As mentioned at the top, when playing a WebM 720p file on the Hewlett Packard 8710w via Media Player, CPU requirements dropped to 18%, about 1/3 the requirement of the most efficient browser and within spitting distance of GPU accelerated Flash playback. On the Aspire for the 640x480 file, CPU load dropped to CPU load dropped to 24%, 30% with hardware acceleration disabled, which is much lower than any other tested technology. If any of the browser vendors can enable this level of efficiency for web-based playback, WebM would have a significant competitive advantage over H.264, whether Flash or HTML5-based. If not, given that many newer computers and mobile devices offer some measure of Flash acceleration, WebM may trail in quality, encoding speed and playback efficiency.
As it stands today, WebM's value proposition is basically that its free, and better than Ogg Theora, though way too tough to decode as compared to rapidly expanding base of GPU-accelerated H.264. If the browser vendors and Google can reduce CPU playback requirements to levels shown in Media Player, however, the story changes considerably, at least for pay per view and subscription based video distributors, who currently pay a fee to deliver H.264 video. Ironically, given the lack of universal HTML5 browser support, the most efficient way to distribute WebM to your customers may be via the Flash Player, assuming that the Flash Player's CPU playback requirements are competitive. You'll probably still have to write checks to MPEG-LA for delivering to Apple's iDevices, however.
As you probably know, H.264 is royalty free for free Internet distribution, at least through 2015, so there's no financial incentive to switch. If your organization wants to migrate towards HTML5, WebM doesn't provide that single codec solution, and is still lower quality than H.264, however small the difference, and takes longer to encode. Overall, for those not charging for their video, H.264 is still a better solution, and given the rapidly increasing size of the GPU-accelerated installed base, will like remain so unless and until Google creates distribution channels that you can't access with H.264.
Google's attempt to clarify its decision to drop H.264 from Chrome in favor of WebM creates even more questions than it answers
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.
Pay no attention to the man behind the Mac. HTML5 won't be a serious consideration for at least a few years.
The standards body extended in perpetuity the royalty-free license on internet video that's free to users from 2015
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.