Schedule level reload sooner if only 1 fragment in level

[flagoworld]

This PR will...

Schedule a level reload sooner than fragment duration if there is only 1 fragment in the playlist

Why is this Pull Request needed?

If the server is adding to a playlist, but there is only 1 fragment so far at the time of the playlist being loaded, the level will not be reloaded before playback reaches the end of the first fragment and a stall is encountered. This stall leads to a hiccup in audio/video as the player recovers by reloading the level and subsequent fragments.

Are there any points in the code the reviewer needs to double check?

Is this the right place to put this logic?

[robwalch]

Can you expand more on the use-case where there is only one segment in the live playlist? Standard practice is at least three.

[flagoworld]

The server starts transcoding the media on demand when the playlist is requested and I want playback to start as soon as the first fragment is ready.

This is an “EVENT” type playlist and and END-LIST tag gets appended when transcoding is done.

[robwalch]

Have you considered using HLS server control and blocking reload to provide playlist updates as they become available?

I appreciate the contribution, but since this only benefits the edge case of playlists that grown at faster than normal playback, I don't think it belongs in the standard library.

This is an “EVENT” type playlist and an END-LIST tag gets appended when transcoding is done.

If you could add an Expires header to the response to hint that an update is expected, maybe there's a way to extend the changes for #7082 to also resolve this issue.

[xtne6f]

Not sure if this is related to this pr, but since commit 88be7874198d146c71600cc594360d064ad308bb, the interval between initial playlist reloads has been doubled. Specifically, when hls.js first loads a playlist like this:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PLAYLIST-TYPE:EVENT
#EXTINF:6.000000,
main0.ts

According to the annotation #EXTINF:6.000000,, hls.js is expected to access the playlist again around 6 seconds, but it accesses the playlist around 6+6=12 seconds. This seems to be because handleTrackOrLevelPlaylist() (playlist-loader.ts) and playlistLoaded() (base-playlist-controller.ts) are adding the result of computeReloadInterval() to details.requestScheduled twice. However, I don't know if this is exactly the HLS specification or a bug, and how specifically to fix it.

[robwalch]

Not sure if this is related to this pr, but since commit 88be7874198d146c71600cc594360d064ad308bb, the interval between initial playlist reloads has been doubled.

Specifically, when hls.js first loads a playlist like this:

@xtne6f - Please file a new Bug Report.

[robwalch]

@flagoworld adding a note from #7556:

Set initialLiveManifestSize to 3 to prevent startup with smaller playlists.

For your unique use-case, this would prevent the stall, but make startup take longer. That startup could then be shortened using the start/stop and schedule override shared above (https://github.com/video-dev/hls.js/pull/7453#pullrequestreview-3094729092).