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.
I’ve written about this before, when comparing H.265 to VP9 and when looking at why Google are pushing VP9.
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?
To make a better decision, you need understanding. Otherwise, how can you know if VP9 codec is the right choice for your WebRTC application?
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.
I would not bet on SVC. Simulcast delivers the same functionality today.
Fippo,
Simulcast is a poor man’s solution to what SVC can do. While it works, there are many use cases it will not perform as good as SVC.
can you name a few? 🙂
Chrome’s simulcast implementation is finely attuned to how the hangouts router works, I do not see them putting real effort into this without a good reason.
I enjoyed this article.
As a WebRTC novice, I appreciate articles like yours to help me keep up on whats happening in the WebRTC realm.
I’m also interested to see what Mozilla Firefox does next with their “Hello” implementation of WebRTC. I’ve used that a few times and find it a significant step forward enabling individuals the ability to use WebRTC without 3rd party intervention. If Firefox can implement multipoint conferencing with Hello, that would be a real trend setter.
Jeff,
Mozilla are using TokBox for the Hello solution, which has a multipoint implementation already. It is a decision that needs to be made to enable it – one that requires more resources and money, as multipoint is a lot more taxing than the current peer-to-peer implementation of Hello.
Hi Tsahi,
I guess it has taken a few years to get this for, and things are constantly changing and improving. I suppose in time it will eventually happen… And, of course I’m a Chrome fan, so I’m interested to see what Google follows up with along with VP9. I would like to see Google implement something similar to Hello. All these new developments are interesting to watch and see what’s next…
There is. They call it Google Hangouts.
Ok, you got me on that one 🙂
However, I’m not big on the social network solutions. That’s what I liked about the Firefox Hello solution. One-on-one connections can be setup directly between two parties without a social network or accounts or sign-ins – that’s what I was hoping Google can follow-up with. I suppose they may think Hang-outs is all we need, though.
SVC for VP9 won’t necessarily come for free. Vidyo’s own implementation will require Vidyo’s video routers in the background, and someone has to pay for them.
Others may choose to implement SVC-enabled versions of VP9 as well and just give it away. But, I’m not aware of anyone who is planning on doing this… yet. And Vidyo has some intellectual properly on doing this well locked away through patents.
I find this article very interesting, because it has been known that the video codec has been a hurdle. I wonder what this means for WebRTC and its application…I’ve seen some pretty cool applications of WebRTC on the internet, as well as some pretty rad FB startups. I’m most interested in file sharing capabilities. One example I’ve seen is shareplace.us , but it still has limitations on the browsers it can be used on.