Cisco’s H.264 Good News

As I noted last year, one of the biggest challenges to open source software has been the patent status of video codecs. The most popular codec, H.264, is patent-encumbered and licensed by MPEG LA, under terms that prevent distributing it with open source products including Firefox. Cisco has announced today that they are going to release a gratis, high quality, open source H.264 implementation — along with gratis binary modules compiled from that source and hosted by Cisco for download. This move enables any open source project to incorporate Cisco’s H.264 module without paying MPEG LA license fees.
 
We are grateful for Cisco’s contribution, and we will add support for Cisco’s OpenH264 binary modules to Firefox soon. These modules will be usable by downstream distributions of Firefox, as well as by any other project. In addition, we will work with Cisco to put the OpenH264 project on a sound footing and to ensure that it is governed well. We have already been collaborating very closely with Cisco on our WebRTC implementation, and we are excited to see Cisco deepening their commitment to the Open Web.  Or, as Jonathan Rosenberg, Cisco CTO for Collaboration puts it,

Cisco has a long-standing history of supporting and integrating open standards, open formats and open source technologies as a model for delivering greater flexibility and interoperability to users. We look forward to collaborating with Mozilla to help bring H.264 to the Web and to the Internet.

Here’s a little more detail about how things are going to work: Cisco is going to release, under the BSD license, an H.264 stack, and build it into binary modules compiled for all popular or feasibly supportable platforms, which can be loaded into any application (including Firefox). The binary modules will be available for download from Cisco, and Cisco will pay for the patent license from the MPEG LA. Firefox will automatically download and install the appropriate binary module onto each user’s machine when needed, unless disabled in the user’s preferences.
 
Interoperability is critical on the Internet, and H.264 is the dominant video codec on the Web. The vast majority of HTML5 streaming video is encoded using H.264, and most softphones and videoconferencing systems use H.264. H.264 chipsets are widely available and can be found in most current smartphones, including many Firefox OS phones. Firefox already supports H.264 for the video element using platform codecs where they are available, but as noted in my last blog post on the topic, not all OSes ship with H.264 included. Provided we can get AAC audio decoders to match, using Cisco’s OpenH264 binary modules allows us to extend support to other platforms and uses of H.264.
 
While Cisco’s move helps add H.264 support to Firefox on all OSes, we will continue to support VP8, both for the HTML video element and for WebRTC. VP8 and H.264 are both good codecs for WebRTC, and we believe that at this point, users are best served by having both choices.
 
Of course, this is not a not a complete solution. In a perfect world, codecs, like other basic Internet technologies such as TCP/IP, HTTP, and HTML, would be fully open and free for anyone to modify, recompile, and redistribute without license agreements or fees. Mozilla is fully committed to working towards that better future. To that end, we are developing Daala, a fully open next generation codec. Daala is still under development, but our goal is to leapfrog H.265 and VP9, building a codec that will be both higher-quality and free of encumberances. Mozilla has assembled an engineering dream team to develop Daala, including Jean-Marc Valin, co-inventor of Opus, the new standard for audio encoding; Theora project lead Tim Terriberry; and recently Xiph co-founders Jack Moffitt, author of Icecast; and Monty Montgomery, the author of Ogg Vorbis.
 
Cullen Jennings, Cisco Fellow, Collaboration Group, says:

Cisco is very excited about the future of royalty free codecs. Daala is one of the most interesting ongoing technical developments in the codec space and we have been contributing to the project.

At Mozilla we always come back to the question of what’s good for the users and in this case that means interoperation of copious H.264 content across OSes and other browsers. We’ve already started looking at how to integrate the Cisco-hosted H.264 binary module, and we hope to have something ready for users in early 2014.
 
Watch this space for more exciting developments in WebRTC, Daala, and open web video.
 
/be

The Bridge of Khazad-DRM

To lighten the mood:

BalrogGandalf gandalf-sign

But actually, I’m serious.

People are rightly concerned about what is going on in the W3C with DRM, as couched in the Encrypted Media Extensions (EME) proposal. Please read Henri Sivonen’s explanation of EME if you haven’t yet.

As usual for us here at Mozilla, we want to start by addressing what is best for individual users and therefore what’s best for the Open Web, which in turn depends in large part on many interoperating browsers, and also on open source implementations with a significant combination by number and market share among those browsers.

We see DRM in general as profoundly hostile to all three of: users, open source software, and browser vendors who aren’t also DRM vendors.

Currently, users can play content that is subject to DRM restrictions using Firefox if they install NPAPI plugins, really Flash and Silverlight at this point. While we are not in favor of DRM, we do hear from many users who want to watch streaming movies to which they rent access rather than “buy to own”. The conspicuous example is Netflix, which currently uses Silverlight, but plans to use EME in HTML5.

(UPDATE: Netflix is using EME already in IE11 on Windows 8.1 without Silverlight. And Chrome OS has deployed EME as well. Apple too, in Mavericks.)

What the W3C is entertaining, due to Netflix, Google, and Microsoft’s efforts, is the EME API, which introduces new and non-standard plugins that are neither Silverlight nor Flash, called Content Decryption Modules (CDM for short), into HTML5. We see serious problems with this approach. One is that the W3C apparently will not specify the CDM, so each browser may end up having its own system.

We are working to get Mozilla and all our users on the right side of this proposed API. We are not just going to say that users cannot have access to streaming Hollywood movies, as that is a good way to lose market share and not have any product with which to uphold our mission.

Mozilla’s mission requires us to build products that users love — Firefox, Firefox for Android, Firefox OS, and Firefox Marketplace are four examples — with enough total share to influence developers, and therefore standards. Given the forces at play, we have to consider EME carefully, not reject it outright or embrace it in full.

Again, we have never categorically rejected plugins, including those with their own DRM subsystems.

However, the W3C willfully underspecifying DRM in HTML5 is quite a different matter from browsers having to support several legacy plugins. Here is a narrow bridge on which to stand and fight — and perhaps fall, but (like Gandalf) live again and prevail in the longer run. If we lose this battle, there will be others where the world needs Mozilla.

By now it should be clear why we view DRM as bad for users, open source, and alternative browser vendors:

  • Users: DRM is technically a contradiction, which leads directly to legal restraints against fair use and other user interests (e.g., accessibility).
  • Open source: Projects such as mozilla.org cannot implement a robust and Hollywood-compliant CDM black box inside the EME API container using open source software.
  • Alternative browser vendors: CDMs are analogous to ActiveX components from the bad old days: different for each OS and possibly even available only to the OS’s default browser.

I continue to collaborate with others, including some in Hollywood, on watermarking, not DRM. More on that in a future post.

/be