Look Ma, H.264 video in Firefox, no Flash necessary. Image: Screenshot/Webmonkey.
The latest nightly builds of desktop Firefox now support the ubiquitous H.264 video and MP3 codecs. When the current Firefox Nightly arrives in final form later this year, Firefox users will no longer need the Flash plugin to play H.264 web video in Firefox.
Firefox for Android and Firefox OS already support H.264 and MP3, but on the desktop the new H.264 support is, thus far, only available in the Windows 7 Nightly release.
You can grab the latest version of Firefox Nightly from the Nightly downloads page. Once installed head to about:config and turn on the preference media.windows-media-foundation.enabled.
Mozilla long opposed supporting the H.264 codec because it’s patent-encumbered and requires licensing fees. For better or worse it’s also the most popular codec for HTML5 video on the web, which drove Mozilla to take the pragmatic approach and add support to Firefox. Instead of including the codec directly in Firefox, the browser will rely on OS-level tools to play H.264 video.
Eventually all platforms except Windows XP will get OS-native codec support for H.264 video. Windows XP, which lacks OS-level tools for H.264, will continue to use the Flash plugin to play H.264 movies.
Even if you’re not a Windows 7 user there are still a few new tricks in Firefox Nightly, including a revamped downloads panel that’s no longer a separate window (and which bears more than a passing resemblance to what you’ll find in Safari 6) and support for the new CSS scoped style attribute.
[Update: As BWRic points out in the comments below the new downloads window/panel design was actually a Firefox innovation that the Safari team got around to implementing first. You can check out former Firefox UX Lead Alex Limi’s original sketches of the overlay window on his blog as well as a follow up post when Safari revealed its take on the design. It’s worth noting that Limi’s sketches have a nice progress bar in the icon (which Safari adopted as well), which is missing from the current Firefox implementation.]
Right now support is limited to Android 4.1 (Jelly Bean) and Samsung phones running Android 4.0 (Ice Cream Sandwich). Mozilla is working to fix some bugs that currently prevent H.264 from working on other devices. Support for older Gingerbread and Honeycomb Android devices is still in the works.
This is the first time Mozilla has released a web browser with support for the popular H.264 codec. The company previously refused to support H.264, citing royalty and licensing concerns. Instead Mozilla touted Google’s WebM codec, which offers many of the benefits of H.264 in a royalty-free package. Unfortunately for Firefox fans WebM has failed to gain ground against H.264.
Adobe’s Flash Player plugin can also play H.264 video and, until Adobe decided to abandon Flash for Android, that was Mozilla’s solution for H.264 video in Firefox for Android.
With WebM adoption lagging and Flash for Android dead, Mozilla found itself in a bind. Some estimates claim up to 80 percent of video on the web is encoded in H.264, forcing Mozilla to choose between supporting H.264 on Android or leaving Firefox users with no way to watch video on mobile devices. Fortunately for Firefox users, Mozilla decided to be practical and support H.264.
Technically the new H.264 support is not a part of Firefox, rather the browser is tapping into Android’s underlying H.264 support to decode video. That means royalty payments are covered by hardware makers, not Mozilla.
I tested Firefox for Android’s H.264 on a Samsung Galaxy Nexus running Android 4.1 and for the most part H.264 video worked without issue. Some popular video sharing sites, however, appear to be doing OS/browser detection rather than feature detection — I’m looking at you Vimeo — which means that, even though your phone can play the video, Vimeo thinks it can’t.
Hopefully Vimeo and other sites doing the same thing will fix this soon because Mozilla is planning to bring the same H.264 support to the desktop. As with Firefox for Android, desktop Firefox won’t have its own decoder, but will rely on OS-level H.264 decoders. For end users though the result will be the same — video that just works.
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.
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.”
MPEG LA, the one-stop shop for motion video patent licenses, yesterday announced a call for patents essential to the VP8 video compression algorithm — the algorithm that is fundamental to Google’s WebM video format. MPEG LA is asking organizations that hold patents believed to cover integral, unavoidable parts of the VP8 algorithm to come forward and submit those patents to the licensing company. The patents will in turn by analyzed by MPEG LA, and those deemed to be relevant will be pooled together. The pooled patents will then be available to license as a single convenient bundle.
In its promotion of WebM and VP8, Google has insisted that all the relevant patents were developed by codec company On2, which Google purchased last year. The patents can be licensed from Google without payment of any royalties or any restrictions on usage. Google has been heavily promoting WebM for use with the HTML5 <video> tag, which allows plugin-free video to be embedded in webpages, and the royalty freedom is a key part of WebM’s value proposition.
Competitive codecs such as the open and industry standard H.264 require royalties to be paid by software and hardware developers. Companies like Opera and Mozilla, as well as the W3C group that is developing the HTML5 specification, deem these royalties be an unacceptable impediment to their usage. They have no such qualms about the royalty-free WebM.
If MPEG LA is successful in assembling a patent pool, that royalty freedom could come to an end. The company is soliciting patent submissions until March 18th. Once the submissions have been made, it will determine which patents are essential to VP8; only those patents that are unavoidable can form part of the patent pool. The owners of those selected patents will then decide on the license conditions they wish to impose, and these conditions could include royalty payments.
Whether this will happen, of course, is the big question. MPEG LA might fail to form a patent pool altogether: it may receive no relevant patent submissions, in which case the patent pool process will likely end. Such an outcome still won’t mean that WebM is in the clear — a company may feel that it’s more lucrative to avoid a patent pool and allow WebM usage to become more widespread before asserting claims — but it would probably imply that there aren’t dozens of potential claimants just waiting to come forward.
This sort of outcome might well see Microsoft’s current neutral stance towards WebM (it will work in Internet Explorer 9, just as long as a suitable third-party codec is installed) become more overtly positive. Redmond might start shipping a WebM codec of its own, for example.
If MPEG LA does form a patent pool, the license terms will be critical. MPEG LA exists to monetize patents, however, so it’s unlikely that any patent pool would permit the kind of indiscriminate royalty-free license that Google currently offers. More likely, they would choose terms similar in kind to those of H.264; Web video may be free, but decoders still incur a royalty. This would put WebM implementors in a difficult position — either drop WebM support, pay up, or risk going to court to fight a patent infringement suit.
An infringement suit is an unappealing prospect: even if you win, the drain on your financial resources can mean that ultimately, you lose. This is especially problematic for organizations like Mozilla, since Google offers no indemnification for users of WebM — if Mozilla gets sued, Google won’t step in to help. As such, the safest, most conservative option for Opera and Mozilla would be to drop support. Google has deeper pockets and can better sustain a legal attack, but even there, the company has to weigh its options carefully. A lost court case could cost tens of millions of dollars. Paying up just to avoid the problem may very well be the better option.
But paying up is problematic too. VP8 is, for most purposes, inferior in quality to H.264. H.264 is much more widespread in software tools, hardware accelerators, and so on: it’s enormously widespread already. If VP8 loses its key feature — royalty freedom — implementers may very well decide that, since they have to pay anyway, they’d be better off paying for the superior, more widely used H.264 license, and abandoning WebM entirely.
Whatever happens — and it will probably be many months before we find out — this is bad news for WebM. The formation of a patent pool directly undermines Google’s claims about the codec — and yet, even if MPEG LA fails to create a pool, question marks surrounding the codec will remain.
This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.