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?

[If you are new around here, then you should know I've been writing about WebRTC lately. You can skim through the WebRTC post series or just read what WebRTC is all about.]

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.

-

UPDATE: Here is a presentation I gave about WebRTC codecs at the WebRTC Conference in Paris.

Tags: , , , , , , , , , , , , , , ,

Liked this post?

Share it!

Never miss a post!

Or just grab the RSS feed!

Comments

  1. Randell Jesup says:

    The IETF rtcweb working group selected Opus + G.711 as mandatory-to-implement audio codecs, by a quite strong consensus (and the only alternative that got support was just Opus). Why G.711? To quote from the meeting “Oh my goodness, why wouldn’t you?”

    The video codec issue will be brought up again at the next IETF meeting, there was no attempt to resolve it at this one.

    Mozilla (not surprisingly) supports Opus+G.711 and VP8.

    • Tsahi Levent-Levi says:

      Randell,

      Thanks for the update!
      I am sure there are those who wish to see other voice codecs as the ones selected instead of Opus – I even have an idea of a few such vendors :-)
      It is exciting to see this move forward and I do hope you nail down the video codec soon – be it VP8 or H.264 – just not both, and not fight over it for too much time.

  2. There are standards and defacto standards. Google and others will just release WebRTC (I think they already have) with VP8 and will take off while the standards bodies are busy researching the solution.

    • Tsahi Levent-Levi says:

      Dave,
      While this might be true, Google is lacking two important browsers: IE and Safari. Without them, there’s just so much the can achieve.
      Hopefully, we will end up with an alignment of a single video codec instead of multiple options.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">