Cisco Blogs

Open-Sourced H.264 Removes Barriers to WebRTC

- October 30, 2013 - 79 Comments

When it comes to making collaboration technology such as high-definition video open and broadly available, it’s clear that the web browser plays an important role. The question is, how do you enable real-time video natively on the Web? It’s a question that folks are anxious to have answered.

WebRTC–a set of enhancements to HTML5–will address the issue head on. But, there is an important hurdle that must first be cleared, and that’s standardizing on a common video codec for real-time communications on the web – something the Internet Engineering Task Force (IETF) will decide next week.

The industry has been divided on the choice of a common video codec for some time, namely because the industry standard–H.264–requires royalty payments to MPEG LA. Today, I am pleased to announce Cisco is making a bold move to take concerns about these payments off the table.

We plan to open-source our H.264 codec, and to provide it as a binary module that can be downloaded for free from the Internet. Cisco will not pass on our MPEG LA licensing costs for this module, and based on the current licensing environment, this will effectively make H.264 free for use in WebRTC.

I’m also pleased that Mozilla has announced it will enable Firefox to utilize this module, bringing real-time H.264 support to their browser.

“It hasn’t been easy, but Mozilla has helped to lead the industry toward interoperable video on the Web,” said Brendan Eich, Mozilla Chief Technology Officer. “Cisco’s announcement helps us support H.264 in Firefox on most operating systems, and in downstream and other open source distributions using the Cisco H.264 binary module. We are excited to work with Cisco on advancing the state of interoperable Web video.”

Why is Cisco Doing This?

Many, including Cisco, have been backing H.264, the industry standard which today powers much of the video on the Internet. We strongly believe that interoperability is an essential goal of standards activities and that usage of H.264 by WebRTC means it will be able to interconnect, without transcoding, to a large set of existing clients from a multitude of vendors.

Regarding H.264, Jan Färjh, Vice President, Head of Standardization and Industry at Ericsson, states: “Support in WebRTC for H.264 enables interoperability with most video-capable mobile devices, which is great for industry acceptance.”

Finally, if you’ve read my blog or attended our recent annual Collaboration Summit, you will have heard our mission for Cisco Collaboration: Create rich collaboration technologies that are incredibly easy to use and make that technology broadly available to everyone in the world – from the largest companies to the smallest businesses. That’s what we would like to see happen with WebRTC, powered by an industry standard that is already prevalent in the market place.

We hope and believe that this step of open-sourcing our H.264 codec will enable the industry to move forward on WebRTC and have the best of all worlds: interoperability with the large installed base of H.264 endpoints, combined with an open‐source and effectively free codebase. This action also underscores our commitment to simplicity, for the greater benefit of developers, users, and vendors alike.

I’d love to start a dialogue on this which is why I’m inviting you to attend a TweetChat I’m hosting (@rowantrollope) later today, Wednesday, October 30 at 9:30 a.m. PDT. The hashtag is #collabchat.  Cisco Fellow Cullen Jennings (@cfluffy), Cisco Collaboration CTO Jonathan Rosenberg (@jdrosen2) and Snorre Kjesbu (@KjesbuSnorre), Vice-President of Cisco’s Collaboration Endpoint Technology Group, will join me in the conversation. I also welcome your comments on this blog.


In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. Firefox already has VP9 support VP9 destroys H.264 in quality and significantly bandwidth usage, there's no reason to user proprietary codecs in WebRTC at all.

  2. Thanks for the info! could you tell me the details for installing openH264 binary? does every user need to download the openH264 binary from Cisco (website) and install it into their own browsers? or Mozilla will download it (one time) and integrate it into the new version of Firefox so all users could directly use openH264 without downloading the openh264 binary again? Thanks!

  3. Can you please tell when build for android will be available?

  4. Thanks for this christmas present! :) +1 for CISCO!

  5. Any news or was the decision revoked? more than a month has passed, x265 is already on a good stage and yet there's no trace of any openh264 code, are you using the "open" term just to sponsorize your brand, or what? anyway, I doubt your version will be any better than x264, which is a *real* open source library, I'm just curious.

  6. is this the official github repository?

  7. I am very happy if that dream could come true, I hope I can be a part of this technology is welcome.

  8. is it already possible to download it?

    • Can you give me the link ?

  9. Hi, when do you release the source code of openh264 ? Do you optimized for neon the openh264 decoder ?

  10. So essentially the only thing "useful" is a binary, not the source code, if we wish to avoid the MPEGLA patent troll. This is worse than useless - this cannot be included in a free software distribution and means neither can Firefox - as it will download and install non-free software. See: As an aside, this is a waste of time - VP8 is equal-to-if-not-greater-than this crap format, and VP9 is definitely greater.

  11. WebRTC is inevitably going to fragment along two dimensions: - Use-cases that need interoperability with "other stuff" (eg videconferencing, UC systems, telco SS7/IMS etc) - Use-cases that are perfectly fine as standalone islands (eg a karaoke app, or a customised video-chat service) That is one dimension. At present, it is hard to determine whether the future balance of importance & value is 20/80, 50/50 or 80/20 around interoperability. Clearly, Cisco would like to tip the balance of WebRTC towards the interop-rich use-cases. The other dimension is whether WebRTC use-cases are based in the browser or not. My view is that on the desktop, WebRTC will be predominantly browser-based. On smartphones, tablets and other devices, WebRTC will primarily be embedded into native apps, or the underlying device OS. That is *especially* true on iOS, unless Apple suddenly changes its mind on WebRTC support in mobile Safari. That means that WebRTC on mobile (especially iOS) probably cannot easily exploit Cisco's H.264 offer. There needs to be a way for either standalone app developers to get access to iOS' existing H264, or "BYOcodec" with the app. That might involve the developer's own integration, or it might use a 3rd-party cloud comms provider. It's not obvious that H.264 is a good solution for either of those. Overall - this is good for desktop WebRTC & interop use-cases, but mostly irrelevant for mobile WebRTC or standalone use-cases.

  12. The main problem with WebRTC is fragmentation. Google pushes VP9, Mozilla wants to go H.264. Microsoft probably hopes it all goes away so they can keep doing their proprietary things. And none knows what Apple thinks. "Everyone" in the video conferencing industry, except Cisco, have moved from the old H.264 AVC to scalable video codecs. There are reasons for that. Google's initiatives with VP9 pushes the web world in the right direction. Cisco's generous offer to pick up the tab from MPEG LA for all of us will only slow down the inevitable.

    • Thor hammer: You have your facts wrong. We are rolling SVC out across our entire portfolio.

    • Thor Hammer, you sound like a Vidyo / Polycom guy. I think it's a bit bold to say everyone is moving to SVC. Frankly most of the guys that have moved have done it for marketing reasons rather then technical. -Nathan

  13. Congratulations Cisco for a smart and bold move. Let's hope H.264 becomes the standard codec of WebRTC. Will the Cisco binary plugin have hooks to use hardware acceleration where it's avilable? P.S. I believe as of today 50% of all the bits on the internet are in H.264 bit steams!

  14. VP8 ist the way to go. Nice strategy, to make it open source, so that others can contribuite, and to do your work, but in the end, if you use it yourself (build yourself), you have to pay to the MPEGLA. You want to push WebRTC ? Then contribute to VP8 and VP9 !!

    • Good move from CISCO. Google is also paying to MPEG LA for VP8/9, not a very big difference here.

      • This page says, that google won against mpeg la ,

  15. In appreciating all comments this is quite simply a positive move for all. Each company has a unique way of collaborating. Every consumer too. Any step forward that recognises that with an intent to bring people and business together in a meaningful way is to be applauded. The cloud collaboration curve is very much upon us and it is here where real innovation will happen, in apps that work for you, that relate to your existence and needs as a business and consumer user; and not against you. Solid move Cisco.

  16. This is a great move, Cisco. Let me just ask for ONE thing: Please make the binary you distribute reconstructible by independent parties. Thus, as a user I should be able to check the downloaded binary against a known good checksum, and that checksum should be created by an independent party. That means that there is no possibility to plant a backdoor into this module, and Cisco is relieved from any possible suspicion. Going beyond what is expected of you will reflect well on the company as a whole.

    • Absolutely - this is the plan. We will be open sourcing all build scripts so that you can verify the checksum on the binary yourself, and then verify it matches the checksum in the version distributed by Cisco. - Nadee, Cisco PR

  17. Hi Cisco, A big thank you from a happy open source user from the Netherlands. Best regards, Martin

  18. As a web developer, I certainly appreciate this move on Cisco's part. However, in my opinion, it doesn't really solve concerns that large part of web community have voiced about inclusion of H.264 in web standards. Cisco is willing to pay patent licensing costs, that's great - but what will happen once Cisco refuses to pay anymore, or simply goes bankrupt? That's a possibility too. At this point we (the web) stay with the same problem we have now, only worse, because H.264 would become more popular due to being part of web standards. So despite this move - which is, may I repeat, very appreciated - I would still refrain from using H.264 in my web projects, if that will be possible.

  19. Is there any timelines when this will be available in FireFox?

    • Gonzalo - not yet, but stay tuned! - Nadee Gunasena, Cisco PR

  20. I'm still confused. Nadee has stated that "the source code will be open source and distributed with a BSD lIcense." but it's the binary that will come royalty-free. So, if I download the source code and build it myself in my computer (the BSD allows it), I myself have to pay the cap? Or I pay it if I distribute it (the BSD allows it too, whether if it's free of charge or not)

    • This seems to be the case: ethical Linux distributions will be unable to compile and distribute it. This "bold move" is not taking my concerns about H.264 "off the table" - rather, I'm more concerned than ever that this could cause H.264 to be seen as an acceptable alternative to VP8, particularly with regards to the upcoming IETF decision. I want to assume the best intentions from Cisco, so hopefully I am misunderstanding something, but this seems like a clever way to attack unencumbered video. But I guess Cisco - and actually, any company that hosts Internet video or carries Internet traffic - has significant financial incentive to promote the more efficient codec at the cost of freedom. If Cisco had convinced MPEG to drop the licensing scheme entirely, I would be much more excited. I thought more open source code was always better than less, but this has me wondering.

      • The desire for more open source does not change the fact that there are millions of devices and applications that use H.264 today. Right now every customer / user I have spoken to wants and expects webRTC to have the ability to communicate with existing VC/TP devices. That is only going to be possible by adopting H.264, happily in addition to any other codec that maybe opensource.

      • Michael, thank you for the comment. Cisco has the same concern many other players do – we want interoperable video. Like it or not, the reality of the Internet today is that the vast majority of existing video communications products, from hardware systems to softclients to mobile apps – are based on H.264. Cisco’s concern is that a webRTC standard that has a codec that doesn’t interoperate with the majority of deployed communications infrastructure creates an island. This means many communications application providers will not be able to utilize the technology. We’re firm believers in the mantra, “We need to build for the Internet as it is, not the Internet as we wish it to be”. That is sound engineering practice. Patents and royalties are a reality of the deployed and operational network that we are trying to support with webRTC. We believe our contribution to the community allows us to find a good balance – something that solves the royalty problem in the most significant use cases so that the patent encumbrance has no practical impact for many, and actually interoperates with video stuff out there today. Mozilla’s response I think gives a clear indication that pragmatics are important. A webRTC filled with patent-free tech that interoperates with no one, and thus unusable for most, is not the outcome that is good for the Internet. WebRTC needs to be usable by application developers and the most important thing there is to interoperate with the network of video stuff that is out there today. - From Jonathan Rosenberg, Cisco Collaboration CTO

        • Thanks for the reply. I appreciate that Cisco is in a tough position and is unable to achieve wide adoption of VP8 on its own. I'm nevertheless extremely disappointed that Cisco will be supporting the standardization of encumbered web video. From the perspective of a Linux user, requiring codecs that distributions won't be able to include for another decade is hardly "interoperability." (I wonder which distributions will disable that Firefox module.)

    • If you distribute it, you are subject to the MPEG-LA license rules, and Cisco has nothing to do with it. The MPEG-LA licensing rules allow you to distribute 100k copies royalty free, and after that there is a per-unit charge. Alternatively, you may elect to pay them the cap of $6.5M if you believe your distribution is that large. The cap is really meant for BIG distributions. Hope that clarifies.

  21. Brion Vibber AAC is not a huge problem. AAC is not licensed for usage. Work around just implement AAC in javascript. Now if aac.js and H.264 from cisco will play ball than H.264 aac will not be a problem. A javascript .js not being run is not a built codec. So its not manfactured. End user is the one that turns to runable. They are not a developer or a manfacture of the codec and they have not paid for the codec either. Limitation that aac.js decode only. But to play all existing content decode only is enough. H264 was in fact the major road block it is a little hard to implement in javascript and have it perform. So thank you very much Cisco. This should make it simpler to provide just 1 video.

  22. You lose... At last the H264 supporters have admitted that they can't compete with Free Open Source software in the long run This is the end of the line for MPEGLA.codecs. No one will *ever* pay for video codecs again. You might as well just go to VP9 now.

  23. When you say "binary module" what formats will there be? Linux shared object? Windows DLL? Presumably it will be (at least initially) for x86, so what x86 instruction set is required? Both 32 and 64 bit?

    • This is still being defined. We’ll initially do this for x86 an ARM (Android), clearly 32 and 64 bit support is needed for x86. - Nadee, Cisco PR

  24. I understand we need the binaries for licensing purposes, but will the compilation procedure be replicable so third parties can verify the source code IS actually the source code?

    • Yes. We plan to open source the build scripts as well, so that third parties can replicate it and do their own verification on signatures at the time of installation of the module. This will allow them to be certain that the binary modules is exactly the compiled version of the source code in the repository. - Nadee Gunasena, Cisco PR

  25. Fantastic!

  26. Is the OpenH264 implementation software-based? Is there any support for OpenMAX on ARM?

    • Hi Dany - It is software based. The specific APIs that will expose the functionality are being worked on right now, so we don’t know yet whether the API itself would be openmax or whether openmax could be a wrapper on top of a lower level API. - Nadee Gunasena, Cisco PR

  27. Will this binary be distributed only as a browser plugin, or will the binary be usable in other server-side applications? If hobbyists commit additional code to accelerate the decoding on specific platforms and chipsets (such as linux on the Raspberry Pi), would Cisco be willing to build the binaries and provide them? I know there's not much web benefit there, but there's a lot of hobbyists who would appreciate a legal free codec for their systems, but for performance reasons they can't really do the decoding on the CPU.

    • Hi Matt, the binary will be available for things besides browsers – our aim is to support any end user application. We are looking to the community to help make it available on increasing numbers of platforms by helping with porting and authoring of scripts. Cisco will be happy to make this available on as many platforms which can be supported under the constraints of the MPEG-LA license terms. Note further that in general the MPEG-LA licensing terms allow for free usage when the number of instances is below a threshold, so for hobbyists it has always been the case that they can just use existing code. As such, we encourage hobbyists to also use the source directly for projects when their distribution volumes are low. - Nadee Gunasena, Cisco PR

  28. AAC audio support seems to be missing; without audio, playback of existing H.264+AAC media, or encoding of new H.264+AAC media for playback in other browsers outside of WebRTC won't be possible. Are there plans for AAC support?

    • No, this is strictly for H.264 video. The standards bodies have aligned on Opus and G.711 as the common audio codecs for webRTC, and the latter is widely interoperable with almost the entire install base of VoIP infrastructure. Furthermore, we expect browser vendors to, over time, support additional optional codecs to improve upon G.711. In any case we are not open sourcing or providing any distributions on audio technology at this time. - Nadee Gunasena, Cisco PR

  29. I'm curious as to how Cisco is going to account for the codec use, for patent licensing purposes. Is this tied to the download of the binary codec in Firefox? What about other products that might want to take advantage of this?

    • Robert, We will pay MPEGLA the cap. Rowan

      • Hmm, surprising that MPEG LA looks at it that way. I would have thought that they would treat each company using it as unique to the cap, great tho that you have that worked out! -Nathan

  30. Huge!

  31. Hi Rowan, great (bold!) move. This is the way to go! So far WebRTC has been on the "edge" for many people: interesting and appealing, but not ready yet for prime time (technical limitations, legal limitations, small players on the market, fragmented investments...). With this announcement everyone will be watching Cisco looking for someone able to define this brand new market. I'm sure You got the attention of these people. It's a big responsibility. Now, you can't disappoint them. Thrilled to see (and to be part) of what's next. Francesco

  32. I am a bit lost on how not passing MPEG LA costs actually removes the requirement to pay MPEG LA. I can buy x264 for commercial use (free if not commercial), frankly the best H.264 implementation out there and still need to pay MPEG LA if x264 does not pass it. Is Cisco saying they will pay MPEG LA for you if you use their implementation? P.S. How does cisco compare with DivX, Elecard, Intel, MainConcept, DiscretePhoto, and x264?

    • Nathan - We will select licensing terms that allow for this code to be used in commercial products as well as open source projects. In order for Cisco to be responsible for the MPEG LA licensing royalties for the module, Cisco must provide the packaging and distribution of this code in a binary module format (think of it like a plug-in, but not using the same APIs as existing plugins), in addition to several other constraints. This gives the community the best of all worlds - a team can choose to use the source code, in which case the team is responsible for paying all applicable license fees, or the team can use the binary module distributed by Cisco, in which case Cisco will cover the MPEG LA licensing fees. Hope that answers the first part of your question - Nadee, Cisco PR

      • So as long as a Cisco-distributed binary is used in a commercial deployment, Cisco will cover the MPEG-LA licensing? I'm thinking of a scenario where a software codec is used in a production video headend. As I understand it, other open source codecs like X264 still require an MPEG-LA commercial license. I am wondering how this would compare licensing (and of course quality) wise. Thank you Cisco team, looks like a busy day for you --Kevin

  33. Could you please clarify whether it's just the binary module that comes with a free licence, or is that also supplied for the code version too? And if the code does come with a free licence, does this get passed on when the code is re-distributed and/or re-used in any other open source applications? Are there any limitations on use in this way? Thanks.

    • Hi Glyn - The source code will be open source and distributed with a BSD lIcense. The binary module is separate and when the users software downloads it from Cisco, that is when we are responsible for paying the MPEG LA royalties. - Nadee Gunasena, Cisco PR

  34. So, just for clearity, are you 'open sourcing' the binaries, or are you open sourceing the actual source code? Because, you know, binaries can't be trusted nowadays (don't need to mention large companies, NSA and mass spying do I?)

    • R, We are open-sourcing Cisco's H.264 codec. That code will then be made available on an ongoing basis as a binary downloadable. We will pay the royalties to MPEGLA for it. This effectively makes it free for any browser (or other app) to include it. Rowan

  35. H.264 is inferior codec and outdated, designed in the 2000s. VP9 is faster, superior and blows H.264 out of the water in compression and was designed in the 2010s and doesn't have the MPEG-LA cloud hanging over everyone.

    • Hello Google boy, you should compare VP9 with HEVC/H265 to be fair...

    • Well its not fair to compare H.264 to VP9. We are talking about offering a option against VP8 that is already part of WebRTC. Since WebRTC gets it's VP8 via libvpx and that has beta VP9 support I hope we will soon have options, but since we are not close to real time on most hardware I don't think it matters much yet. -Nathan

    • And how many devices today use VP9? It does not make sense to create yet another island with browsers just using VP9; by all means support VP9 but include H.264 since Cisco has now removed the biggest hurdle for implementers and this will open interoperability with millions of existing devices from several vendors.

  36. Great move ! It reminds me of what we did at Fluendo with the MP3 codec for GStreamer. Kudos to you guys, I can't wait to try the decoder implementation on ARM with GStreamer SDK.

  37. Hi Rowan, this looks like great news, but I don't understand how it exactly works. As far as I understand patents cover algorithms powering H.264/AVC and not their implementation, so even if you're releasing for free your implementation some of the technology contained therein will be probably protected by patents from other companies. This is the reason why MPEG is currently trying to standardize a video coding format for browsers that entirely relies on patent free technology. regards, Claudio

    • If Cisco has an implementation, and they open source it, your concern would be valid except for their statement "will not pass on licensing costs."

      • Which means that they will pay all licensing costs of IP claims from other companies (the MPEG LA pool basically)?

    • Hi Claudio - We do support development of royalty free codecs and are happy to see ongoing work this direction at MPEG. - Nadee Gunasena, Cisco PR

    • That's right Claudio - 264 is protected by patents, which are managed through MPEGLA. We will be paying the royalties for all downloads of the binary distribution of this open source component, which makes it free for any browser to include in their implementation.

  38. A bit too late. Now there is H.265, the sucessor to H.264. So brand-new WebRTC is built using legacy technology.

    • Instead of H.265 we should be getting behind Daala.

      • We do actually contribute to the Daala research and help write the code. Today it is not yet ready for use. It is targeted to be a generation after H.264. Once it is further along, we can evaluate it relative to other codecs. - Nadee Gunasena, Cisco PR

      • The point of h.264 support is that _existing_ content and applications can interconnect without having to be pre-transcoded. That opens up millions of hours of video.

    • H.264 is not legacy by any means, as much as H.265 is not "there" yet. Most video content on the web is encoded using the H.264 standard and most end-point devices support encoding/decoding H.264 streams. None of these hold true to H.265 and VP9. These are next-gen, in the sense that they are available, but not yet useable.

  39. Does the "binary" will be available for MIPS64 and PowerPC architectures?

    • Hi Albert - thanks for your question! If the community can provide the ports of openh264, we are very open to including binary builds for any of them. Nadee Gunasena Cisco PR

    • Initially just X86 and ARM. But with an open source codebase we look to the community to help us create binaries for other platforms on which Cisco can distribute to the user's computer or device.

  40. Hello! Always looking for ways to advance the experience of learners and their teachers. Would like guidance to learn the value of real time video as education strategy. I applaud your efforts to open a pathway to its access. Best, Dr. Barbara

    • There are lots of ways. The @mozillaignite community has been exploring some of this in the context of Gigabit access Also check out The project we have been working on is called Cheers

    • I've talking to start ups in the education space. JabberC and WebRTC generate a lot of excitement. You'll see a lot of cloud based educational applications integrate instant messaging, audio, and video in their web page (soon without the need of a plugin, natively in HTML5). Cisco is the only company able to provide this service. School boards are excite as well. They can broadcast message to students and staffs, anytime anywhere on any device. They don't have to care about the end-point (videoconference, web browser, Jabber app on Windows, iPad, Android...)! They can integrate these functionality right into their own applications. Also related, location-awareness is making attendance a breeze. By making the network smarter, Cisco enables a seemless experience for its customers. When the technology does not get in the way, great collaboration happens. All we need for learning!