Crash course: HTML 5 video
- — 20 July, 2010 03:38
If you want to watch Internet-delivered video on your PC, the vast majority of Web sites have settled on a single, consistent way to do that. That's the good news. The bad news is that this single, consistent delivery system is Adobe Flash, with all its security and stability issues.
But now a new way to deliver video through a browser is coming to the fore, one intended to be native to the browser itself: HTML 5's VIDEO tag. In this article I'll look at how the <VIDEO> tag can be used with the new generation of browsers. I'll also examine how parts of this equation -- the browsers and, to some degree, the video formats themselves -- are also still very much in flux.
Online video before HTML 5
One could fill a decent-size book talking about all the formats that have been used to deliver Web video at one time or another: Microsoft's .avi and .wmv container formats and the gang of codecs delivered with them, Apple's QuickTime, RealNetworks' RealVideo and RealAudio formats, and so on. Microsoft's Silverlight also deserves mention, since it allows providers such as Netflix to distribute content with embedded copy protection -- a feature not likely to fall out of demand as long as money changes hands for video content.
However, the video delivery system that's most widely deployed right now is Adobe's Flash.
The Flash Player was, and still is, one of the few browser add-ons that almost everyone is likely to have. Browsers on Macs and PCs alike typically support Flash by default, since a growing amount of Web content in general depends on it. It could be argued that Flash has become a video-delivery system as a byproduct of its original intention, which was to bring vector-based animation to the Web.
But Flash has problems as a video delivery system. It's proprietary. It requires the use of third-party code rather than something native to the browser. It has been lambasted for its lack of security and instability. The list goes on. It's a solution, when people have been hungering for the solution.
Hello to the VIDEO tag
The history of the VIDEO tag starts with the Web Hypertext Application Technology Working Group (WHATWG), a consortium made up of folks from Apple, the Mozilla Foundation and Opera Software. The WHATWG was created in 2004 to focus on the development of HTML 5 as a response to what it felt was the disregard of the World Wide Web Consortium (W3C) for real-world developers vis-à-vis XHTML and the then-extant HTML standards.
The first proposals for a VIDEO tag were submitted to the WHATWG in 2007 by Opera Software. The idea was simple: Create a framework in which Web browsers can natively play back video without being forced to fall back on third-party plug-ins. The user gets the experience of video that just works, those hosting the video have less maintenance to perform, and everyone walks away happy.
That's the theory, anyway. The practice has been another story entirely.
The codec conundrum
When the <VIDEO> tag was first proposed in the HTML 5 draft specification, one key omission from the spec was which video (and audio) codecs would be natively supported by the browser. As a result, while there are several video codecs that can be used in conjunction with the <VIDEO> tag, browser makers are not obliged to support any one of them: It's entirely their choice which codecs to include support for.
The original plan involved specifying the Theora video and Vorbis audio codecs as a baseline that all browsers should be able to play, but this was dropped in favor of an approach where no specific codec was recommended. Instead, the WHATWG expressed a desire for a codec that could be used in an unencumbered fashion and had a better guarantee of patent indemnity than Theora/Vorbis offered at the time.
In the end, the following three codecs have emerged as the main contenders for <VIDEO> tag support: H.264, Theora and VP8.
H.264: Microsoft and Apple have been major proponents of the H.264 codec family, which has already been broadly implemented and supported -- not just on the Web, but in cameras, in Blu-ray discs, and many other media that need powerful, efficient compression.
What's contentious about H.264 is not the technology itself but the licensing. H.264's usage is governed by the MPEG LA group, which levies a sliding scale of fees for H.264 based on the intended use. That said, the vast majority of end users on the Web might never pay anything for using H.264, for a couple of reasons.
First, the MPEG-LA has stated that for the next five years it will collect no royalties for H.264 Web streams that are offered free to end users.
Second, in the cases where you're dealing with for-pay content, odds are that the usage fees have already been assumed by someone else. For example, if you're encoding stuff in Windows and uploading it to YouTube as a pay-per-view item, you pay no licensing fees for using H.264, because any costs that might be levied have already been assumed by (in this case) Microsoft and Google.
For additional information on this issue, Ed Bott of ZDNet has explained how H.264 licensing fees work and why it wouldn't be in the MPEG LA's interest to suddenly ratchet up licensing fees when the current free-to-stream provisions for Web playback are up for revision in a few years. Florian Mueller's analysis is also interesting -- he examines the MPEG LA licensing terms from the point of view of an opponent of software patents, noting that the MPEG LA's licensing scheme, while not an ideal arrangement, does serve a useful function in a world where software patents exist and must be acknowledged.
That said, companies like Mozilla have not been set at ease -- for example, according to Mike Shaver, vice president of engineering at Mozilla Corp., MPEG LA's licensing isn't flexible enough to make solid exceptions for free software. Mozilla has opted to support Theora/Vorbis directly in its Firefox browser (and will support WebM in Version 4.0), and it has no plans to add native H.264 support.
Theora: Free software proponents have advocated the open Theora video format (with its matching Vorbis audio codec), which requires no licensing fees at all and has implementations immediately ready to use. But Theora has been criticized on a number of grounds: It isn't as technologically advanced as other codecs; there isn't much material encoded in the format, so current video would have to be recoded; and Theora's patent status could be subjected to future legal challenges (something Steve Jobs has hinted at).
VP8: A more evolved version of the Theora codec family (they share common ancestors), VP8 was developed by On2 Technologies, which also created one of Flash's video codecs. Google has since purchased On2 outright, and while Google now owns the patent for VP8, it's allowing unrestricted use of the codec without licensing fees under the banner of "the WebM Project." (WebM is Google's name for VP8 video plus Vorbis audio.)
This makes VP8 sound like a sure thing, but there are two problems. The first is that there are serious questions about how polished the spec is -- a factor that has serious implications for, say, hardware devices that shoot video directly in VP8. If VP8 is going to be in flux, then cameras that shoot video in VP8 would need to be firmware-upgradable (and have updates published by their makers) to use newer, better performing versions of the codec.
Another problem is VP8's quality and compression efficiency compared to H.264. One analysis, by Jason Garrett-Glaser, a developer on the FFmpeg project, has put the quality of VP8 on a par with H.264's "baseline" spec -- in other words, good but not great, and with H.264 way out in front in certain respects. He also believes that VP8's spec relies way too much on the snippets of code provided by Google. Most specifications for a standard (like the <VIDEO> tag itself) are drafted and discussed in depth before a single line of code is written; in Garrett-Glaser's view, the only real VP8 spec we have right now is the code, a cart-before-the-horse situation. Next: How to add HTML 5 to your site