With Microsoft jumping into WebRTC by supporting H.264 and adding everything into Internet Explorer (IE), Skype, and whatever else looks good this week, WebRTC advocates need to have a rational, calm discussion on adding new codecs. The "VP8, Opus, or Death" crowd needs to start thinking beyond H.264 video support for reasons that will become clear shortly.
In the beginning, the hard line within WebRTC -ville was thou shall use VP8 for video, Opus for audio, and G.711 for backwards compatibility with the PSTN. Somewhere along the way, G.722 made it in there for desktop HD voice support and people got iSAC and iLBC as audio bonuses because Google Global IP Solutions and open sourced its audio intellectual property and code.
Video has been the big battle ground, with Microsoft and Cisco being the loudest voices for H.264 video support. There's a huge installed base of enterprise video devices built around H.264, so the recent breakthrough has been Cisco open-sourcing its H.264 code base and making it available in plug in form. With H.264, WebRTC can be a widely used tool in the enterprise.
For the next five minutes, all is happy as Microsoft goes to plug in WebRTC everywhere in its communications ecosystem and everyone agrees that H.264 and VP8 will be the mandatory video codecs for WebRTC.
Opus is pretty much state-of-the-art still when it comes to audio, but VP8 for video is already looking a bit long in the tooth when you consider VP9 has been out for more than a year in production versions of Chrome and Mozilla since March of this year. Development of VP10, the next great video codec from Google, started in September. Google says they plan to issue new video standards about 18 months after VP10 is released.
Put another way, VP8 is already behind the curve with VP9 in production and VP10 in development. It's a bit odd to saddle WebRTC with a fixed number of codecs and no way to elegantly, without a committee fight, inject new codec support. Purists will insist the beauty of WebRTC is that there are a limited number of codecs to support and all of them are open source.
I'd like to see an automatic update mechanism in WebRTC where the browser distributor would be able to drop in new open source codecs without committee or, alternatively, a browser could pick up a new codec on-the-fly from a webpage/website/WebRTC service provider if needed. Do you really need to have committee meetings to upgrade video quality? It should be a simple codec update, so long as everyone has equal access to the codec.
Being able to download a new, but licensed, codec from a web page or WebRTC service provider could provide a "shut up" point to GSMA's scheming on getting AMR-WB into WebRTC to avoid transcoding headaches. WebRTC developers and individuals shouldn't have to pick up the cost for AMR-WB because mobile carriers don't want to pay for transcoding between AMR-WB and other HD voice codecs, such as Opus and G.722. If a service provider wants to incorporate AMR-WB or other codec support within its WebRTC application, it's fine, but it should provide the codec to the end user if it wants to avoid the cost and expense of transcoding. A mechanism to provide a "transient," session-based use of a licensed codec would be helpful and useful. Yes, I know it is going to take more coding to do on-the-fly codec downloading, but it's an alternative to inflicting licensed codec usage upon an entire ecosystem of developers and users.
