Here we go again. The Internet Engineering Task Force (IETF) is scheduled to discuss WebRTC Mandatory to Implement (MTI) codecs again this week at IETF 91. We have been here a few times before – the community failed to reach a consensus on this issue last year. Will this time be any different? What does this all mean for the industry and transcoding vendors like Dialogic?

Where we were a year ago

 Let’s recap where we were on this debate a year ago:

  • Google, the mother of WebRTC, includes VP8 in with the open source reference at webrtc.org
  • Incumbent telephony/video vendors prefer H.264 because it is already well established
  • Open source developers and standards policy makers like VP8 because it is royalty free and open source
  • Cisco tried to quell these concerns by offering to pay for H.264 royalties via its OpenH264 implementation so long as you use their binary
  • Firefox comes out and announces it will use OpenH264 to support H.264
  • Nokia claims VP8 is infringing on its patents and says it will not allow it to be used in WebRTC royalty free
  • Google says any patent claims are baseless
  • Mobile developers complain VP8 does not have hardware support on most devices, meaning WebRTC eats up a ton of battery
  • Google starts building a list of devices with VP8 hardware
  • A vote is taken, but no consensus is reached – no MTI video codec is chosen

 For more details see my post from last year on this.

It was obvious that that consensus would not be reached in the March 2014 IETF meeting, so this topic was tabled until now. It was hoped movement in the market would help push consensus in one direction.

So what has changed in a year?

 Here we are, a year later. Has anything changed?

 It turns out a lot - here is the run-down of where we are since last year:

  • Google still doesn’t support H.264 for WebRTC in Chrome
  • The MPEG-LA (H.264’s patent pool owner) announces an agreement to grant Google licenses for VP8
  • The above pool appears to exclude Nokia, who is still suing over VP8 patent rights and will not license it under reasonable and nondiscriminatory terms
  • Google puts VP9 – VP8’s eventual successor – on its WebRTC roadmap by the end of 2014 (this has yet to be implemented)
  • There is no counter response from the H.264 camp with H.265 plans
  • Cisco builds out OpenH264 for the Constrained Baseline Profile – this is a subset of everything H.264 has to offer but is probably good enough for most WebRTC apps
  • Microsoft announces it is actively developing WebRTC (actually the ORTC version of WebRTC, but that is a different topic) with H.264, not VP8
  • Mozilla launches FireFox with OpenH264 – without hardware acceleration, because it can’t due to royalty schemes
  • The VP8 hardware-supported device list grows, but not by enough to give it a significant share vs. H.264 support

So what does it all mean? Who is going to win?

I have no idea. This is a good one for the sportsbook in Las Vegas. Both sides have made progress. I give a slight edge to H.264 with Microsoft working on WebRTC in Internet Explorer and Nokia’s patent trolls still lurking, but a slight edge doesn’t cut it when you need consensus. My guess is that there will continue to be no MTI, but we’ll have to listen to the debate. There is room for creative solutions, like only forcing browser vendors to do both but not mobile app developers.

Would a MTI mean the end to Transcoding?

Unfortunately, that is wishful thinking.

No one has ever liked to transcode. Transcoding is inefficient. It adds cost. Transcoding is a failure on vendors and standards to come up with a better way.

However, despite all of this, transcoding has been a fact of life in the PSTN and VoIP worlds for decades. Try as you might, you will always find older device in the network that does not support the codec you want. There will always be a new codec that you want to support, but that is not supported everywhere. That’s just how networks always end up – new technologies – including codecs - are always introduced faster than the old ones are removed. Implementations become fragmented and then someone figures out a way to bridge them. Do your best to limit transcoding, but in most cases you will not be able to avoid it forever.

WebRTC certainly shouldn’t aspire to start out this way, but sadly this history is likely to repeat itself in WebRTC eventually.

Aren’t you just saying that because you are a transcoding vendor?

Like many vendors, transcoding is one of the things we do. In fact, software transcoding in our PowerMedia XMS it is one of the things we really well, but is not the only thing we do or the thing we prefer to do. It’s simply not tenable to build a product only does the one thing everyone hates doing. To make our customers who have to transcode hate it less we have been making it easier to do and cost less.

Consensus on this topic would be good for us all

We hope consensus is reached in the WebRTC Video MTI codec discussion to help accelerate market adoption. Even though our transcoding feature set could potentially benefit from a lack of video MTI, the whole market would suffer from a more limited adoption of WebRTC. Speaking as a commercial vendor, we all stand to gain by growing the WebRTC rather than trying to divide it. There are plenty of other higher-value features to sell beyond transcoding.

Let’s all root for progress to be made at IETF 91 in Hawaii. Perhaps there should be a rule that no one can go to the beach until consensus is reached. That would be sure to force some progress.

Want to hear more?

I will speaking about this topic and other media-related issues during the WebRTC Expo in San Francisco in the next weeks. I am also at the TADSummit in Istanbul this week. Contact me here if you would like to talk at either of these shows.