WebRTC, codecs and transcoding

WebRTC, codecs and transcoding

  • Comments 1
  • Likes

One of the most contentious topics in WebRTC has been the selection of a mandatory-to-implement (MTI) video codec. Codecs – be they audio or video – are negotiated during the setup of a call. The MTI is a codec that all browsers and WebRTC-supporting end-points would need to support as a last resort should they fail to negotiate anything else. In effect, the MTI codecs are the ones everyone has to implement to comply with the official Internet Engineering Task Force (IETF) specifications. The choice for the MTI audio codecs was easy: the newer Opus codec, which supports low-bandwidth, high-definition audio and G.711 as a fall back for easy interoperability with existing VoIP phones on the PSTN or in the enterprise. Both are open source and royalty-free.

Unfortunately, the decision around mandatory video codec support in WebRTC has not been so simple.

Ongoing arguments

There were always two main video codec options in the debate – the newer VP8 and the older H.264 codec, which is widely used in video streaming and video conferencing systems today. There were arguments on the technical merits of VP9 vs. H.264, but at the end of the day, they are comparable. The real debate comes down to patents and which alternative represents the quickest path to mass adoption for WebRTC.

Google developed VP8 and made it open and royalty-free, meaning anyone can use it, modify it and redistribute it at no cost. Google and many open source backers argue that VP8 should be the MTI because it is free, and free is the only way to get broad adoption across all segments of the industry. Free is especially important to what many see as challengers to the status quo; typically these are smaller companies that are not in a position to pay royalties or hire expensive patent lawyers. However, there are unresolved challenges to Google’s patents, so VP8 could prove to be not so free after all. In addition, since VP8 is a new technology, there is greater potential more patent challenges could surface. Furthermore, VP8 is only now being incorporated into mobile chipsets to optimize for performance and battery life. This means most existing devices will consume more power than other devices that have the ability to leverage underlying H.264 hardware acceleration.

H.264 is owned by the MPEG LA, an industry body that pools the patents of many license holders. It is not a royalty free codec; there is a cost depending on how and how much you use the codec. In practice, many H.264 WebRTC providers could have to pay royalties to the MPEG LA for it use. However, H.264 has been around for more than decade. It is widely used in everything from Blue-ray Discs and YouTube to enterprise video conferencing systems. Proponents argue H.264 represents the state of the Web today. They say that making VP8 the MTI would hurt WebRTC by forcing so many established players to incorporate something new rather than leveraging something that is already there. In addition, Microsoft and Apple, the two other major browser vendors, have also given public support for H.264. H.264 advocates use that to say its use would encourage these significant non-players to deploy WebRTC faster.

New efforts to no avail

The debate has gone back and forth for many months. In a sudden move last week, Cisco attempted to break the stalemate by announcing it would open source and make H.264 royalty-free by paying for the royalties itself. At the same time, Mozilla made its own announcement, saying it would incorporate this codec into Firefox. However, this comes with some caveats that many VP8 supporters do not like, particularly those looking to embed WebRTC into non-browser applications.

Google responded a few days later by announcing the new Nexus 5 would be added to the growing list of mobile devices that have hardware acceleration for VP8.

Unfortunately these new efforts did not make a difference. The IETF met last week in Vancouver, and like every attempt before, the group failed to reach consensus (which is required for IETF standardization). There is still no mandatory-to-implement WebRTC video codec.

What Does it All Mean?

Google Chrome does not support H.264. Mozilla Firefox supports VP8 today and will support Cisco’s OpenH264 sometime in early 2014. Developers embedding WebRTC into their applications without using Chrome or Firefox are free to use whatever they like. 

In practice, this makes WebRTC in its current state much more applicable to applications where the entity providing the service has control over the end-user device. This way they can ensure they would not have interoperability issues between end points. Examples of this include interactive digital kiosks, communicating to a remote contact center agent, machine-to-machine (M2M) applications like Google’s Chromecast, or video telephony embedded inside a native mobile app.

It also means transcoding will be required to communicate with the vast majority of existing video telephony infrastructure today, since only VP8 is supported. The situation will improve when Firefox supports Cisco’s OpenH264, but this limits WebRTC’s overall applicability since Firefox is just a subset of the market.

Independent of the video codec debate, there are many straightforward use cases for WebRTC video. Creative developers will find ways around these limitations, albeit maybe with a slight bit more difficulty. It could be that the industry ends the debate long before the standards-makers do.

What do you think?

Does the mandatory video codec debate matter to you? Do you have a codec preference? To represent your voice, we have set up a simple, five-question survey. All eligible* participants who answer the survey will be entered to win a $100(US) iTunes or Google Play gift card. Please click here to answer.

*LEGAL NOTICE: Void where prohibited; foreign officials (as defined in the U.S. FCPA of 1997) are not eligible to participate. Please visit http://www.dialogic.com/en/landing/WebRTCSurveyContest.aspx for additional terms and conditions, and further rules governing eligibility. The names of other companies and products mentioned herein are the trademarks of their respective owners. Entry deadline is November 15, 2013.

Views: 5435
Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment