ADAPTIVE BITRATE ALGORITHMS: HOW THEY WORK AND HOW TO OPTIMIZE YOUR STACK

22 juin 2016

Streamroot: Who are we?

PARTNERS

INFINITE POSSIBILITIES, LIMITLESS DELIVERY

Streamroot combines the best of a controlled, centralized network with the resilience and scalability of a widely

distributed delivery architecture.

Presentation Outline

I. Design goals

II. Components: Constraints & ParametersExamples: hls.js & dash.jsBasic Algorithms + improvements: smoothing, quantizing, scheduling

III. Going furtherAnother Approach: buffer levelsThe key to improving: testing and iterating

I. Design goals: optimize viewer experience

1. Maximize efficiency – stream at the highest bitrate possible

2. Minimize rebuffering – avoid underrun and playback stalls

3. Encourage stability – switch only when necessary

(4. Promote fairness across network bottlenecks)

I. Design goals: why this matters

Views 24 min longer when buffer ratio is < 0.2% for live content

View time drops 40% when > 0.4% buffer ratio mark

Buffer ratio vs. play time

Source: NPAW aggregated data for a set of European live broadcasters

II. Components: Constraints and Parameters

CONSTRAINTS PARAMETERS

Screen size / Player size Buffer size

CPU & Dropped frame threshold Bandwidth & possible bitrate

Startup time / Rebuffering recovery (Bonus: P2P Bandwidth)

II. Components: constraints

1. Screen & Player SizeResolution should never be larger than the actual size of the video player

2. CPU & Dropped framesDowngrade when too many dropped frames per second

3. Startup timeAlways fetch the lowest quality first whenever the buffer is empty

Screen & player size: HLS.js

https://github.com/dailymotion/hls.js/blob/master/src/controller/cap-level-controller.js#L68

Checks the max CapLevel corresponding to current player size

Frequency: every 1000 ms

Dropped frames: HLS.js

https://github.com/dailymotion/hls.js/blob/master/src/controller/fps-controller.js#L33

Calculates the dropped frames per second ratio.

If > 0.2, bans the level forever goes into restricted capping levels

fpsDroppedMonitoringThresholdfpsDroppedMonitoringPeriod

Startup time strategies

https://github.com/dailymotion/hls.js/blob/master/src/controller/stream-controller.js#L131https://github.com/Dash-Industry-Forum/dash.js/blob/master/src/streaming/rules/abr/InsufficientBufferRule.js

First segment loaded from the first level in the playlist (capped by the cap level rule), then continues with normal ABR rule.

HLS.js DASH.js

Always loads the lowest quality when buffer empty

II. Components: parameters

1. Bandwidth Estimation (goal: maximize bitrate) Estimate available bandwidth based on prior segment(s)

Available bandwidth = size of chunk / time taken to download

2. Buffer size (goal: minimize rebuffering ratio)Rebuffering ratio = buffering time / (buffering time + playback

time)Also: Abandon strategy

Bandwidth estimation: HLS.js quantization

https://github.com/dailymotion/hls.js/blob/master/src/controller/abr-controller.js

Adding levels quantization to reduce oscillation

(Bonus) P2P bandwidth estimation: HLS.js

Bandwidth estimation: DASH.JS smoothing

Bandwidth smoothing, taking the last X segment estimations into account

https://github.com/Dash-Industry-Forum/dash.js/blob/development/src/streaming/rules/abr/ThroughputRule.js

Bandwidth fragment abort rule: HLS.js and DASH.JS

https://github.com/dailymotion/hls.js/blob/master/src/controller/abr-controller.js#L51https://github.com/Dash-Industry-Forum/dash.js/blob/master/src/streaming/rules/abr/AbandonRequestsRule.js

HLS.js DASH.js

(Bonus) DASH.JS complementary buffer-based rules

Prevents from switching down when buffer is large enough (mostly for VOD)

https://github.com/Dash-Industry-Forum/dash.js/blob/development/src/streaming/rules/abr/BufferOccupancyRule.js

Buffer size based ONLY no more bandwidth estimations

Uses utility theory to make decisions: configurable tradeoff between rebuffering potential & bitrate maximization:

Maximize Vn + y SnWhere:Vn is the bitrate utilitySn is the playback Smoothnessy is the tradeoff weight parameter

IV. Going further: DASH.js BOLA, another approach

IV. Going further: test and iterate!

You’ve got the power!

- Know what is important to you (buffering, max bitrate, bandwidth savings…)

- Compare and cross with QoS analytics to understand your audiences

- Test and iterate: AB testing allows you to compare changes in real-time

1. Tweak the parametershttps://github.com/dailymotion/hls.js/blob/master/API.md#fine-tuning

2. Write your own rules!AbrController: AbrControllercapLevelController: CapLevelController,fpsController: fpsController

IV. Going further: how to improve in practice

HLS.js DASH.js

1. Tweak the Parametershttp://cdn.dashjs.org/latest/jsdoc/index.html

2. Write your own ruleshttps://github.com/Dash-Industry-Forum/dash.js/wiki/Migration-2.0#extending-dashjs

https://github.com/Dash-Industry-Forum/dash.js/blob/development/src/streaming/rules/abr/ABRRulesCollection.js

QUESTIONS?

Guess what?

We’re Hiring!Core JavaScript ■ Backend Scalability ■ Junior Software Developer ■ Presales & Support

http://www.streamroot.io/jobs

Further Reading / Contact Us

Probe and Adapt: Rate Adaptation for HTTP Video Streaming At Scale. Zhi Li, Xiaoqing Zhu, Josh Gahm, Rong Pan, Hao Hu, Ali C. Begen, Dave Oran, Cisco Systems, 7 Jul 2013.

Improving Fairness, Efficiency, and Stability in HTTP-based Adaptive Video Streaming with FESTIVE, Junchen Jiang, Carnegie Mellon University, Vyas Sekar, Stony Brook University, Hui Zhang, Carnegie Mellon, University/Conviva Inc. 2012.

ELASTIC: a Client-side Controller for Dynamic Adaptive Streaming over HTTP (DASH). Luca De Cicco, Member, IEEE, Vito Caldaralo, Vittorio Palmisano, and Saverio Mascolo, Senior Member, IEEE.

BOLA: Near-Optimal Bitrate Adaptation for Online Videos. Kevin Spiteri, Rahul Urgaonkar , Ramesh K. Sitaraman, University of Massachusetts Amherst, Amazon Inc., Akamai Technologies Inc.

Drop us a line:

Nikolay Rodionov, Co-Founder and CPO, nikolay@streamroot.io Erica Beavers, Head of Partnerships, erica@streamroot.io