Closed adrums86 closed 4 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 86.33%. Comparing base (
28cb9fd
) to head (48551a6
).
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Good finding!
Description
Sometimes when we're switching timelines, we run into a situation where the buffer is starved due to the main or audio trying to switch to separate timelines.
shouldWaitForTimelineChange
is called when deciding whether to wait to load or append the current segment. The conditions for this to returnfalse
are:If we're calling from the audio segment loader, we need to wait for the main segment loader to change to the timeline the audio segment loader is trying to change to, before we allow further loads or appends for the audio segment loader.
// Main loader should wait for the audio loader if audio is not pending a timeline // change to the current timeline. // // Since the main loader is responsible for setting the timestamp offset for both // audio and video, the main loader must wait for audio to be about to change to its // timeline before setting the offset, otherwise, if audio is behind in loading, // segments from the previous timeline would be adjusted by the new timestamp offset. // // This requirement means that video will not cross a timeline until the audio is // about to cross to it, so that way audio and video will always cross the timeline // together. // // In addition to normal timeline changes, these rules also apply to the start of a // stream (going from a non-existent timeline, -1, to timeline 0). It's important // that these rules apply to the first timeline change because if they did not, it's // possible that the main loader will cross two timelines before the audio loader has // crossed one. Logic may be implemented to handle the startup as a special case, but // it's easier to simply treat all timeline changes the same. if (pendingAudioTimelineChange && pendingAudioTimelineChange.to === segmentTimeline) { return false; }
This causes the loader to get stuck waiting for the other loader to sync up for a timelineChange which never happens and eventually stalls playback.
Specific Changes proposed
Add checks in the loader to look for bad timeline changes, instances such as this where the loaders are both pending timeline changes to separate timelines and resetting the loader when those cases occur, in order to re-sync timelines and avoid a stall.
Requirements Checklist