Let the WebRTC Codec Wars Begin!

WebRTC standardization effort is heating up, and now politics and big money are entering the game: which codecs are going to be selected as the mandatory ones for WebRTC?

This was bound to happen. Whenever you try to reach a consensus of multiple companies, you end up dealing with politics and conflicting interests. In the case of WebRTC, that’s going to be selecting the voice and video codecs that are going to be mandated by the standard.

If you look at my first post about WebRTC, it has a table in it, where the codecs used by WebRTC are indicated:

At the time, it seemed as if Google are planning on releasing WebRTC with VP8 for video and G.711, iLBC and iSAC for voice.

How times have changed.

Last week, Joab Jackson reported on PCWorld that Google is backing VP8 for WebRTC:

Google engineers have volunteered the company's VP8 video codec for an emerging standards project, called WebRTC, that could provide a real time communications protocol for the Web.

He goes on and comments the stance of Google and Ericsson regarding the video codec – it is a good read.

This started by email threads on the IETF mailing list, where both Google and Ericsson provided such statements.

Google’s side: VP8 for video, Opus for voice (along with G.711. Why? Because they are all royalty free and provide high quality.

Ericsson’s side: H.264 for video (and maybe H.265 later on down the road), G.719 or AMR-NB. Maybe even AMR-WB and EVS. Why? Because this is how ITU thinking works.

And yesterday, we were informed that Microsoft is pushing a proposal of their own for WebRTC called CU-RTC-Web. As Janko Roettgers informs us on GigaOm:

Kaufman [Microsoft] likened the way the existing WebRTC proposal works to a black box within the browser: Issues like codecs and the way media is sent over the network are predetermined, with little that app developers can do to optimize for their unique challenges, he explained.

Google comes from the internet world. In it, royalty free is an asset, making VP8 a better option than H.264. The selection of Opus comes from the fact that it was developed and standardized by the IETF (where the internet lives) and is a “derivative work” of Skype’s SILK codec. It is considered a good codec.

Ericsson’s is coming from the mobile and the ITU standardization work. All codecs suggested by Ericsson come either from the ITU or mobile (3GPP), so it makes sense for them to support this angle. Ericsson also has patents in H.264, making it a benefactor of royalty payments from the use of this codec…

Microsoft? They're on Ericsson's side. They are looking for more options, power, flexibility. But by doing that, they are complicating the solution and probably running it to the ground. The end result isn't going to be something that can interoperate easily - trust me - I've been there.

It also shows the mindset of ITU thinking: we can have multiple choices, and then we will let the implementations decide during runtime. While this causes interoperability and implementation headaches, this is the way things work today.

There is also some sense in Ericsson’s suggestions: most/all of the codecs they have suggested have runtime implementations using a large range of hardware chipsets, which makes it easier to implement (and optimized, an important aspect for mobile devices).

If the IETF will settle on multiple codecs for voice and video as mandatory ones this is going to be bad for the industry: the simple solution should win – it will make it easier for companies to adopt and for disruption to appear. If we will end up with 4 or more voice codecs and 2 or more video codecs, then we are in for the same hurdles we have today with other VoIP standards.

The battle is just starting. I hope Google wins this one.