by Stefan Slivinski, Video Team Manager, LifeSize
There are many applications for SVC, both outside and within the video communications space. One example is a video conferencing bridge, which allows several people to participate in the same video call. It’s essentially the same as a teleconferencing bridge but with video.
Just as a telephone is used to talk through a teleconferencing bridge, an endpoint is used to talk through a video bridge. Unlike telephones though, endpoints vary widely in their capabilities. Some endpoints are run on a smartphone and send and receive low resolutions, and some are very powerful and capable of very high resolutions (up to Full HD at 1920 x 1080.)
The objective of a bridge is to provide the best possible experience for each individual on the call, which means sending low resolutions to less capable endpoints and high resolutions to more capable endpoints. This requires the bridge to decode the entire incoming video, merge everyone together, and re-encode a custom stream that best fits the capabilities of each endpoint.
This means the bridge must have one decoder and one encoder for everyone on the call. The problem with so much decoding and re-encoding is that the bridge introduces additional delay, making it harder to communicate and sometimes more expensive due to the need for specialized hardware.
SVC is able to address this deficiency by allowing a bridge to forward video streams from one participant to everyone else without the need to actually decode or re-encode any video. Everyone receives a separate stream from everyone else without incurring any additional delay.
In order to provide the best possible experience regardless of an endpoint’s capability, the bridge would send a small spatial layer to smartphone endpoints and a high spatial layer to the more powerful endpoints. And because the bridge doesn’t need to encode or decode any video, it can use commodity hardware at a fraction of the cost of the specialized hardware used in today’s bridges.
Another benefit of SVC is error resiliency, which I’ll cover in my next blog. Stay tuned.