By the end of 2015, WebRTC will have 3 video codecs.
Up until recently, using WebRTC meant you had VP8 as your video codec. Mozilla added H.264 into Firefox. And now that we know Microsoft Edge is adding WebRTC, it is time to ask what will be the video codec that will be supported?
My bet is on H.264 and no other video codec.
Here is how I foresee the video codec map in WebRTC browsers evolve by year end:
| Today | Dec 2015 (estimate) | |
|---|---|---|
| Google Chrome | VP8 | VP8, H.264, VP9 |
| Mozilla Firefox | VP8, H.264 | VP8, H.264 |
| Microsoft Edge | N/A | H.264 |
Why is this my forecast?
Google pushes Chrome towards VP9
- Google is in the process of adding VP9 already
- If all goes well, VP9 will be officially launched this year as part of WebRTC
- That said, Google can’t ignore H.264. It was added as a mandatory codec to WebRTC
- Not implementing it won’t look good, so Google will need to pay attention to it
- Since some have already added H.264 on their own to WebRTC, that shouldn’t be as challenging as the introduction of VP9
- Support for both H.264 and VP9 will maintain Google’s lead in WebRTC
Mozilla won’t have time for VP9 in Firefox
- Mozilla have bigger worries to deal with
- Firefox OS has been a dud, causing Mozilla to shift its focus of Forefox OS towards quality. This requires resource and attention
- Firefox is lagging behind Chrome in many areas of WebRTC (see is WebRTC ready yet). This is mainly true in the more sophisticated media processing features which are becoming a lot more common and required these days
- Until Firefox closes these gaps versus Chrome, it should not invest in a new video codec adventure
- Add to that the new ORTC APIs that get wrapped into WebRTC and the need to support promises
- To implement VP9, it first need Google to stabilize and improve its current VP9 support in WebRTC. This will delay its adoption of VP9 which will get it into 2016
Microsoft’s razor Edge focus on Skype (and H.264)
- Microsoft is late to the WebRTC game
- It has IE to think about and its new Microsoft Edge browser
- This isn’t just about adding WebRTC – it is about revamping IE and rewriting it with new rules (no plugins for example)
- The work on this new browser needs to be synchronized with other (LARGE) groups at Microsoft with their own announcements:
- Skype for Web
- Skype for Business
- A new Skype web SDK
- With so much on its plate, Microsoft will need to focus on the bare essentials
- First priority will be a WebRTC/ORTC implementation that can run Skype
- Second priority will be interoperablity with other browsers
- Firefox will come first, as it supports H.264
- Microsoft will assume Google will add H.264 before it can add VP8 anyway
- Once they get over the basics, it will be time to add VP8
- With their current speed, don’t expect VP8 to happen in 2015
Why is this important?
- The codec wars may have been over, or just in an intermission in between acts in this grand play; but at the same time, developers are left to their own devices in figuring what video codec to use
- Selection of a video codec needs to take into consideration many issues: performance, royalty payments, hardware support, browser availability
- At times, multiple video codecs will need to be supported
- In some cases, multiple video codecs will need to be supported in the same session (multiparty video calls)
Got a use case in mind for WebRTC? Which video codec will you be using for it? Check out how VP9 codec fits with WebRTC.
So… which of these video codecs should you use in your application? Here’s a free mini video course to help you decide.
Good analysis/prediction, Tsahi. Video codecs are going to be messy for developers for ever, but a lot of this will be hidden by whatever SDKs/PaaS platforms most commercial applications are likely to use. More work, obviously, if the use case is free and you are doing the work yourself. As you know, Twilio announced they would support both codecs and I am digging around to see what TokBox says but haven’t found it yet – but the standards decision should drive this for most toolkit vendors. But how tough this really is depends a lot on your use case:
– Free apps are the toughest because this is a hassle/potential-expense where there is no money to pay for other services to help
– Tough for “join from whatever/any-browser” video conferencing type apps where transcoding may start to loom in the worst case
– Easy for messaging native-apps to just embed whatever they want (WhatsApp, Facebook etc and also, I suppose, Hangouts)
– Manageable for customer service apps because (I believe) it will always be worth enabling both codecs on the controllable agent desktop so they can support all potential kinds of customer access.
My recent experience in the latter customer service area is that it is not too hard to abstract the communications layer and slide in the right communications element depending on how the customer needs to communicate – including choices of different WebRTC toolkits as well as non-WebRTC proprietary communications. However, this is a cost to maintain over time so reducing this complexity is highly desirable.
Lawrence, thanks.
The issue is with the fact that there are codecs to select from, but that they aren’t implemented everywhere. This adds complexity which is the antithesis of what WebRTC needs to be.
Of course! WebRTC should be simpler but it is still complex and difficult in some areas, particularly around browser support and video codecs, and this has been the case for some years now and is not changing fast enough. My (obvious) point is just that how badly this complexity bites you does depend on your use case :).
Much like Chrome, Firefox now has VP9 support in WebRTC behind a flag (in about:config). Since the spec for packetization isn’t finished yet (and not even Chrome has an implementation of the proposal), both Chrome and Firefox are using “generic” packetization, which works but doesn’t expose a number of possible features like layering.
Bottom line: you can make interop calls from Firefox to Chrome using VP9 today (if you pref it on in both browsers). This isn’t to say we might not lag their VP9 implementation – but we’re not far behind at the moment. Also, please do check http://iswebrtcreadyyet.com/ – such as Promise support, WebAudio integration, etc.
Randell,
Thanks for the update. I have missed the VP9 flag in Firefox.
Is it just me or do most people keep forgetting Mozilla is a much smaller organization with a lot less resources than Microsoft, Google or Apple.
Not sure what you’re trying to say here Lennie (though I do agree they are much smaller)
“Firefox is lagging behind Chrome in many areas of WebRTC”
Mozilla for most of the things will always create new independent implementations of protocols (to make sure webstandards works you need independent implementations) this take a lot of time. Otherwise Chromium (the open source part of Chrome) and Firefox would share a lot more code I’m sure.
I’m amazed Mozilla is able to deliver as well as they have. They do have a lot less of products than Apple, Microsoft or Google to focus on of course.
They learned their lesson with mobile. They were late to that market.
The next new consumer product coming to the market that Mozilla is working on is Virtual Reality. It looks like Mozilla is ahead of the pack. The first VR consumer products are planned for the end of the year/start of next year.
WebVR (they are developing a standard with Chromium developers) is based on WebGL and WebGL2 (also a standard still in development I believe).