Skip to content

Conversation

flagoworld
Copy link

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
Copy link
Collaborator

robwalch commented Aug 7, 2025

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
Copy link
Author

flagoworld commented Aug 7, 2025

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.

Copy link
Collaborator

@robwalch robwalch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Playback should not be started if there is only one segment. Increasing the rate under these circumstances does not meet the requirements of the HLS spec.

To force a reload of the playlist, try modifying Level.details.requestScheduled and toggling loading off and on:

hls.levels[hls.loadLevel].details.requestScheduled = 0;
hls.stopLoad();
hls.startLoad();

Comment on lines 518 to +528
reloadInterval = lastSegmentDuration;
}
}

// If only 1 fragment, make sure to reload well before it ends to avoid race condition stall
if (fragments.length == 1) {
reloadInterval = (fragments[0].duration * 1000) / 2;
logger.log(
'computeReloadInterval found only 1 fragment, using duration / 2',
);
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't this work in the block above? (4x segment duration is > distance to end of one segment.)

Suggested change
reloadInterval = lastSegmentDuration;
}
}
// If only 1 fragment, make sure to reload well before it ends to avoid race condition stall
if (fragments.length == 1) {
reloadInterval = (fragments[0].duration * 1000) / 2;
logger.log(
'computeReloadInterval found only 1 fragment, using duration / 2',
);
}
reloadInterval = lastSegmentDuration;
}
// If only 1 fragment, make sure to reload well before it ends to avoid race condition stall
if (fragments.length == 1) {
reloadInterval /= 2;
}
}

The problem with this whole idea is that if you only ever serve one segment, the server will keep getting hit at twice the rate of normal.

My suggestion would be to not even start playback until there are three segments present.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that even possible? Wouldn’t the END-LIST tag be present if there were only 1 and it would never try to load more?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Serving a static playlist with no end list is pretty simple. Static playlists should have one.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not debating/arguing, but looking to understand the spec better, so please be patient with me:

I skimmed over the spec and I am not seeing anything about minimum 3 fragments. Can you point me to where it discusses that?

Looking at the spec, it says:
If the Media Playlist contains the final Media Segment of the presentation, then the Playlist file MUST contain the EXT-X-ENDLIST tag; this allows clients to minimize unproductive Playlist reloads.

If we check for the EXT--X-PLAYLIST-TYPE == EVENT, we can then determine if we even need to schedule a reload at all, right, so this would prevent any kind of infinite reload condition there. END-LIST is REQUIRED for EVENT playlists.

How would requesting an update sooner when there is only 1 fragment lead to more updates than requesting it near the end if there is still only 1 update scheduled during the playback of that fragment? Actually, come to think of it, the goal is to make sure to do an update well before the playing fragment ends if the playing fragment is the last fragment. Would it make sense to change the logic as such? Not even sure at a glance if that information is available in this scope, but I think it would fix the issue without breaking anything? An honestly that logic may be better up in the level-controller as well?:
If playing last fragment, reloadInterval /= 2.

Copy link
Collaborator

@robwalch robwalch Aug 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have a look at the sections that cover HOLD-BACK and "three Target Durations" and "three times the Target Duration". I'm sure that if you are encoding a playlist, the rate of growth of the playlist will be greater than 1x, but this is a special case. You should delay the start of playback rather than increase the rate of playlist polling.

Cutting the reload interval is not something I am willing to do. In case of a miss (no update after refresh) then the next refresh should should wait another target duration (not half), but that wouldn't be the case with this change. The likeliness of a stall in most cases (where the playlist grows at a rate of 1x) are still very high.

Arbitrarily cutting the reload in half when there is an eminent stall deadline is not ideal. This is a special app case that should be handled by the app, based on distance to the edge: reload before hls.latency seconds when there is one segment and hls.latestLevelDetails.live.

@robwalch
Copy link
Collaborator

robwalch commented Aug 12, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants