All the signs direct to a sad truth: transcoding will be an integral part of our WebRTC future.
For the voice part, we are mostly there. For the video part, we are as far as can be:
- VP8 and H.264 have both been mandated
- Firefox is already supporting H.264, alongside VP8
- Chrome is hard at work adding VP9. H.264 takes second priority for them
- Microsoft’s new Edge browser will most probably focus on H.264
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.
Video codecs supported by each browser
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:
- For base P2P services, this won’t matter, as the browsers will need to negotiate and come to a decision on their own
- For those needing server side processing, be it for interoperation with other networks, recording, multiparty or other - there will be a need to decide which codecs to support
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:
- Support VP8. Get it to run on Firefox and Chrome. Wait for Microsoft to join the party
- Support H.264. Get it to run on Firefox and Edge. Wait for Google to join the party
- Support both VP8 and H.264
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.