In ABR (adaptive bit rate) streaming, the player controls the quality (bit rate) selection function of its maximum available bandwidth estimation based on the buffer level. The player has one objective: to maximize the quality of experience (QoE) perceived by the user while avoiding rebuffering. Bandwidth estimation performed by the player is usually based on HTTP (application layer), which does not work properly in some situations like with CMAF low latency. With the latter, a video segment is split into chunks that are coded and transmitted continuously in such a way that a segment is sent and received roughly at the video bit rate. Relying on the buffer level is not really feasible as with low latency the aim is to have the buffer as small as possible. In order to mitigate this problem, several player-side algorithms have been proposed in the context of Twitch’s ACM MMSys 2020 Grand Challenge dedicated to the problem.
We have adapted the Twitch MMSYS 2020 Grand Challenge software environment in order to compare Broadpeak’s server-side technology S4Streaming (S4S) solution for low latency with the winner algorithms.
The results showed a clear advantage of using S4S streaming in almost all situations.
The figure below shows the QoE score for the default dash.js client-side algorithm (stock), the two client-side “MMSYS/Twitch Grand Challenge” winners algorithms (L2A and LOL), and S4Streaming, our server-side algorithm. The QoE score is computed based on the formula provided for the challenge (find it here). The “double” figure represents the score computed with video representation bitrates that were 2 times greater than those recommended for the challenge (<=1Mbps).
