WebRTC Expert Feature

September 03, 2013

Google, Vidyo Team on SVC for VP9 and WebRTC - Is SVC the Right Answer?

Google and Vidyo recently announced a partnership to deliver SVC capabilities with VP9 in WebRTC and to contribute that to the open source client initiative led by Google. This is a significant development as it helps to paint how WebRTC will explode out of the current demonstration applications into the mainstream.

While many people think of WebRTC as a browser to browser protocol, it is in fact peer to peer. And one of those peers can be a media server. Media servers are devices/systems that facilitate a number of functions above a device peer to peer capability. They enable conferencing beyond the limited number that can be done peer to peer, enable recording and analysis of the media flow, and enable connection of diverse devices and provide transcoding. In other words, for a large percentage of WebRTC communitarian applications, a Media Server is going to be required.

In the conferencing world, there are two ways a media server can function: as a multipoint control unit (MCU) or as a video "router" or "switch" (different names, same function). In the MCU case, all of the conferencing nodes send their video to the MCU where the MCU decodes the video and generates the output and mixes in a single stream to send to the endpoints. In the router case, the streams are not decoded and mixed in the media server, but rather forwarded to all of the other end points. In the router version, the challenge is that forwarding all of the streams at full quality/resolution/frame rate is a lot of bandwidth. 

To solve these issues, Scalable Video Coding (SVC) was invented. In SVC, each video stream is encoded so it has multiple layers, each with different bandwidths (and therefore quality levels). The idea is that you only send the right layer based on the network bandwidth, location on screen, etc. In other words, you may receive four lower bandwidth streams for the four small windows on the screen and only high bandwidth for the large window. The big advantages to SVC/routing are elimination of the latency and quality issues that MCUs insert at the core and potentially significantly reducing the price of the media server. As the video is essentially dealt with totally in an encoded form, SVC/routing eliminates a lot of core processing.

The plan to have routing available for WebRTC is a great step. If we look forward to implementations, we will probably require both routing and MCU functionality to meet the variety of use case scenarios that WebRTC can enable. An HD executive video conference with four locations is a very different use case that a teacher doing an on-line course with 50 students on video. And, of course, for some time, MCUs are required to integrate to older devices and may be important for some low-bandwidth locations for larger screen displays. I look forward to the delivery of the Google/Vidyo proposal and code.

The one thing I wonder is whether we should also consider multi-stream AVC as a way to implement routing (and even as a part of MCUs) in WebRTC. In SVC, a single stream is encoded with typically three layers of quality/bandwidth. The cost of doing this is a percentage, typically between 10 and 20 percent, higher total bandwidth than the highest quality stream. The router can then strip off the higher quality content to send only a lower quality layer if the network bandwidth or display type requires it. 

An alternative to SVC is to send two or more AVC streams to the router and have it decide which one to forward. In other words, if I am sending a 1080P stream at a bandwidth of 1 Mbps, I also send a 540P stream at a bandwidth of 250 Kbps or a 540i stream at 125 Kbps. In this case the router would send the 125Kbps stream if the video was in a small window on the end point and the 1 Mbps stream for the large window. 

Generally, the argument is that SVC is more efficient that multiple rate AVC, but analysis shows this is very dependent on use cases. While I applaud Google for and Vidyo for partnering for this demonstration, I believe we should not immediately focus only on SVC, but should also consider multi-rate AVC as a possible routing mechanism. I would be interested in your opinions about this.

Edited by Alisen Downey


Free WebRTC eNewsletter

Sign up now to recieve your free WebRTC eNewsletter for all up to date news and conference details. Its free! what are you waiting for.