Loading all fragments in a level at the same time

[fegauthier]

Is your feature request related to a problem? Please describe.

A problem that I have with some streams is that it needs like 13-14 seconds to load a 10 seconds fragment. Obviously, it will provoke some lags even with a buffer.

There is the live stream m3u8 generated by the stream server

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:5886
#EXT-X-ALLOW-CACHE:YES
#EXT-X-TARGETDURATION:11
#EXTINF:10.010000,
/hls/b5b33f1249776fefb30b1f80cc77e398/45598_5886.ts
#EXTINF:10.010000,
/hls/a83b9bf98417d74f63a8594ee2713b5d/45598_5887.ts
#EXTINF:10.010000,
/hls/fab85cd89162d44d1da2ed37fc10eb35/45598_5888.ts
#EXTINF:10.010000,
/hls/c9cea979e7df10b79e1ba63cce51a025/45598_5889.ts
#EXTINF:10.010000,
/hls/2419cc43c287bf2c9e6524a74ca4e18d/45598_5890.ts
#EXTINF:10.010000,
/hls/4ffd555ddf12fbff4e01a746a2f5bbba/45598_5891.ts

Levels includes always 6 fragments of about 10 seconds each.

Describe the solution you'd like

A solution that can solve this issue is of course ask the server provider to increase bandwidth speed to get fragments faster. In my case, it's not very possible to do that. Another solution that I thought was implementing concurrent fragment loading. When m3u8 playlist is reloaded, the Stream Controller should download all fragments at the same time. Instead of getting 13-14 seconds to get 10 seconds fragment, it will take 13-14 seconds to get 60 seconds.

I'm looking at the code right now to see if this change "is a big change" for the hls.js code. I think it could be a big improvement for HLS.JS to implement that.

If anybody has some ideas about implementing that, it would be appreciated.

Thanks!

Additional context

No response

[fegauthier]

I created an experimental PR that enable parallel fragments fetching.

https://github.com/video-dev/hls.js/pull/5291

[robwalch]

Hi @fegauthier,

This is not a feature we're interested in supporting. It could have many side-effects, the main issue being that it would impact bandwidth measurement, ABR, and abort loading checks in unpredictable ways.

If you would like to load the segments in the playlist prior to HLS.js requesting them, you can outside the player (hls.levels[].details.fragments contains the parsed Playlist segment data including their URIs), and implement a custom loader to use the data or external loaders, once HLS.js instantiates your custom loader internally.

[ringus1]

@robwalch Such a pity. Library is used throughout multiple big projects and sometimes playlists even have no VBR to choose from, therefore bandwidth measurement is pointless in these scenarios regardless.

It would be desirable to have this standarised as an option for developers without the need to maintain multiple different implementations of the same thing that seems to be recurring requested feature.

Also, please see how major CDNs/VOD providers are making use of such parallelism to increase stability of the connection and saturate it to the best extent. That's quite important especially for mobile networks, where lagging might be substantial and asking simply one by one, might results in what OP is describing.

Please please reconsider.

[robwalch]

Closing as this is not something we would consider in its current form.