Player runs out of buffer easily when challenged with deteriorated network conditions

[hariszukanovic]

Environment

• The MPD passes the DASH-IF Conformance Tool on https://conformance.dashif.org/
• The stream has correct Access-Control-Allow-Origin headers (CORS)
• There are no network errors such as 404s in the browser console when trying to play the stream
• The issue observed is not mentioned on https://github.com/Dash-Industry-Forum/dash.js/wiki/FAQ
• The issue occurs in the latest reference client on http://reference.dashif.org/dash.js/ and not just on my page

• Dash.js version:4.4.1 (latest)
• Browser name/version: Chrome Version 103.0.5060.134 (Official Build) (64-bit)
• OS name/version: Linux Ubuntu 21.10

Steps to reproduce

1. Please provide clear steps to reproduce your problem
   Using default settings in the reference player and bandwidth throttling option in Chrome developer tools. Please look at the video here https://drive.google.com/file/d/1csqC2VfZhwsKsm-oInMINNVbBCnp-E9s/view

2. If the bug is intermittent, give a rough frequency if possible
   Always reproducible

Observed behavior

All is recorded in the attached video url...
https://drive.google.com/file/d/1csqC2VfZhwsKsm-oInMINNVbBCnp-E9s/view

I will try to also describe:

The manifest contains a low-quality 500k video bitrate.
The network connection is "very good".. around 50Mbit/s and the player starts with playing the 5Mbit variant.
I set the bandwidth throttling to 3 Mbit in Chrome developer tools and can verify that fetching the next chunk takes much much longer time, around 20 seconds.
After this chunk, the player continues to dowload&play the 5 Mbit variant, even though the last one took 20s to download and the buffer has just a bit over 20s in it... I think risky, but ok... perhaps betting on network condition improvement in the meantime...
So, the next chunk again takes around 20s to complete, because the network conditions have not changed... after which the player, with less than 10s in the buffer... switches to try the next lower bitrate in the list... which is 3,8Mbit... while there are lower bitrates also avalable in the manifest?
To me, already at this point, it looks pretty clear and quite certain that the buffer is going to get empty.

I tried with other ABR strategies, but the result is similar and the player seems to make pretty weird decisions about when to switch and which variant to switch to... very often running out of the buffer.

Console output

https://drive.google.com/file/d/1csqC2VfZhwsKsm-oInMINNVbBCnp-E9s/view

Expected behavior

The player should realize the network conditions have changed and switched to the appropriate video variant before it is too late.
In this concrete case, if the download speed was 3Mbit (even a bit less!), lasting for 20 seconds (1st chunk download). Already at this point, I would consider the network conditions to have deteriorated so much that I would switch immediately to a lower bitrate (the drop in download speed is really huge).
After the whole 40 seconds of having had the 3Mbit download speed, I would certainly not choose to switch to a 3,8 Mbit variant since there are 2 other lower bitrate variants there... 1,8Mbit and 500k

Besides all the advanced algorithms that dashjs has and implements, this case seems like something that is a basic case for which the ABR algorithm to a human eye seems to be obviously failing...

In my experience, this kind of network condition can be found very often when using WiFi connections.

Perhaps the defaults are not as safe and conservative as I imagine an ABR player should be, since I belive that is its primary task is to try and not get interrupted while playing.
Perhaps I can configure the player to make other/better decisions about switching bitrates?

[hariszukanovic]

Anyone seen this kind of issue?

[dsilhavy]

@hariszukanovic I saw similar behavior and started refactoring and reworking the ABR and throughput logic in #3776 . This is ongoing work and will take more time though

[hariszukanovic]

@dsilhavy
Thanx for your response!

I did more testing and I noticed also:
when the player sometimes does manage to switch to an adequate lower bit-rate in time. However, it often remains in a state of nearly empty buffer and literally stops trying to fill the buffer up again to recover the buffer fully and even in such a state it sometimes tries to switch up to a higher bitrate which again very easily brings the buffer to 0.

Also, I tried several older dash.js versions (4.x.x, 3.x, 2.x) and all of them seem to react to ABR in different peculiar ways that do seem quite illogical to a human eye.. so, I suppose the ABR and throughput logic has had its shortcomings for some time now..

Anyway, it's good to know I am not seeing ghosts...
ABR, being a fundamental feature of adaptive streaming protocols, actually made it hard for me to believe I reproduced this kind of problem so easily.

It is great the work on this is ongoing and I hope it is now getting the due attention and priority to get fixed in the sea of advanced features this player has...
Let me know if I can help somehow.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. However, it might still be relevant so please leave a short comment if it should remain open. Otherwise the issue will be closed automatically after two weeks. Thank you for your contributions.

[dsilhavy]

unstale

[markriley9999]

Hi

I'm just wondering if this is still an issue, as I'm seeing the same behaviour as described above (using v4.7.0).

If I artificially throttle the network, I see that the rep selection algorithm sometimes does 'too little, too late' - even with incremental throttling.
However, what is more perplexing is sometimes even in the event of successfully selecting a sustainable bitrate - the rep selection alg will suddenly choose a much higher rep than expected and consequently empty the buffer. Or sometimes, I see the buffer being held at an unnecessarily low level even though I know that at that chosen rep the buffer could easily fully recover to optimal levels again.

I have tried this with multiple streams from various dash packagers.

---

As a related aside, I have now forced the ARB strategy to use the 'Bola' alg, i.e., 'abrBola'.

Using this I see much more deterministic behaviour, ie:

1. the algorithm responds well to a sudden drop in network bandwidth, choosing an appropriate rep and settling on it
2. conversely, I also see a very good recovery when the network is opened back up again
3. however, in the restricted bandwidth state - whilst an appropriate rep is found and used - I see that the buffer size is 'held' at a sub optimal level (presumably a level associated to that bitrate).

I suspect point 3., based on my limited knowledge on how this strategy works, is an expected consequence of using this algorithm - which is why I suspect that dash.js, by default, dynamically switches between 2 strategies - but that is pure conjecture on my part, to get best of both worlds.

---

Anyway, it would be good know if my observations at the start of my thread are to be expected and if so, is looking at this on the development roadmap?
And/or has anyone else created a custom algorithm selection algorithm that I could try instead?

Please let me know if you need any additional information.
Best regards

[dsilhavy]

The ABR and throughput logic was refactored and enhanced as part of the work on v5, see https://github.com/orgs/Dash-Industry-Forum/projects/8/views/2 . Issue should be re-tested against v5, see current alpha version here: https://reference.dashif.org/dash.js/v5/samples/dash-if-reference-player/index.html

[dsilhavy]

Anyone had the chance to do some tests with https://reference.dashif.org/dash.js/v5/samples/dash-if-reference-player/index.html ?