abr-controller stops sampling throughput at download boundaries

[InanisV]

What version of Hls.js are you using?

v1.0.0 and v1.0.1

What browser and OS (including versions) are you using?

Google Chrome 89.0.4389.114
macOS 10.15.6

Test stream:

BBB: https://test-streams.mux.dev/x36xhzz/x36xhzz.m3u8
Akamai: https://ll-hls-test-apple.akamaized.net/cmaf/master.m3u8

Configuration:

const hlsjsDefaults = {
  debug: true,
  enableWorker: true,
  lowLatencyMode: true,
  progressive: true,
  testBandwidth: true,
  capLevelOnFPSDrop: true,
  maxLiveSyncPlaybackRate: 1.3,
  backBufferLength: 60 * 1.5,
};

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. Just play the video with test stream

Expected behavior

In abr-controller, each time Events.FRAG_BUFFERED is triggered, the onFragBuffered function should sample and update throughput by calling this.bwEstimator.sample.

Actual behavior

Most time Events.FRAG_BUFFERED is triggered, the onFragBuffered function directly returns due to stats.aborted == True.

Temporary Solution

I used v1.0.0-rc.4 before and it works well.
So I compared all files manipulating flag stats.aborted with those from rc.4.
Then I found that this bug can be solved by removing line 265 loader.destroy(); in src/loader/fragment-loader.ts.

[robwalch]

Does this issue only present when progressive: true, is enabled?

[robwalch]

Akamai: https://ll-hls-test-apple.akamaized.net/cmaf/master.m3u8

You absolutely should not enable progressive with LL-HLS streams. Note that this option is labeled "experimental" in the release notes. That means it is not intended for production. It also is counterintuitive to the design of LL-HLS, as it was meant to be enabled for HTTP chunked transfer encoding (CTE) streams, not LL-HLS streams which take advantage of CDN caching and delivery of assets at line speed, not encoding speed.

[robwalch]

Does this issue only present when progressive: true, is enabled?

Reproduced the issue and can see that this is an issue with the fetch loader which is selected by default when progressive is set to true. The bug however impacts the fetch loader either way, as the stats for all destroyed loaders get marked as aborted even after they retrieved a response successfully.

[InanisV]

Akamai: https://ll-hls-test-apple.akamaized.net/cmaf/master.m3u8

You absolutely should not enable progressive with LL-HLS streams. Note that this option is labeled "experimental" in the release notes. That means it is not intended for production. It also is counterintuitive to the design of LL-HLS, as it was meant to be enabled for HTTP chunked transfer encoding (CTE) streams, not LL-HLS streams which take advantage of CDN caching and delivery of assets at line speed, not encoding speed.

Hi Rob,

Thank you for the explanation. It really helps. :)