Last week's RTCweb working group meeting at IETF 88 in Vancouver failed to reach agreement on a Mandatory to Implement (MTI) video codec for WebRTC. As Eric Krapf noted, the debate has been between Google's royalty free codec (VP8) and H.264, use of which can require royalty payment for use to MPEG-LA. Prior to the meeting, Cisco attempted to break the logjam by releasing an H.264 module that anyone could use, that it would turn into an open source project, and announcing that it agreed to pay licensing fees for use. Cisco's proposal ran into several obstacles including:
* Pushback from FOSS (Free and Open Source Software) developers concerned about their inability to modify the Cisco module and recompile it into their own applications
* Pushback from Google and other pro-VP8 individuals and companies that would prefer to focus on a true royalty-free codec and one they believe is a better codec than H.264
* Concerns over the length of Cisco's commitment to pay H.264 royalties and what happens when H.264 is replaced by H.265
As Eric noted, the working group decided invoke IETF guidelines for reaching consensus through a committee approach, but my read of recent mailing list postings doesn't hold out a lot of hope for the committee to reach a decision that everyone can accept. Some ideas floating around include:
* The committee ultimately agreeing on either H.264 or VP8 as MTI
* Making both VP8 and H.264 MTI
* Making H.261 MTI so at least there's a standard video codec until there's further discussion and hopefully agreement on a path forward
* Making both or either codec a "should" implement but not making them mandatory to implement
None of these approaches are gathering much in the way of momentum. Because of their competitive position with respect to Google, I can't see any way that Microsoft and Apple agree to support VP8. And even if they do, H.264 is hardware optimized in mobile devices, VP8 isn't. Thus, VP8-based WebRTC solutions might work great on the desktop, but they are likely to consume a great deal of processor resources (and battery life) on iPads and iPhones. And legal challenges from Nokia persist. While Nokia has been unsuccessful with two previous lawsuits challenging Google's ownership of VP8, should its latest suit succeed, VP8 users could be required to pay royalties for its use.
Making both codecs MTI isn't viable either, WG members essentially agreed that pushing that approach would just lead to vendors ignoring the standard and refusing to implement one of the two codecs. H.261 was a novel idea, but it's an old codec with poor video quality.
Another way forward is for the WG to just agree to not have an MTI codec. But that means no standard way of supporting video in WebRTC. So you might end up with a future where some application vendors support VP8 since it's baked into Chrome, but using their apps in Safari or IE would require a plug-in (and would there be a standard VP8 plug-in or would each app require its own version of a plug-in?) If that's the road forward, WebRTC's promise as a ubiquitous browser-based voice/video/application sharing interface is largely destroyed.
I should add that even if there is ultimately agreement on a way forward, it doesn't mean that vendors will abandon plug-ins. For instance, H.264 enhancements like High Profile and Scalable Video Coding (SVC) aren't part of the discussion and won't be available even if H.264 is deemed MTI; thus, incentive remains for application vendors to use a plug-in-based infrastructure until H.265 is available (as it includes these enhancements). VP8 will soon give way to VP9, meaning VP8-equipped browsers will require an update.
So what's obvious from last week's meeting and subsequent discussions is that there's no obvious way forward. Absent a movement by MPEG-LA to declare H.264 royalty-free, or sudden massive momentum behind a more vendor-neutral codec like the open source Daala project, I'm increasingly worried that the WebRTC market will fracture into applications and web sites that support VP8 and those that require a plug-in or download to support H.264; thus the promise of WebRTC as a true open and ubiquitous voice and video client resident in every browser will be lost.
Follow Irwin Lazar on Twitter and Google+!
@imlazar
Irwin Lazar on Google+
