VP9 is headed to WebRTC. What is it and why do we need it?
You might have missed it, but during November of last year, Justin Uberti gave a short explanation on Google+ about the current WebRTC VP9 implementation on Chrome:
VP9, our next generation codec, is now supported in WebRTC in Chrome Canary, when you run it with the –enable-webrtc-vp9-support flag.
Time to check why this is so important for Google (and the rest of us).
Before we start, a word about VP9 – It is a video codec, considered to be the successor of VP8 – one of the two mandatory video codecs in WebRTC (and the one currently used by almost all implementations using WebRTC).
1. Better video quality
In theory, VP9 offers two options:
- For the same bitrate you’d use with VP8, it can squeeze better video quality (visibly better)
- For the same quality you’ve been used to with VP8, it can use considerably less bitrate
It translates to opening the door to things like 1080p or 4K resolutions (not that I can understand the reason why you’d want it), but at the end of the day, what you can expect is a better video quality to something that is good enough already.
It also translates to lower costs of bandwidth of your TURN servers.
2. Better multipoint video sessions
Multipoint video conferences are tough today. Implementations aren’t straight forward, and there are few out there that do it well.
There are three architectures for multipoint:
- Mesh – will be challenging with VP9’s CPU requirements
- Mixing – prohibitive in scale due to cost per port, and VP9 isn’t going to make it any better
- Routing – the current favorite of WebRTC vendors, will get a boost once VP9’s SVC capability is introduced
Almost 18 months ago, Vidyo announced their collaboration with Google on SVC in VP9. SVC will enable an SFU, which handles multipoint video routing, to receive a single video stream from each participant in a session, and without decoding it, to split it into layers, deciding how many of these layers to send to other participants of the call for best user experience.
Routing with VP9 is going to be far superior to what is possible with VP8 or H.264, so multipoint video use cases are going to improve a lot by adopting it.
3. Royalty free video codec
As I always say, these codec wars are never about the technical aspects – they are about the business side. And in our case, it is the fight between a royalty bearing codec to free access to video coding.
By running faster than competition into the next generation codec, and having VP9 out there in Chrome for WebRTC, Google are trying to force the industry to switch from H.265 to VP9.
If they succeed, this is going to be a boon to all video related use cases on the internet and elsewhere – reducing royalty costs is a blessed outcome.
We are accustomed to picture compression being free to use. We are now being warmed up to voice codec compression being free with Opus. What is left is video coding, and while it might take time, there is a need for it to happen sooner rather than later.
Why is it important?
If you thought we’ve got to a point where everything is going to be stable, then you are wrong. Expect the next 2-3 years to be interesting when it comes to WebRTC. Also expect ongoing investment in maintaining your newly launched service, as WebRTC will be changing in many ways – the VP9 video codec introduction is but one of these changes.
The challenge multipoint conferencing poses is still high. With a VP9/SVC implementation, this should change, opening up the route for more use cases. It depends on the tooling vendors to adopt this technology and offer suitable solutions that use it.
The better the quality, the less high end solutions are required. This doesn’t assist those with traditional business models and product offerings in the video conferencing domain.