What is Scalable Video (Simulcast)?
Normal OpenTok sessions use congestion control feedback: the publisher bitrate is set from feedback from all active subscribers; each subscriber asks the publisher to set a bitrate that the subscriber can handle. In non-scalable video streams, this mechanism affects the experience of all subscribers in the session, as the publisher generates a common quality for all subscribers, and it needs to fit the worst subscriber capabilities case
In a broadcast topology, normal congestion control presents a “race to the bottom” - a higher subscriber population increases the probability to have a subscriber in trouble, either due to network or due to device capability issues. In those cases, publisher’s bit rate will decrease to the point of having poor quality video for all participants.
Scalable Video addresses the trade off between video quality and subscriber capacity by delivering multiple layers of video with a diversity of encoded qualities directly from the publisher. TokBox smart media routing servers are able the to adapt quality independently for each subscriber to what's best for their respective network or processing capacity; thus, allowing the remaining subscriber pool to remain independent and unaffected by the rest of subscriber conditions.
Note that Scalable Video is a publisher property. Default platform behavior is designed to avoid use of Simulcast for 1-1 (1-participant) calls. So a publisher will publish in Simulcast only if there are >2 connections in the sessions. To enable the Simulcast from first connection onward, (in a 1-to-many participant calls, where the first connection in the session might be the publisher), please write to firstname.lastname@example.org and share the API KEY.
How does scalable video improve performance?
We observed that the QoE benefit this feature offers improves as the number of receivers per sender increases; i.e. with special impact on large multi-party & broadcast use-cases.
The amount of improvement we get with Scalable Video depends a lot on the specific use case (type of devices, networks, resolutions, and number of receivers).
On the subscriber side, when using Scalable Video, the average bitrate received by endpoints is independent of the number of receivers. Quality of the stream received by each subscriber will be better adapted to their respective network and hardware capacity conditions without affecting the other subscribers. A general expected result is an overall higher average bitrate across the platform streams for large multi-party or broadcast use-cases.
What are the limitations of scalable video and the supported browsers/devices?
- Currently Scalable Video is only available for Chrome, Safari, and native iOS/Android publishers. The feature is 100% transparent for the subscriber that will keep receiving a single regular VP8 video stream.
- With our latest server release and client SDK 2.14 and higher, Scalable Video will be supported on -
- all 64-bit Android devices and
- latest iOS devices starting with iPhone 6 & above
- For client SDKs prior to 2.14, the supported devices (besides laptops/desktops) are:
SAMSUNG-SM-G935A (ATT carrier)
SAMSUNG-SM-G935V (Verizon carrier)
- Scalable Video has an overhead cost in bandwidth and CPU usage on the publisher. This may be especially challenging for older generation mobile devices. This overhead makes it suboptimal for 1:1 calls. In any case, it is a key requirement for Scalable Video to have sufficient upload bandwidth available to publishers to properly operate and provide improvements.
- Screen-sharing streams do not use Scalable Video.
For more details on this feature, check out the article here.