OpenAI, LLMs, WebRTC, voice bots and Programmable Video
Learn about WebRTC LLM and its applications. Discover how this technology can improve real-time communication using conversational AI.
Read MoreVP9 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).
In theory, VP9 offers two options:
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.
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:
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.
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.
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.
Learn about WebRTC LLM and its applications. Discover how this technology can improve real-time communication using conversational AI.
Read MoreGet your copy of my ebook on the top 7 video quality metrics and KPIs in WebRTC (below).
Read More