Hls.js: Bandwidth significantly underestimated during startup

[brandonkal]

What version of Hls.js are you using?

0.12.3

What browser and OS are you using?

Chrome/FF

Test stream:

The same stream used here: #2099

Checklist

• [x] The issue observed is not already reported by searching on Github under https://github.com/video-dev/hls.js/issues
• [x] The issue occurs in the stable client on https://hls-js.netlify.com/demo and not just on my page
  
• [x] The issue occurs in the latest client on https://hls-js-latest.netlify.com/demo and not just on my page
  
• [x] The stream has correct Access-Control-Allow-Origin headers (CORS)
• [x] There are no network errors such as 404s in the browser console when trying to play the stream

Steps to reproduce

1. Please provide clear steps to reproduce your problem
   Start the stream and monitor bandwidth estimation. During first 20 seconds, the bandwidth estimation ramps up from zero. But it takes 20 seconds for it to stabilize and become reasonable.

The end result is that the defaultEstimate value is completely ignored due to the very low minimum weight. Even when setting a start level, such as 2, the low estimate causes the second fragment to always switch down to level 0, which causes the buffer to quickly fill with low quality segments.

https://github.com/video-dev/hls.js/blob/fe276d938a31be0c48f18bb3935611dfafde8702/src/utils/ewma-bandwidth-estimator.js#L14-L15

Other Observations

1. abrMaxWithRealBitrate is only effective if the calculated real bitrate is greater than the manifest bitrate due to the use of Math.max(). This is not mentioned in the API docs and does not seem desirable. For instance, this stream only reports max bitrate for the VBR encoding which is about 1.2x the average bitrate. This means abrBandWidthUpFactor and abrBandWidthFactor must be set at 1.2 for a reasonable aggressiveness. However, because these scalars are also used to reduce oscillations, doing so also increases oscillations between 1500k and 2200k. But lowering these numbers causes hls.js to never switch up to 1500k because of the underestimate and the conservative factor. These scalars also have no effect on the bandwidth used in the abandon rules watchdog whcih has a hardcoded safety margin.
   https://github.com/video-dev/hls.js/blob/fe276d938a31be0c48f18bb3935611dfafde8702/src/controller/abr-controller.js#L122-L126

2. minAutoBitrate doesn't appear to be adjustable after initialization.

3. abrEwma* default values in the API docs do not match the default values in the code.
4. The emergency switchdown appears to flush the buffer during startup even when the loaded fragment levels are greater than 0.
5. maxBufferLength is not descriptive of what the parameter really does. Fragments still download even when the buffer is greater. targetBufferLength or minBufferLength would be less confusing.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[brandonkal]

still an issue

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[brandonkal]

still an issue

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[brandonkal]

These bots are really user hostile...

[brandonkal]

@johnBartos Please mark this as confirmed so I don't have to fight this hostile bot. Not sure how the age of an issue makes it no longer valid.

[itsjamie]

@brandonkal what's your expectation on how much trust should be placed in the starting bitrate for the initial weighting? For example, if you provided a starting estimate of 4000kbps, would you want the ABR algorithm to prioritize playing at the maximal quality of what's possible for that connection and not build a forward buffer to survive network hiccups? Or, would you want the algorithm to include buffer size in its calculation?

My concern is that the current situation takes advantage of the fact that the weight does take time to become accurate, therefore the buffer size has time to build before the controller switches up. If we were to simply increase the weight of the default, we would effectively increase the chance for buffer stalls as there would be a smaller forward buffer.

Another common issue to avoid is when people move from different networks on the same devices, so the available APIs that store past historic data oftentimes lead to high buffer rates at the beginning of streams for these users as they switch to worse networks.

Some more expectations of behaviour will help make this actionable. Thank you!

[carloscarnero]

Some more expectations of behaviour will help make this actionable. Thank you!

In addition to what @brandonkal has commented above, the following is something I'm trying to achieve but haven't been able to:

1. The user plays a source, and ABR works its magic as expected.
2. Client-side, every couple of seconds, I get the current bandwidth estimate from the player. I store that value client-side in local storage, with the expectation that if...
3. The user plays another different source, probably in quick succession, ABR will work its magic but this time "seeded" with the estimated bandwidth stored in its local storage.

Of course, I wouldn't want to disable the estimator at all, just that it could take into account previous knowledge (if available.) Granted, this works best when the network is stable, but modifying a priori the initial estimate could be taken into account.

[brandonkal]

Building a buffer at the start is a priority but ideally I'd like the expected buffer size to ramp up slowly. So a delayed priority. I would consider a freeze at second two a fine risk over starting every video at quality zero for the first 20 seconds.

I would like the starting estimate to be respected and it shouldn't be abandoned at chunk two because there is no initial buffer.

It is true the estimate could be innacurate. With past video play data I can provide a reasonable initial bandwidth, but as it is now, there seems little reason to provide that input.

[robwalch]

One way this could be resolved is with #2754