Better spec compliance regarding playlist update timing

This commit is contained in:
reusedname 2025-03-01 15:28:55 +05:00
parent 96bfd4e027
commit eca4245836
1 changed files with 12 additions and 3 deletions

View File

@ -122,7 +122,11 @@ public abstract class AbstractHlsDownload extends AbstractDownload {
handleMissedSegments(segmentPlaylist, nextSegmentNumber);
enqueueNewSegments(segmentPlaylist, nextSegmentNumber);
splitRecordingIfNecessary();
calculateRescheduleTime();
// by the spec we must wait `targetDuration` before next playlist request if there are changes
// if there are none - half that amount
calculateRescheduleTime(playlistChanged(segmentPlaylist, nextSegmentNumber)
? segmentPlaylist.targetDuration*1000
: segmentPlaylist.targetDuration*500);
processFinishedSegments();
// this if-check makes sure, that we don't decrease nextSegment. for some reason
@ -175,6 +179,11 @@ public abstract class AbstractHlsDownload extends AbstractDownload {
return this;
}
private boolean playlistChanged(SegmentPlaylist segmentPlaylist, int nextSegmentNumber) {
return segmentPlaylist.seq + segmentPlaylist.segments.size() > nextSegmentNumber;
}
protected void processFinishedSegments() {
downloadExecutor.submit(() -> {
@ -427,8 +436,8 @@ public abstract class AbstractHlsDownload extends AbstractDownload {
return new SegmentDownload(model, playlist, segment, client, targetStream);
}
private void calculateRescheduleTime() {
rescheduleTime = beforeLastPlaylistRequest.plusMillis(1000);
private void calculateRescheduleTime(float duration_ms) {
rescheduleTime = beforeLastPlaylistRequest.plusMillis(Math.max((int)Math.ceil(duration_ms), 250));
if (Instant.now().isAfter(rescheduleTime))
rescheduleTime = Instant.now();
recordingEvents.add(RecordingEvent.of("next playlist download scheduled for " + rescheduleTime.toString()));