As detailed in previous posts on webrtcHacks, the Internet Engineering Task Force (IETF) has worked for the past few years to standardize the “on-the-wire” protocols that make up the WebRTC engine. It is coming up on 3 months since IETF 88 in Vancouver, where the IETF was to have settled the matter of a mandatory-to-implement (MTI) video codec. The process resulted in no consensus, and the task of finalizing WebRTC 1.0 drags on with MTI video codec(s) in question.  A recent straw poll among IETF participants shows how divided the issue remains.

No stranger to the IETF, and the subject of video technologies, Chris Wendt is a Principal Architect within the Office of the CTO at Comcast, a leading North American Multi-System Operator (MSO). Chris has spent most of his career in the fields of multimedia and communications, including work with MPEG-4 video coding and streaming solutions at Sarnoff Research. He has been an active participant in the IETF, and more recently, a familiar face at WebRTC industry events. Chris was a panelist at the WebRTC Conference and Expo, where he commented on some very progressive approaches for operators deploying web enabled services like WebRTC. Chris provides some expert opinion on the state of the WebRTC video codec debate, on webrtcHacks.

{“intro-by” : “reid“}

---

On the Video Codec Debate: Commentary by Chris Wendt

I, like many in the WebRTC community, have been following as the video codec debate rages on. At first, it was interesting to watch; royalty-free, that would be great; universal interoperability, that’s great too. But over the past few months it has really gotten to the point where I ask, “what is the point of following this issue?” The debate has become both unhealthy to the process and, what I find even more disturbing, increasingly it has turned nasty and opinionated.

From the beginning, I’ve been questioning why define MTI in RTCWeb.

“While it would be wonderful if everybody agreed on a single video codec, I don’t see any possibility that one can satisfy all use-cases in any practical way. Whether it’s browser to browser or browser to terminal, one can argue that her use-case is more valuable than the other, but we can’t all agree on that either.”
Chris Wendt on the RTCWeb mail list – March 14, 2013

This unending discussion is really undermining the effort, and more importantly the camaraderie and spirit of this great engineering effort. It’s sad to see. Not that the standards process is always full of unicorns and argument free, but this just seems to be sucking the wind out of the room, certainly more than I have personally ever seen before.

And to what end? I really believe that, while the absolute desire for a single codec as MTI is understandable and logical, it is a bit misguided.
Why do I dare to say that? There is logic to my opinion, but it is not necessarily straight forward. It also has nothing to do with whether either codec has better quality, or how IPR restricted a codec is, or if one or the other has better cool-factor.

It has everything to do with applications, products, and customers. Problem is, the RTCWeb working group membership represents a very wide range of individuals, companies, applications, use cases, and video codec needs. There are traditional telecom apps, there are OTT communications apps, there are customer service apps, there are gaming apps, and there are probably folks from the porn industry. Point being, there isn’t just one single ecosystem that needs to inter-operate. Rather, there are many diverse applications who likely never will. That’s all fine and dandy, and if the story could end there in the context of RTCWeb alone, we could tell participants to either decide for yourself, or go to your friendly industry forums and consortiums and figure out what video codec serves you best, and call it a day.

But, there is this little issue of our favorite Swiss army knife, “the browser.”

This browser is, of course, the thing that binds us all together, for better or worse. So if app A likes H.264, and app B likes VP8, and app C likes the next super-duper SVC/Simulcast/3D/360 degree enabled codec, there is a problem. And, I believe, this is the core issue to focus on. The debate is not for a general audience. It’s not for telco folks to tell the independent app developers to use H.264 or vice versa with VP8. It’s that the browser is the common tool, the common application environment. Because the browser is the core issue, and not anything specifically to do with rtcweb and protocols, I believe the decision of which video codec(s) to support really lies in the browser community alone.

This is a product issue. One that is part of the odd world of HTML5, W3C, and Web Standards in general, where consensus makes the platform more valuable, but competition has a funny way of playing a part of the browser ecosystem. This fine line of working together for compatibility while trying to differentiate to gain market share.

I believe this is the context where, as application providers, and as “customers” of the browser vendors, the best we can achieve is to appeal to their product managers to get support for the latest and greatest set of codecs for our application. For the browser vendors, it’s a value proposition: am I willing to make the investment, either in licensing cost, or IPR violation risk to satisfy the requests of my customers.  This and only this will be the mechanism that a video codec gets implemented in a browser, not by a non-binding technical standard or a bunch of very smart technical experts.

I think the world of web standards is amazing. It has come very far and the world is better for it. IPR has always been a hot button issue, and in most cases, for the good of the industry and the world, IPR has been addressed in a reasonable way, or absorbed by the browser vendors. Video has just been contentious because of historical precedent and it’s collision course with the open web.

While I’m not a big fan of the debate, of course, I do give Google credit for bringing the debate to the forefront. Certainly, we likely wouldn’t be even considering the fact that H.264 could be royalty free (at least in a near time frame) if it weren’t for the industry debates over H.264 and VP8. And that is a good thing.

Where to go from here…

Short term, I’m hopeful that browser vendors can and will take Mozilla’s lead, and by-and-large support both H.264 and VP8. But, get ready for the next round of debates. There is much talk of SVC and simulcast support, and the impending VP9 and H.265 codec integration. Will browsers continue to support codec, after codec? Is there a H.26x and VPx framework that supports SVC and simulcast features in a reasonable way, so as an app developer I can have my pick of preferred codecs?

Will Daala come and save us all to be the one and only codec to rule them all?  I’m optimistic this can all work out to a reasonable conclusion, but it’s clear that it will take a little time and a little evolutionary dust to settle in video codec land. Market forces will dictate directions given compelling applications and robust implementations. I say, let’s focus, as a WebRTC community, on working towards a conclusion of the specifications and continue building the compelling applications that will drive adoption. There is much work to be done to have a mature set of specifications and implementations, and things will likely look different in 6 months or a year when other players and browser vendors get in the mix as well.

I’m excited about WebRTC from the perspective of enabling contextual conversations. I believe this really is the future of communications, and am happy to be involved in building a small piece of it. As a community, let’s get past this debate and just accept what is painfully clear, we all have different opinions and preferences and the opportunity to select a single consensus driven MTI is not going to happen in the IETF. I believe this is OK, and not the doom and gloom scenario others have discussed, and will likely even evolve beyond H.264 and VP8 perhaps quicker than most would imagine. Video codec aside, I think there is a bright future for both WebRTC and RTCWeb in many contexts and is laying the foundation for what will be an extremely valuable set of tools to enable the next iteration of real-time communications. Please contact your local congressman to say “no” to further MTI debates, and get back to work.

{“author” : “Chris Wendt“}