Who are the Winners and Losers of the WebRTC Video Codec MTI Decision?

24/11/2014

We have a mandatory to implement codec in WebRTC! And it is… both.

WebRTC MTI video codec

The IETF got to an agreement on the MTI video codec for WebRTC. While I wouldn’t go to all the details and intricacies with the text suggested for the specification, suffice to say that for developers there is now choice between VP8 and H.264.

What interest me most is who wins and who loses in this long fight we had over the video codec in WebRTC. Here’s my list of winners and losers:

Microsoft

Microsoft got what it wanted. Time to prepare their Skype for the web. It also got H.264, which should make its life easier with the existing deployment it has out there for Lync and Skype devices that aren’t easily modifable or upgradable.

On the down side, it now needs to deal with VP8.

Google

Google definitely won this round. Although it now has to concede to adding H.264 to Chrome, it got approval of VP8 into an important specification. It tried getting VP8 through WebM into video streaming and failed, opting for supporting it through YouTube and Chrome. But now it has it on paper that it is mandated for WebRTC.

This also means another reason to force chipset vendors to add VP8 hardware acceleration to their future chipsets.

As Google is already hard at work on VP9, it really has little interest to continue focusing on H.264/VP8 stuff and run as fast as possible to the next playing field of video codecs.

Mozilla

Mozilla is part of the reason this came to be. Its Firefox browser already has support for both VP8 and H.264, the latter through its partnership with Cisco.

Browser Vendors

Other, smaller, browser vendors are the losers here. Apple, Microsoft and Google have already paid the patents of H.264. For them, adding this codec to a browser is just a matter of coding.

Mozilla went through the motions (and pains) related to integrating Cisco’s OpenH264 project, needing to download the codec library dynamically to meet the needs of the royalty buyout license. Doing that yet again per browser is a bit more of a challenge. For those smaller browser players out there, this is going to be a real pain.

Opera, who runs on top of Google’s own Chromium project might find it hard to integrate with an H.264 codec in a way that won’t force them to pay royalties.

In a way, it sits nicely with the fact that browsers today are hard to implement and maintain, with some real barriers of entry:

As CEO Alok Bhardwaj told The Verge, “I think their hope is that us and any other browser disappears.” But without some sort of relationship with Mountain View, it’s not clear how Epic and other projects like it can survive.

Browsers are now a game for large players only. Even if the baseline is built out of WebKit, Blink or Chromium – there are large enough barriers to get it from there to the market.

Cisco (and Enterprise video conferencing vendors)

Cisco got what it wanted. It now has H.264 inside the browser, which means it won’t need to transcode to fit all of its enterprise related video conferencing products and services.

MPEG-LA

Definite losers here.

The fact that VP8 got accepted means VP9 is a reasonable choice for the future video codec, putting into question the whole H.265 royalties game that the MPEG-LA is trying to jump-start.

Application Developers

As long as what you are doing is point to point, you’re good. Just pick out whatever codec you feel more comfortable with and be done with it.

Multipoint is a nasty complexity in this case. For some scenarios, it will be close to impossible to force everyone to the same video codec.

Server Side Media Processing

This one is hard to evaluate. For some, having an extra codec means an unnecessary headache. For others, the fact that transcoding may now be required means more sales.

All in all, server side media processing is now a bit more complex to deal with as it needs to take into account more video codecs.

The Next Fight

That said, the next fight is right around the corner. Browsers will have VP8 and H.264, but the new technology in VP9 is already getting into Chrome and will be with us early next year.

The real winners here are the royalty free codecs movement:

  • Images have been patent free for quite some time
  • Decent voice codecs have been royalty free as well – SILK, Speex and now Opus
  • VP8 just got “standardized” and “mandatorized” for use in an important specification, placing royalty free video codecs as a clear statement of our modern needs

Responses

Anatoli says:
November 24, 2014

I think you are taking too far the “mandatory to implement” mandate – in the large schema things, nothing changed. There are no real enforcement to get Microsoft to support VP8 or Google to support H.264. And the smoke cloud of Nokia VP8 patent issues didn’t go anywhere. Developers still have to prepare to deal with browser issues, and the only real winners ( or definitely not losers) are the companies which can support transcoding…

Reply
    Tsahi Levent-Levi says:
    November 24, 2014

    Anatoli,

    While a specification doesn’t ensure compliance to it, it is better than the other option. This is the first specification that has a non-H.26x codec in it as mandatory to implement. As such, it is a big win for VP8 (and by extension VP9). Having H.264 in there means it wasn’t a knock out but rather winning by points – which is usually the most you can ask for in a standardization war anyway.

    Reply
Philipp Hancke says:
November 24, 2014

Microsoft is not going to include VP8 just because the IETF writes down a MUST in some spec. Bernard Aboba is explaining why this is not a technical issue about 15 minutes into http://www.ietf.org/audio/ietf91/ietf91-coral3-20141113-1730-pm3.mp3 (in a way such that even I can understand it 🙂

Reply
Aswath Rao says:
November 24, 2014

So Opera does everything except H.264 to be compatible with WebRTC and forgo WebRTC label. They can interwork w all other browsers. So its user base has no impetus to change the browser on this count.

My suspicion is Mozilla went through the pain you identify for other reasons and other browsers do not have to follow their lead.

Reply
    Lennie says:
    November 24, 2014

    I don’t understand why you and Tsahi say Opera can’t support H.264.

    Every device or browser or application can now use H.264.

    Because can you just automatically download the Cisco binary from the OpenH264 site. You’ll need to include a URL and hash in your application so you can check what you downloaded was correct.

    That is what Ericsson did with GStreamer:
    http://www.openwebrtc.io/

    Reply
      Tsahi Levent-Levi says:
      November 25, 2014

      Opera is based out of Chromium. They are effectively bound to Google’s decisions. Replacing the video codec that Google ends up using with the OpenH264 one is going to be complicated to implement and a lot more complicated to maintain in the longer term.

      Reply
        Lennie says:
        November 25, 2014

        I doubt Chromium includes any H.264 support right now. My guess would be Chrome has it.

        So if Opera adds OpenH264 to Chromium they won’t have to deal with the other H.264 implementation. It’s the Chrome team that has to deal with the merge. 😉

        Also OpenH264 is an open source project. Opera can also add code to OpenH264 to make it easier to fit their needs.

        Linux distributions, for decoding at least, already include gstreamer-ffmpeg decoder.

        Google uses ffmpeg I believe.

        Yes, Opera will have some work to do. Hopefully they are not the only ones that want this.

        Reply
          Tsahi Levent-Levi says:
          November 25, 2014

          Lennie,

          I think I didn’t make myself clear here. Opera using any H.264 implementation exposes them to royalty payments. Using OpenH264 requires them to dynamically download that library in runtime, which won’t be easy to maintain in a piece of source code maintained by another third party (Google).

          Reply
          Lennie says:
          November 25, 2014

          I was also thinking: Opera already has a MPEG-LA deal for decoding:
          http://en.wikipedia.org/wiki/HTML5_video#Browser_support

          Reply
Stass Soldatov says:
November 24, 2014

That is really good news, because that means we will have IE with more-less standard WebRTC in some time.

Reply
    Tsahi Levent-Levi says:
    November 24, 2014

    Stass,

    That is correct. There are questions will Microsoft really adopt VP8, but I think this step is good enough for me now. We can all complain later if they decide not to deliver 🙂

    Reply
hu says:
November 25, 2014

it is a good news. there are lots of application using h264. so it is very neccessay to support it. if you don’t. lots of developers have to do it by themselves. besides . some of my client want to me do it.

Reply
» The best real-time blog posts of 2014 AgilityFeat says:
December 28, 2014

[…] in IE and Safari, there is finally consensus on video codecs! Vendors, browser companies and developers alike celebrated this resolution, even if it’s not perfect. WebRTC even made the print edition of […]

Reply
RealTimeWeekly | RealTimeWeekly #60 – Best Posts of 2014 says:
January 2, 2015

[…] in IE and Safari, there is finally consensus on video codecs! Vendors, browser companies and developers alike celebrated this resolution, even if it’s not perfect. WebRTC even made the print edition of […]

Reply
Avoiding Contact Center IVR Hell with WebRTC - webrtcHacks says:
May 16, 2015

[…] the Great Video Codec Compromise now promises H.264 support in browsers, mobile SDKs have been able to take advantage of those […]

Reply

Comment