All posts tagged ‘HTML5 Video’

Idealism vs. Pragmatism: Mozilla Debates Supporting H.264 Video Playback

The HTML5 video element promised to be a game-changer for internet media publishing. It provided a vendor-neutral standards-based mechanism for conveying video content on the web without the need for proprietary plugins while offering a path for tighter integration of video content on the web and broader platform support than has historically been available through plugins.

But the HTML5 video element has yet to live up to its full potential, because a dispute over video encoding has prevented the standard from being implemented consistently across all web browsers. Mozilla, which has long resisted adoption of H.264 on ideological grounds, is now preparing to support it on mobile devices where the codec is supplied by the platform or implemented in hardware.

The popular H.264 format is widely viewed as the best technical choice for encoding Internet video, but its underlying compression technologies are covered by a wide range of patents. This has raised the question of whether its appropriate for a standards-based web technology to rely on a patent-encumbered video format that requires publishers and software implementors to pay licensing fees.

The ubiquity of the web and its strength as a platform for innovation are partly due to the royalty-free licensing model that the W3C mandated for web standards. As Mozilla and other parties have argued over the past few years, the use of a patent-encumbered video format is antithetical to the principles of the open web. Critics of the H.264 licensing model have advocated the use of other video codecs, causing a split in the browser landscape.

Apple and Microsoft both support H.264 while Mozilla and Opera oppose the use of patented codecs. Google previously favored H.264, but shifted its position after opening VP8, a codec that the search giant has put forth as a viable alternative to H.264 for Internet video. Google vowed to remove H.264 support from its Chrome web browser at some undisclosed future date, but has not yet done so.

The lack of universal support for a single codec has proved problematic because it compels content creators to either encode their video in multiple formats or fail to support large segments of their audience. Building consensus around a single codec would remove one of the biggest remaining impediments to widespread adoption of the HTML5 video element.

A Change in Course

Mozilla’s strong commitment to the open web made it seem as though the organization’s position was intractable. Mozilla’s resolve on the matter appears to have cracked, however, as the organization confronts the challenge of bolstering its credibility as a mobile platform provider.

Andreas Gal, Mozilla’s director of research, announced on a public mailing list today that he wants to proceed with a plan that would enable H.264 decoding on Mozilla’s Boot2Gecko (B2G) mobile operating system. The proposed change would allow the video element in Mozilla’s HTML rendering engine to rely on codecs that are supplied by the underlying operating system or dedicated video hardware.

In addition to enabling H.264 playback in B2G, the proposed patch would also enable it in the Android version of mobile Firefox. Gal further expressed support for eventually taking similar measures in the desktop version of Firefox, with the stipulation that it would only be practical if the implementation ensured support for virtually all users.

Modern versions of the Windows operating system expose an H.264 codec to third-party software, but Windows XP does not. Gal said that he’d favor supporting H.264 in Firefox on the desktop if a means could be identified for ensuring that XP users (which represent a very significant portion of Firefox’s audience) aren’t left out. This is a radical change of policy for Mozilla, one that could have significant ramifications for the future of video on the web.

Despite the pragmatic concession, Gal says that Mozilla’s ideological position in favor of open codecs remains unchanged. The organization is still hopeful that an unencumbered codec will eventually prevail.

“We will support decoding any video/audio format that is supported by existing decoders present on the system, including H.264 and MP3. There is really no justification to stop our users from using system decoders already on the device, so we will not filter any formats,” he wrote. “I don’t think this bug significantly changes our position on open video. We will continue to promote and support open codecs, but when and where existing codecs are already installed and licensed on devices we will make use of them in order to provide people with the best possible experience.”

The option of using system-provided codecs is an obvious solution that would allow Firefox to play H.264 video without having to ship the code itself. We’ve discussed (and endorsed) this approach in some of our previous coverage, but Mozilla has historically rejected it on ideological grounds. In the past, Mozilla’s position was that it didn’t want to take any steps that would legitimize or encourage the use of a patent-encumbered codec. The organization is no longer maintaining that argument.

Google’s major investment in advancing its unencumbered VP8 codec gave open web advocates hope that H.264 could still be displaced, but it hasn’t happened. The lack of follow-through from Google on its promise to remove H.264 from Chrome has eroded faith in the search giant’s ability to popularize VP8. Gal says that it’s no longer feasible to wait for the open codec to gain additional traction.

“Google pledged many things they didn’t follow through with and our users and our project are paying the price,” he wrote. “H.264 wont go away. Holding out just a little longer buys us exactly nothing.”

The proposal to support H.264 in mobile Firefox has generated a tremendous amount of controversy among Mozilla developers. The critics include Mozilla employees and independent contributors. Mozilla’s Joe Drew characterized the proposal as “capitulating on Free codecs” and expressed concern that the mobile-centric rationalization amounts to pushing an ideological compromise through the back door.

Firefox developer Justin Dolske also expressed some concerns. He pointed out that the possibility of enabling support for system codecs was discussed once before in relation to Fennec on the Nokia tablet devices and that it was rejected at the time for ideological reasons. He asked that the issue receive further discussion, specifically some clarification about what circumstances have changed that necessitate a reversal of the previous policy.

“The state of HTML5 video started off from a bad place, and to be fair still isn’t in a good place. So reassessing Mozilla’s stance is not unreasonable. But I think if Mozilla is going to do an about-face on open video standards (and it is an about-face), then there should be some serious discussion about it. Certainly more than than a few terse words saying it’s hopeless and obvious,” he wrote. “We spent a lot of time and made a lot of blog posts about why H.264 was bad for the web. Leaving those who advocated for us suddenly high-and-dry doesn’t feel like the right thing to do.”

The debate has continued on the mailing list. There is also some preliminary discussion from certain participants in the debate about whether it would make sense at this point to simply license the codecs and ship them directly in the browser. Such a move, which would be a step further than merely supporting external codecs where available, would ensure support for Windows XP users but would detrimentally impact downstream distributors of Firefox code.

The outcome of the debate is unclear, but it currently appears probable that the plan to support system-provided codecs will be upheld and carried out. There are already some patches that have been hashed out, which means it can be practically implemented without much difficulty. The questions about how to proceed on the desktop and whether to license and ship the codecs are more tentative in nature and will likely take more time to be resolved.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

HTML Editor Calls HTML5 Video Copy-Protection Proposal ‘Unethical’

A newly proposed web standard could bring DRM to web video.

The Encrypted Media Extensions draft — which is backed by the likes of Google, Microsoft, and Netflix — defines a framework for bringing DRM, or “protected media content” as it’s called in the spec, to a web browser near you.

The proposed standard is controversial to say the least, and has already been dismissed as “unethical” by Ian Hickson, the WHATWG’s HTML spec editor. Hickson goes on to say that the proposal “does not provide robust content protection, so it would not address this use case even if it wasn’t unethical.”

The use case Hickson refers to is solving one of the biggest obstacles to the wider adoption of HTML5 video — it lacks the copy protection mechanisms that media companies are accustomed to having. Currently streaming media services like Netflix and Hulu rely on plugins like Adobe Flash to deliver protected content. While such services might like to abandon Flash in favor of HTML5 video, they are often contractually required to have copy protections in place first.

As it stands, the HTML5 video spec offers no means of adding such protection. The proposed Encrypted Media Extensions standard would not actually define any DRM schemes itself. Rather it would add a new set of API extensions for the HTMLMediaElement which would provide the necessary components for a DRM scheme. The actual content protection would be handled by “an appropriate user agent implementation.” That means technically the actual DRM would not be in the spec, though arguing that the Encrypted Media Extensions doesn’t bring DRM to HTML is roughly the same as saying you didn’t inhale.

An overview of how the proposed Encrypted Media Extensions would work. (Image from W3C)

But there’s a very serious problem with the proposal as it stands — open source browsers. As Mozilla’s Chris Pearce writes on the HTML mailing list, “since the decoded video frames are stored in memory (as are audio samples) so that they can participate in the HTML rendering pipeline, how do you guard against an open source web browser simply being patched to write the frames/samples to disk to enable (presumably illegal) redistribution of the protected content?”

The answer, according to Netflix’s Mark Watson, is that the decryption could be handled at the firmware or hardware level. “If my understanding is correct,” writes Watson, “it’s not unknown for open source products to make use of or even ship with closed source components, such as drivers, for access to platform or device capabilities.”

The Encrypted Media specification is currently a draft proposal, which means it’s a long way from becoming a W3C-blessed standard. It does enjoy the backing of some high-profile W3C members like Google and Microsoft, but with Hickson very adamantly against it and Mozilla unlikely to support it in its current form, it’s not likely to move beyond the draft stage without some serious revisions. That does not, however, mean that pressure to add some sort of DRM to HTML5 video is going to go away any time soon.

File Under: HTML5, Web Standards

HTML5 Video on the Web Today

The hype surrounding HTML5 video has thankfully receded from the high water mark of 2011. But the absence of hype doesn’t mean HTML5 video is a thing of the past. In fact, while it’s true that HTML5 video still can’t completely match all of the features available in Flash, the state of HTML5 video on the web continues to improve with every new browser release.

For a very thorough rundown of exactly where and how well HTML5 video works on the web right now, check out the excellent report on the state of HTML5 video from Long Tail Video. Put together by the makers of JW Player, an HTML5 video player toolkit, the state of HTML5 video report is mercifully free of any evangelism for any particular technology. Instead it offers a level-headed look at reality, answering the basic questions — where can you use HTML5 video? How well will it work for users? And when will you need Flash fallbacks?.

HTML5 video enthusiasts will be happy to know that the state of native video on the web is looking better these days. Two-thirds of all the browsers on the web now support the HTML5 video tag. Support for the various video tag attributes has improved as well, with both Safari and Chrome offering full support.

Still, for all the bright points in the report, there is clearly still a need for Flash fallbacks if you want your video to reach the widest possible audience. With older versions of Internet Explorer still lingering (IE 9 and up support the HTML5 video tag) and the lack of support for closed captions and audio descriptions in any browser, Flash will likely remain the only option for at least some portion of the web for some time.

The good news is that, in some cases, the state of HTML5 video will be improving very soon, for example Firefox 10, which will be released in final form very soon, will support native fullscreen playback.

For more details on which parts of HTML5 video work and which don’t in today’s browsers, be sure to read through the full report.

File Under: Browsers, Web Standards

Google Gives IE 9 the Gift of WebM

Now that Microsoft’s Internet Explorer 9 is out in the wild, Google has released its WebM video plugin which will allow IE 9 to play WebM video. The new IE 9 supports the HTML5 video tag out of the box, but it can only play back H.264 video, not the Google-backed WebM video codec.

If you’ve upgraded to IE 9 and would like to make sure that WebM video will work when you encounter it, head over to the Google WebM for IE 9 download page.

For all the promise of HTML5 video, there is, as of now, no single video codec that works in every web browser. That’s a pain for publishers who need to encode every video in two codecs and a pain for users, who need to install extensions, like Google’s new WebM for IE 9 or Microsoft’s H.264 plugins for Firefox and Chrome (Windows only).

Until recently Google’s Chrome web browser was the only browser that supported both formats (and the OGG format), but then Google announced it would drop support for H.264 in Chrome in order to drive adoption of WebM video. Converting YouTube videos to use WebM would be a huge boon for WebM, but so far Google has not done that.

It would also greatly help the WebM cause if Adobe Flash could play WebM video. Since there is no “it just works” codec for HTML5 video, most websites still fall back to Flash video. Because Flash can play H.264 video it makes more sense for publishers to encode video in H.264 and serve it natively to Safari and IE 9 users, while falling back to a Flash container for browsers that don’t natively support H.264.

If the WebM project is going to make it through these transitional times, it needs to get Adobe to support WebM in Flash, which would remove one of H.264′s primary advantages — that it works in Flash as well. In the mean time, at least there is the IE 9 plugin, which means Apple’s Safari is now the only browser on the web that can’t play WebM video.

See Also: