All the signs direct to a sad truth: transcoding will be an integral part of our WebRTC future.
It started out nicely. The utopian idea that a single voice codec and a single video codec can rule it all in WebRTC: just have Opus and VP8 supported and all will be good in the world.
For the voice part, we are mostly there. For the video part, we are as far as can be:
Most of today’s use cases focus on VP8 and Chrome-first or mobile-first and move on from there to expand their coverage.
The imminent introduction of Microsoft Edge in Windows 10 with its initial optimistic reviews may change that, where the focus of WebRTC based services will become Microsoft Edge first. Especially if Chrome will get H.264 support this year.
With many complaining about lack of support on Microsoft’s part in WebRTC, the introduction of a Microsoft Edge browser with WebRTC means that vendors will attempt supporting it as part of their offering.
If the initial version of Edge includes only H.264, which is a reasonable assumption, it will force WebRTC services to support it first:
With the mounting headache of adding additional video codecs, many will try to reduce the number of codecs they need to support. The alternatives will be:
Some will choose the second alternative, either because they will assume Google will have H.264 in Chrome faster than Microsoft will get VP8 on Edge. Or because they will assume H.264 offers better performance on mobile.
The result? A rise in the popularity of H.264 in WebRTC.
The end result? The need to support multiple video codecs.
Google may well be aware of this, which is one of their reasons for pushing VP9 into WebRTC as fast as possible. The real battleground will be between VP9 and H.265. Getting VP9 there faster means a higher probability of winning the video codec war. It will be interesting if and how this plays out in 2016.