Estimated bitrate detection with low video bitrate fragments and high latency

[pedro-pedrosa]

Some of my users have reported that on some of their videos the quality level starts at 432p for a few seconds even though it's set to start at 1080p, then later on it switches to 1080p. Today I've seen that on a particular video of mine where the first few seconds are black screen, the first couple fragments are really small, around 50kb each, and also that due to server geolocation and proxy reasons, the total time it takes for each of these fragments to load is around 600ms, mostly due to latency and not bandwidth.

If we take a naive bandwidth estimation approach, these loading times equate to around 660kbps, which is much lower than the average bandwidth declared in the m3u8 manifest for 1080p which is 5.6mbps, and so the player started loading the 432p steam instead, only to later switch back to 1080p once the bandwidth estimator picked up more reliable bandwidth readings from fragments with non-blank frames.

My question is, does the bandwidth estimator in ABR take latency into account? is this something we can provide as a parameter?

[robwalch]

Request roundtrip time or latency is estimated as Time To First Byte Hls.ttfbEstimate as of version 1.4. You can see "TTFB Estimate" on the "Buffer & Statistics" tab of the demo page.

You cannot provide a default latency estimate. You can however provide a default bandwidth estimate with abrEwmaDefaultEstimate. If not configured, HLS.js starts with a default of at least 500kbps up to whichever is lower: the first variant BANDWIDTH in the Multivariant Playlist or abrEwmaDefaultEstimateMax (5Mbps default).

[pedro-pedrosa]

thank you for the response. I am using version 1.3.1. was this not taken into account prior to 1.4? if not then I'll probably have to update