Trick or Treat? Cisco’s OpenH264.org & What it Means in the WebRTC Video Battle

We had a lot of traffic to Victor’s post on the WebRTC mandatory video codec earlier this week. Given the news from Cisco yesterday we figured this warranted a quick follow-up post beyond what we could add to the comments area.

Quick debate recap

Engineers don’t like lawyers, and as Victor mentioned in his post earlier this week, much of the debate over assigning a mandatory video codec for WebRTC has been about avoiding the lawyers. While debate over the technical merits of H.264 vs. VP8 yielded no overwhelming winner (they are both great codecs), the debate has more recently revealed it’s true form as a mostly IPR related issue.  The H.264 camp speculated that there could be legal issues with VP8 despite Google’s claims otherwise. There are certainly inherent issues with H.264.  Which one has more risk?  It would take lots of lawyers to sort through this and no one pays for lawyers to go to standards meetings. Even if they did,  it wouldn’t matter – lawyers use arbitrators and the legal system, not technical standards procedures to work through disagreements.

Unfortunately the attempts to avoid the lawyers have failed.  One of the most significant barriers preventing use of H.264’s use as a Mandatory To Implement (MTI) codec for WebRTC, as stated by many vocal H.264 opponents (see passionate comments on webrtchacks), has been the patents and licensing fees associated with it.

The news

Cisco announced this morning that they intend to remove this barrier by contributing open source H.264 implementations and absorbing the MPEG-LA licensing fees.  In concert with this announcement, Mozilla has acknowledged the contribution, and announced they will be delivering H.264 to Firefox in the near future.

How does this change things?

What Cisco is attempting to do is bear the brunt of the legal battle by assuming responsibility for H.264 royalties under specific circumstances. At a high-level, this is not much different than what Google attempted with VP8. The main difference is there are 8 other major backers of H.264 and hundreds of millions of devices (maybe Billions) that already support H.264.

Materially, the possible outcomes in the debate remain the same.  However, Mozilla now appears to be in the column in support of the H.264 proposal (or possibly H.264 & VP8), and the legal implications and licensing obligations of WebRTC’s use of H.264 are more aligned with the principles of the open web.

Who cares about H.264?

While theories, accusations, and speculation abound, the facts are that many of the H.264 proponents are those that have invested money, and mounds of high quality engineering in IP based real-time communications outside of the web for many years now.  The result of that investment is that most IP based video systems and services use H.264 today, and this is not easily changed.  When you consider that most mobile devices contain dedicated hardware support for accelerating the encode/decode operations for H.264, it represents a massive deployment that can’t simply be updated at the flip of a switch.

While some argue that existing video-over-IP implementations are, or should be separate from the web, many would like to be able to interoperate between web and non-web applications at a reasonable cost.  Most agree that the notion of transcoding between H.264 and VP8 for sessions that cross this divide would be a very cost prohibitive proposition at scale. Those who build outside the web but want to interoperate with WebRTC are faced with either implementing the tools and technologies of WebRTC in their non-web applications, or making use of gateway functionality within elements they have already deployed .

If VP8 became the one and only MTI video codec for WebRTC, the implications are huge for those web outsiders that want to allow their consumers the ability to have real-time-communications to/from the web.  In the end, the price of floating the cost for a “free” Web Real Time Communications, may be significantly less than overhauling all the established video RTC work that has been done to date.

How will this work?

Cisco is going to provide a codec binary module and open source everything.  Mozilla is going to bake this into Firefox. Other developers can incorporate the binary module into their code just as Mozilla is doing and Cisco will pay the charge. Alternatively they can utilize the source code to build their own binary, but Cisco is not covering the royalty charges for this. The binary has to come from Cisco for them to cover the licensing charges.  Implementors (browser makers) will need to connect to Cisco.com and trust their compilation of the open source project.  Ideally, this will be transparent to web developers, and nothing will change in how they use the W3C WebRTC APIs.  The promise would be that web apps running on browsers containing Cisco’s openH264 implementation will have any associated licensing fees covered by Cisco, no strings attached.

The Good, the Bad, and the Ugly

The Good news for the WebRTC community is that Cisco just lowered one of the major barriers to adoption of H.264. This is going to cost Cisco real money based on statements they have made – money that others might have had to pay. This move also increases H.264. Cisco should be commended for taking bold action to try something new for the benefit of WebRTC, even if there are many that disagree on the debate.

The bad news is that everyone really wants a free and unencumbered codec as opposed to a generous hand-out that could easily be rescinded by a public company that is still subject to the whims of its shareholders. This mechanism also definitely will not work with Apple iOS according to the Cisco openh264.org Q&A…but then again, Apple already licenses H.264 on it’s devices.  The downloaded binary module approach may be problematic for other platforms too. It is unclear how this will leverage underlying hardware acceleration, if at all. It is also not available today. I think it is safe to assume Cisco will put the necessary resources behind this to get a quality module to market quickly, but there is risk there.

The ugliest part is that this does not end the debate.  It does not bring the community together.  Based on the IETF mailing list discussion today, opponents to H.264 are not phased by the move, claiming it does not go far enough.  Certainly it does not remove the lawyers from the equation. It leaves open new issues – some have already cited security concerns about relying on an unauditable binary (i.e. what if the NSA inserted something between in the compilation process?). It also does nothing to establish precedent for future codec battles – namely VP9 vs. H.265. We will have to wait until next week to see what this really means.

The MTI codec outcome that may be strengthened the most by a move where VP8 and H.264 are both chosen as mandatory.  H.264 proponents will have done just enough to alleviate IPR concerns, while achieving interoperablity.  VP8 proponents will still have leverage over any patent trolls wanting to stir up trouble through future use of H.26x.  In the future, any side that proves to be an un-trustworthy citizen of the open web can be “voted off the island”, so to speak.

Summary

As is typical with debates that are so polarizing, it can be challenging to remain objective and pragmatic when it revolves around matters which are qualitative instead of quantitative.  It is ironic that perhaps this battle is less about what happens in the immediate future on the web, and more about jockeying for future position, and RTC that is outside the web.  What happens within WebRTC will undoubtedly shape the future of RTC in the existing telephony domain. Surely larger forces are in play here.

 Many questions are going to remain open:

• Are the large H.264 proponents unfairly protecting their interests and keeping a stranglehold on RTC outside the web going forward?

• Is Google attempting to undermine and weaken other tech giants under the guise of open and “free” technology by sealing off interoperability to those that are already significantly invested?

• What if Cisco’s generosity runs dry, providing MPEG-LA some way to corner future licensing fee gotchas H.264?

• What if Google’s generosity runs dry, and they start charging for VP8 (9)?

• What about H.265 vs VP9?

• Who do I trust for an unknown future?

We’ll try to leave you to answer those for yourselves.  If you already have your mind made up about the integrity and motivation of the major players involved in this debate, this move may do little to dissuade.  At a minimum however, this news serves as a potential major contribution to WebRTC from Cisco and those supporting H.264.  As the MTI debate plays out, certainly this makes H.264 a much more attractive option for inclusion as a WebRTC component.  Simply focusing on the here-and-now, this aims to mitigate concerns about down-the-road licensing fees against implementors of WebRTC, while ensuring interoperability outside the web.

 

{“authors”: [“chad“, “reid“]}