ABR Algorithms Explained (from Streaming Media East 2016)

Editor's Notes

• #11: Explain what HLS.js is. Also say it’s quite simple to extend, as the different controllers are actually option parameters, and so can be easily replaced.
• #12: Checks the max CapLevel corresponding to current player size Every 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)
• #13: Calculates the dropped frames per second ratio. If it is > 0.2, bans the level for ever => goes into restricated levels Not activated in production! fpsDroppedMonitoringThreshold fpsDroppedMonitoringPeriod
• #14: 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 don’t wait for the other levels to have been loaded
• #15: Simple algorithm,
• #16: Here talk about Streamroot, and the fact having the sources from different buffers is even more difficult! Code from us?x Basically a onProgress & bandwidth estimation too (coming from CDN & P2P network!) Request.onProgress Request.onLoad => classic estimation With P2P estimation! Don’t wanna infinite speed, and thus includes a P2P bandwidth metric. Not the same for different peers, so averaged and smoothed Code from us?x Basically a onProgress & bandwidth estimation too (coming from CDN & P2P network!) Shema => a P2P cache and a CDN buffer => and time = 0
• #17: One of the most important ones here What 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?
• #18: Pros: Simple implementation, taking into account a lot of different params Works 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 device’s available bandwidth, for several reasons: You can have very quick bandwidth changes, especially on a mobile network, as well as unexpected bandwidth drops The requests can be living in parallel with other TCP request (HTTP or any other on the user’s device) This can lead to frequent estimation oscillations!
• #19: The different static constants more for you use-case? You can play with them You can also easily build your own rule! Here is an example on Github? First explain how to do that?
• #20: difficult to correlate a unique segment download time to the real device’s available bandwidth, for several reasons: You can have very quick bandwidth changes, especially on a mobile network, as well as unexpected bandwidth drops The requests can be living in parallel with other TCP request (HTTP or any other on the user’s device) This can lead to frequent estimation oscillations!
• #21: difficult to correlate a unique segment download time to the real device’s available bandwidth, for several reasons: You can have very quick bandwidth changes, especially on a mobile network, as well as unexpected bandwidth drops The requests can be living in parallel with other TCP request (HTTP or any other on the user’s device) This can lead to frequent estimation oscillations!
• #23: 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 it’s utility)
• #26: DASH.Js has 4 different Rules ThroughputRule  calculates bandwidth with some smoothing! No real quantizing (have a real estimate and no other values) AbandonRequestsRule  cancels if takes more than 1.5x of donwload  BufferOccupancyRule to now go down if buffer large enough (RICH BUFFER TRESHOLD) InsufficientBufferRule  au tas
• #28: You can easily take the best out of hls.js here! Write a player size rule, a FPS drop rule… change the Abandonrate rule! It’s all very easy to do!
• #29: 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. BUT Not 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!
• #30: 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 what’s 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!
• #32: 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 what’s 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!