BW estimator is sometimes called with missing stats for LL-HLS

[kanongil]

There is a problem with the consistency of the bandwidth reporting.

The issue seems to be related to level switches (maybe due to aborts??).

What version of Hls.js are you using?

1.0.0-rc3

What browser and OS are you using?

macOS Chrome

Test stream:

https://stream.sob.m-dn.net/live/sb1-ll/index.m3u8

Checklist

• The issue observed is not already reported by searching on Github under https://github.com/video-dev/hls.js/issues
• The issue occurs in the stable client on https://hls-js.netlify.com/demo and not just on my page

• The issue occurs in the latest client on https://hls-js-dev.netlify.com/demo and not just on my page

• 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

Steps to reproduce

1. Observe numBytes value passed to estimator here:

   hls.js/src/utils/ewma-bandwidth-estimator.ts

   Line 36 in f3e2e99

   sample(durationMs: number, numBytes: number) {

2. Play stream
3. Force level switch a few times

Expected behavior

All passed sample contain actual data, and not zeroes.

Actual behavior

Sometimes samples contain numBytes = 0 and seriously wrong durationMs (ex. 629418.165).

Example of a LoadStats used to compute the supplied values:

[kanongil]

This is still an issue in RC4. I suspect it is related to the parser blocking here:

hls.js/src/controller/buffer-controller.ts

Line 472 in 9e13e30

this.hls.trigger(Events.FRAG_BUFFERED, {

If you look at the traffic, you will see that ABR controller onFragParsed is not triggered for all transfers when performing a LL-HLS switch to a non-indendent part. If this is by design (which I suspect it is), a fix could be to move the logic back to the more direct onFragLoaded event (and use stats.loading.end instead of stats.parsing.end to compute the transfer duration).

It is unclear what the reasoning was to include the parsing time, from the original commit.

[robwalch]

@kanongil let me know if you are still seeing this in the latest release. I have not been able to reproduce this recently.

Adding a console.assert to the code in question may help me encounter the problem during development, and would be a welcome contribution.