Scalable Video Coding at its best is on its way to WebRTC courtesy of Vidyo, who stands to gain… ?
Scalable Video Coding (SVC), for those that are new to the term, is a way to take a single video stream, split it into layers and have the layers provide value one on top of the other. That value could be better error resiliency, better frame rate, higher video quality or higher resolution. What is it good for? Two things mainly:
- Error resiliency – the video looks better even in network hiccups
- Reduce load on the MCU – if you are planning to add multipoint video, then SVC makes the backend servers work less and provide better results (usually)
SVC was the reason Vidyo, a company that start from video conferencing veterans, existed in the first place – it went on a quest to kill the hardware MCU. While other video conferencing vendors have been gearing up their solutions towards SVC, I don’t think that any one of them reached the level of commitment, embedding and technology that Vidyo has. This is probably why Google opted for Vidyo’s H.264/SVC codec for their Google Talk and later Hangouts services.
Yesterday, Vidyo announced support of WebRTC. As stated in the press release:
Vidyo will develop a scalable video extension for the VP9 codec as part of the WebRTC client open source project.
[…]
Vidyo and Google will promote this version with relevant standards bodies.
[…]
Vidyo and Google plan to develop additional capabilities to further optimize the Hangouts experience for enterprise users.
Things to note from the announcement:
- This is about VP9 and not VP8. Google is planning to shift WebRTC to VP9 and probably sooner than later. The “present” to the market and the pressure over the mandatory video codec selection is going to be the addition of SVC technology as part of the package – a sweet deal considering the fact that SVC is still far from being commoditized
- The IP that Vidyo is contributing here is substantial, but relates only to the client side of the WebRTC story. A lot of the smarts of SVC resides in the backend, where WebRTC is lacking in existing infrastructure. SVC adds complexity there
- This requires additional standardization effort. VP9, which is Google controlled in a way, but more so WebRTC itself, where additional signaling is required to get a reign over the capabilities SVC brings to the table
Why Would Vidyo do such a thing?
That’s the main question. The answers are varied, with the best one being that they didn’t really have a choice. Vidyo is the youngest video conferencing company – the one that has the most to lose. It raised almost $100M, with the latest round of $17M just 4 months ago. It raises the question – can such an opening of their technology make them a billion dollar company.
On the other hand, ignoring WebRTC means a reduction in the size of the market they are targeting by upstarts – just as TNW went for LiveNinja’s platform and not Vidyo’s.
By pushing their tech into WebRTC on the client side, Vidyo gets a head-start in SVC support for WebRTC and with being able to introduce their VidyoRouter and other products with native WebRTC support faster than anyone else to the market. It probably has a few patents on the server side processing up its sleeves and will be willing to protect them.
This is probably the best move they had with WebRTC. Question is – will it be enough.
I am guessing that Vidyo and Google have already got something working with VP8 if the info about Google+ offering HD vidyo by swapping out from svc to VP8 is correct
http://techcrunch.com/2013/08/28/google-hangouts-go-hd-starting-with-hangouts-on-air/
Seems mainly to be Vidyo PR to counteract the negative attention of the announcement that Google is taking Vidyo out of Hangouts (and a favor from Google to support the PR, earned by Vidyo being a good Hangout partner).
There is no guarantee that standards decisions will end up in Vidyo’s favor, regardless of what they contribute.
All that said, you make a great point on the signaling demands of SVC…something that WebRTC has tried to stay away from…so will make for some very interesting discussion (which imo would have happened regardless of this PR as there are SVC (and CLUE for that matter) advocates within the WebRTC communities.
Personally I see this as an incredibly smart move by Vidyo. Whenever any kind of disruptive wave sweeps through an industry the smart vendors have to decide how to ride that wave and decide what becomes free (something will) and where their remaining points of value are. Google is a huge force fighting a broad and bloody cloud hegemony war with Apple, Microsoft, Facebook, maybe Amazon, probably nuevo-Yahoo and others. Google, for their own reasons, wants to completely commoditize video/audio/p2p-data real-time infrastructure on the client side. Why fight that? And why try and keep pushing H.264/H.265 against Google’s push for free licensing-unencumbered VP9 as a web standard? Google has spent ~$200M so far and appears committed to spending/building/buying whatever it needs to succeed at this. Vidyo is saying that they think VP9 and WebRTC is going to win substantial share and that they want to be a part of that win. They clearly plan to establish their value on the server side with app functionality, enterprise capabilities and security, and, yes, VP9 and H.265 interoperability to bridge the legacy/new-web divide, where Vidyo will be able to bring unique skills. Plenty of money to be made if you stay on top of the wave. Smart.
One of the things holding Vidyo back from large public deployments is the client licensing. It may not seem much but that $5 per installation is a brick around the neck of resellers trying to get Vidyo into more open projects. This seems to be a path to a web based free Vidyo client, that would have the capability to leverage investment in Vidyo ports. This would open possibilities where higher capability is required for a large population of users with relatively short term port usage.
Another opportunity would be to leverage the WebRTC peer to peer mode for small conferences, freeing infrastructure ports for larger conf or transcoding load.
Vidyo took it because they had to? This is about as good as it gets.
While Polycom and LifeSize are warning people not to be too excited about WebRTC compared to their solutions – Vidyo just made every Chrome desktop a high quality vidyo endpoint.
The stuff they are giving away is not important to their business (they sell cheap endpoints based on Intel NUCs), but has huge ramifications for their server infrastructure. They have also locked in their own technology to the next generation of video (WebRTC and VP9).
There is no money in desktop or browser video; however, there is a lot of money in video infrastructure. With VP9-SVC, every website that enables multipoint video as part of WebRTC may need a video media router (alias VidyoRouter!!!). They can build their own, or they can license Vidyo’s video media router. And by the way, Vidyo has 38 patents on this kind of technology, so good luck with trying to build your own without stepping on one of Vidyo’s patents. Thus, Vidyo, effectively, becomes like Twilio or Toxbox or others promoting infrastructure that will work with all of these WebRTC-enabled browsers. A nice move by Vidyo!