All posts tagged ‘WebM’

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.

MPEG LA: 12 Companies Own Patents Essential to Google’s VP8 Codec

MPEG LA, the self-styled one stop shop for motion video patent licenses, says that 12 different companies have come forward with patents “essential” to the VP8 algorithm championed by Google as a royalty-free compression standard. The organization met with these companies in June to discuss the formation of a patent pool, though there has not yet been a decision to determine whether a pool should be formed, or what its terms and conditions might be.

The organization started the search for VP8 patents in February, with the initial call for companies to come forward ending in March. That deadline came and went without comment from the company, so interviewed a spokesman by e-mail to find out what the current situation was. MPEG LA did not disclose which 12 companies held patents it felt to be essential to VP8, nor did it say how many patents there were in total. The group also did not say how many patents had been submitted for evaluation only to be deemed inessential.

The VP8 video codec is an integral part of WebM, the video file format that Google first proposed last May. WebM is marketed as a royalty-free format, in contrast to the widely used royalty-incurring H.264 codec. These royalties prevent H.264 from being incorporated into specifications such as HTML5′s native video support, as W3C, the group that governs the HTML standard, has a policy of only accepting royalty-free technology. Google maintains that although VP8 is patented, all the relevant patents were owned by On2, the company that originally developed VP8. Google’s purchase of On2 was finalized in 2010, and the search giant has since offered perpetual, royalty-free licenses to the patents.

With so many companies submitting patents of their own to MPEG LA, formation of a patent pool becomes much more likely, and the chance that WebM will retain its royalty-free position shrinks accordingly. That isn’t yet a foregone conclusion, however—though the companies have come forward and made initial submissions, they may decide that it’s not worth forming a patent pool for some reason. Even if they do, the decision to enforce their patents against VP8 users is separate; MPEG LA doesn’t enforce patents (it has sued companies, but for breach of contract, not patent infringement), and so it would be up to the individual members of the pool to take legal action against infringers.

Though the lawsuits could be brought against individual companies using VP8, rather than Google itself, it’s plausible that Google would get involved, to defend the value of its $100 million purchase of On2—though VP8 users will no doubt be reluctant to assume that such assistance will be forthcoming, as victims of Android lawsuits have had to fend for themselves. Indeed, with VP8 integrated into Android, those companies already being sued for Android patent infringement may yet find themselves on the wrong end of more legal action.

When asked for comment, Google’s response to was substantially the same as it always has been when asked about VP8 and patents; MPEG LA’s patent pool discussion is “nothing new,” that the “vast majority of the industry supports free and open development,” and that Google is “firmly committed to [...] establishing an open codec for HTML5 video.” The company also referenced its own effort to create a royalty-free patent-licensing initiative. However, if the 12 companies that have come forward aren’t members of that initiative, its value could be negligible.

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

File Under: HTML5, Multimedia, Web Basics

Google Pools WebM Video Supporters for Patent Protection

Google has announced the new WebM Community Cross License (CCL) initiative. The new group is designed to create a patent-safe haven around Google’s WebM video codec for HTML5 video. Members of the new CCL initiative agree to license any WebM-related patents to each other under royalty-free terms.

The WebM codec is one of several ways web developers can deliver native HTML5 video on the web, without requiring the Flash Player plugin or other proprietary, non-standard tools. The other major codec, H.264, is older and more widespread, but carries expensive licensing fees for broadcasting sites like YouTube.

So far Firefox 4, Opera, Chrome and Internet Explorer 9 (via a plugin) all support the WebM codec. Apple’s Safari and Mobile Safari are the lone holdouts for H.264 (IE9 also supports H.264).

Microsoft, which many suspected would ignore WebM, has thus far remained cautiously supportive of WebM. While the company doesn’t include support out of the box, it has pledged to support users who “install third-party WebM video support on Windows.” Many of Microsoft’s concerns about WebM revolve around unresolved patents and licensing.

Google’s CCL initiative seems geared at least in part to assuage Microsoft’s patent fears, laying out in clear terms how participating companies will handle patents. In short, organizations that join the CCL agree to license any essential patented WebM technologies to other members of the CCL under royalty-free terms, affording each member a measure of protection against potential patent lawsuits.

For the launch Google has put together 16 companies including AMD, Cisco, LG and Samsung, as well as browser makers Opera and Mozilla.

The elephant in the room is the MPEG-LA organization which governs the licensing of the H.264 codec. MPEG-LA recently closed out its call for the submission of patents essential to WebM, but has yet to announce any lawsuits against WebM. That does not of course mean that MPEG-LA has failed to come up with any potential WebM patent violations. In fact, not announcing anything helps build the sense of patent fear, uncertainty and doubt that surrounds WebM at the moment.

But MPEG-LA may have problems of its own. The U.S. Department of Justice is reportedly investigating the group to see whether the organization is trying to stifle competition from Google. Our friends at Ars Technica report that DOJ investigators are “looking into whether MPEG-LA or its member companies (which include Apple and Microsoft) are making an active effort to cripple adoption of WebM.”

While WebM’s future may still be in doubt, Google is clearly pushing forward regardless. The company has already removed H.264 support from its Chrome web browser and recently began serving up WebM videos on YouTube. With the new CCL initiative Google has expanded its range of WebM allies beyond just browser makers and is well on its way to having a patent pool that can back up WebM against MPEG-LA.

See Also:

File Under: HTML5, Multimedia, Web Apps

YouTube Begins Serving Up Native WebM Video

YouTube has announced it will begin offering HTML5 videos in the WebM codec to web browsers that support it. So far YouTube says that it has encoded 30 percent of its videos in WebM, which accounts for 99 percent of all traffic to the site.

YouTube’s move to WebM is no surprise; Google has already dropped the competing H.264 codec from its Chrome web browser and it was only a matter of time before YouTube began moving to WebM as well.

The WebM Project, a partnership between Google, Mozilla, Opera and dozens of other software and hardware makers, provides web developers a way of embedding video and audio in HTML5 pages without plug-ins, and without the need to pay the expensive licensing fees that surround the competing H.264 codec. Currently WebM video works in Firefox 4, Chrome, Opera and Internet Explorer (via a plugin). The other main HTML5 video codec, H.264, works on all Apple devices and in Internet Explorer 9.

While YouTube is adding WebM support, it isn’t following Chrome’s lead and dropping H.264. The site will continue to serve up H.264 video to those browsers that support it (in other words, Safari, Mobile Safari and Internet Explorer 9).

Despite the new WebM support, YouTube still isn’t serving up HTML5 videos by default. If you’d like to get in on the new WebM fun, you’ll still need to sign up for the opt-in HTML5 player.

See Also:

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: