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

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

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