ABR Algorithms Explained (from Streaming Media East 2016)

  • Published on
    19-Jan-2017

  • View
    2.733

  • Download
    0

Transcript

PowerPoint Presentation

ADAPTIVE BITRATE ALGORITHMS: HOW THEY WORK AND HOW TO OPTIMIZE YOUR STACKStreaming Media East Track DTuesday, May 10, 2016 1:45 to 2:30 pm

CLIENT-ACCELERATED STREAMING

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 OutlineIntroduction: What are we trying to accomplish? Why does this matter?

The Basics of how ABR algorithms work: constraints & parameters, processExample: hls.js

Possible improvements to basic ABR algorithms: smoothing, quantizing, schedulingExample: dash.js

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

I. Why ABR?Multiplicity of network conditions and devices need to dynamically select resolution

HTTP / TCP stack removal from the transport protocol congestion logic client-level estimation & decisions

Source: FESTIVE diagram of HTTP streaming

I. Design GoalsMaximize efficiency stream at the highest bitrate possible

Minimize rebuffering avoid underrun and playback stalls

Encourage stability switch only when necessary

(4. Promote fairness across network bottlenecks)

I. Why this Matters

Buffer ratioViews 24 min longer when buffer ratio is < 0.2% for live contentView time drops 40% when > 0.4% buffer ratio mark

Buffer ratio vs. play timeSource: NPAW aggregated data for a set of European live broadcasters

II. The Basics: Constraints and ParametersCONSTRAINTSTRADEOFF PARAMETERSScreen size / Player sizeBuffer sizeCPU & Dropped frame thresholdBandwidth & possible bitrateStartup time / Rebuffering recovery(Bonus: P2P Bandwidth)

II. The Basics: ConstraintsScreen & Player SizeBitrate should never be larger than the actual size of the video player

CPU & Dropped frame rateDowngrade when too many dropped frames per second

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

II. The Basics: Tradeoff parameters

Maximize bitrate available bandwidth estimationEstimate the available bandwidth based on prior segment(s)Available bandwidth = size of chunk / time taken to downloadMinimize rebuffering ratio buffer sizeBuffer ratio = buffering time / (buffering time + playback time)

Abandon strategy

Source: BOLA

Example: HLS.js

HTML5 (MSE-based) media engine open-sourced by Dailymotion

https://github.com/dailymotion/hls.js

Very modular, so you can change the rules without even forking the media engine!

Explain what HLS.js is. Also say its quite simple to extend, as the different controllers are actually option parameters, and so can be easily replaced.

Example: HLS.js player size level capping

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

Checks the max CapLevel corresponding to current player sizeEvery 1000ms.You can also add up manual level caps on initialization.If the cap level is bigger that the last one (which means the player size has grown, like in Fullscreen for exemple), then you flush the current buffer and ask for a new quality right away (force the buffer)

Example: HLS.js dropped frame rule

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

Calculates the dropped frames per second ratio. If it is > 0.2, bans the level for ever => goes into restricated levelsNot activated in production!fpsDroppedMonitoringThresholdfpsDroppedMonitoringPeriod

Example: HLS.js startup strategy

https://github.com/dailymotion/hls.js/blob/master/src/controller/stream-controller.js#L131

First segment is loaded from the first level in the playlist, then continues with normal ABR rule.

First segment always from the lowest quality, then it continues with normal rule (very simple simple rule in practice!)Another optimization is just to load this level (and playlist), and dont wait for the other levels to have been loaded

Example: HLS.js bandwidth-based ABR controller

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

Simple algorithm,inspired by Androids AVControllers ABR algo

Simple algorithm,

Example: HLS.js P2P bandwidth estimation

Here talk about Streamroot, and the fact having the sources from different buffers is even more difficult!Code from us?xBasically a onProgress & bandwidth estimation too (coming from CDN & P2P network!)

Request.onProgressRequest.onLoad => classic estimation

With P2P estimation! Dont wanna infinite speed, and thus includes a P2P bandwidth metric.Not the same for different peers, so averaged and smoothedCode from us?xBasically a onProgress & bandwidth estimation too (coming from CDN & P2P network!)

Shema => a P2P cache and a CDN buffer => and time = 0

Example: HLS.js bandwidth fragmentLoad abort rulehttps://github.com/dailymotion/hls.js/blob/master/src/controller/abr-controller.js#L51

One of the most important ones hereWhat happens if you started a request and then BW drops ? Especially important when you ahve long fragments, this can very easily lead to a buffer underrun! After Half of the needed time, compare the estimate time of arrival to time of buffer underrun. And then see if there is another level that could solve the issue?

STRONG POINTSCOULD BE IMPROVEDVery simple and understandableAdd history parameter to BW estimation and adjustmentHandles CPU & player size constraintsStartup time constraint could be improved to get the lowest level firstConservative BW adjustment to avoid oscillationSound emergency abort mechanism

Example: HLS.js sum-up

Simple algorithm with better performances in practice compared to native implementations.

Pros:Simple implementation, taking into account a lot of different paramsWorks as good as the other implementation at Dailymotion! (alshls, android, iPhone etc)Cons:Still Naive bandwidth estimation => possible overestimation, and possible oscillation around bitrates?We can do a lot of improvements on bandwidth estimation! difficult to correlate a unique segment download time to the real devices available bandwidth, for several reasons:You can have very quick bandwidth changes, especially on a mobile network, as well as unexpected bandwidth dropsThe requests can be living in parallel with other TCP request (HTTP or any other on the users device)This can lead to frequent estimation oscillations!

Tweak the parameters

https://github.com/dailymotion/hls.js/blob/master/API.md#fine-tuning

Dropped FPS:

capLevelOnFPSDrop: false,fpsDroppedMonitoringPeriod: 5000,fpsDroppedMonitoringThreshold: 0.2

PlayerSize:

capLevelToPlayerSize: false,

Write your own rules!

AbrController: AbrControllercapLevelController: CapLevelController,fpsController: fpsController

Example: HLS.js how to improve

The different static constants more for you use-case?You can play with themYou can also easily build your own rule!Here is an example on Github?First explain how to do that?

III. Improvements: the pitfalls of bandwidth estimationNot resilient to sudden network fluctuations

Often leads to bitrate oscillations

Biased by HTTP/TCP calls on the same device/network

difficult to correlate a unique segment download time to the real devices available bandwidth, for several reasons:You can have very quick bandwidth changes, especially on a mobile network, as well as unexpected bandwidth dropsThe requests can be living in parallel with other TCP request (HTTP or any other on the users device)This can lead to frequent estimation oscillations!

III. Improvements: better bandwidth estimationA new 4-step approach:

EstimationSmoothing

QuantizingScheduling

Source: Block diagram for PANDA

difficult to correlate a unique segment download time to the real devices available bandwidth, for several reasons:You can have very quick bandwidth changes, especially on a mobile network, as well as unexpected bandwidth dropsThe requests can be living in parallel with other TCP request (HTTP or any other on the users device)This can lead to frequent estimation oscillations!

III. Improvements: estimation & smoothing

Estimation: take history into account!

Smoothing: Apply a smoothing function to the range of values obtained. Possible functions: average, median, EMWA, harmonic mean

How many segments? 3? 10? 20?

III. Improvements: quantizing

Quantizing: quantize the smoothed bandwidth to a discrete bitrateAdditive increase multiplicative decrease conservative when switchingup, more aggressive when down.

Source: FESTIVE

Good to minimize the oscillations!Can have a different switch when UP or DOWN:

Conservative when UP, less conservative when DOWN

You can also scale taking into account the bitrate (and its utility)

III. Improvements: scheduling (bonus)

Continuous & periodic download scheduling oscillation, over- or underused resources

Randomize target buffer level to avoid startup bias and increase stability.

Also extremely useful for promoting fairness!

Source: FESTIVE

Example 2: DASH.JSDash.js is the reference DASH player developed by DASH-IF.

https://github.com/Dash-Industry-Forum/dash.js/wiki

4 different rules:

2 Main:ThroughputRuleAbandonRequestsRule

2 secondary:BufferOccupancyRuleInsufficientBufferRule

Example 2: DASH.JS main rules

Source: DASH-IF, Maxdome

DASH.Js has 4 different Rules

ThroughputRulecalculates bandwidth with some smoothing!No real quantizing (have a real estimate and no other values)AbandonRequestsRulecancels if takes more than 1.5x of donwloadBufferOccupancyRuleto now go down if buffer large enough (RICH BUFFER TRESHOLD) InsufficientBufferRule au tas

Example 2: DASH.JS, sum-upSTRONG POINTSCOULD BE IMPROVEDSmoothes bandwidthNo quantization of bitratesSegment abort mechanism to avoid buffering during network dropsDoesnt handle CPU & Player size constraintsRich buffer threshold to avoid BW oscillations

Example 2: DASH.JS how to improveTweak the Parameters

ThroughputRule:

AVERAGE_THROUGHPUT_SAMPLE_AMOUNT_LIVE = 2;AVERAGE_THROUGHPUT_SAMPLE_AMOUNT_VOD = 3;

AbandonRequestRule:

GRACE_TIME_THRESHOLD = 500;ABANDON_MULTIPLIER = 1.5;

2. Write your own rules

https://github.com/Dash-Industry-Forum/dash.js/wiki/Migration-2.0#extending-dashjshttps://github.com/Dash-Industry-Forum/dash.js/blob/development/src/streaming/rules/abr/ABRRulesCollection.js

BufferOccupancyRule:

RICH_BUFFER_THRESHOLD = 20

You can easily take the best out of hls.js here! Write a player size rule, a FPS drop rule change the Abandonrate rule!Its all very easy to do!

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

BOLA stuff ? The approach is quite difficult to explain based on utility theory, and supposed to be a lot more efficient because there are no need to estimate the bandiwdth.BUTNot fully implemented in dash.js, and there are some optimisation constants that depend a lot on the use-case (target buffer, live, vod)Today not working great for small segment sizes AND small buffer size ( but good for 1+ min apparently?)Still work in progress, but an interesting approach!

IV. Going further: test and iterate!Tweaking algorithms is easy, creating your forks too.

Youve 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

Significant improvements without even changing your workflow!

We can give a lot of tips, but most of the use-cases are spcific (segment size, playlist size, latency and also which parameter is most important to you (buffer rate? Best bitrate ? Best bitrate no so useful if you KNOW that most of your user have a better bandwidth anyway? Number of switches)So whats important is to have a way to iterate and improve ?The best is to have AB testing on 50/50 of population, to be able to quickly see results and compare them! What happens if you just tweak one parameter ? The results can be quite stunning!

QUESTIONS?

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.

Contact us at:

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

We can give a lot of tips, but most of the use-cases are spcific (segment size, playlist size, latency and also which parameter is most important to you (buffer rate? Best bitrate ? Best bitrate no so useful if you KNOW that most of your user have a better bandwidth anyway? Number of switches)So whats important is to have a way to iterate and improve ?The best is to have AB testing on 50/50 of population, to be able to quickly see results and compare them! What happens if you just tweak one parameter ? The results can be quite stunning!