Skip to content

Schedule level reload sooner if only 1 fragment in level #7453

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Schedule level reload sooner if only 1 fragment in level #7453

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions src/utils/level-helper.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -518,6 +518,14 @@ export function computeReloadInterval(
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',
);
}
Comment on lines 518 to +528
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.

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

@flagoworld flagoworld Aug 7, 2025

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

@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.

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

Copy link
Author

@flagoworld flagoworld Aug 7, 2025

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 •
edited
Loading

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.

} else {
// estimate = 'miss half average';
// follow HLS Spec, If the client reloads a Playlist file and finds that it has not
Expand Down
Loading