Skip to content

fix: Improve boundary gap mitigation at DASH period transitions #8344

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.

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

Merged
merged 12 commits into from
Mar 28, 2025

Conversation

matvp91
Copy link
Member

@matvp91 matvp91 commented Mar 26, 2025

With resetting MSE on boundary crossing, we might seek into a gap. This would cause MSE not to reset properly, and playback will stall. The following changes are made:

  • We rely on seeking to check if we need to start the boundary timer. The timer assumes we will cross a boundary in a short period of time, and is built to handle edge cases like misalignment & subtle gaps. We first relied on seeked but that event might never come when MSE does not reset. Thus seeking into a gap near a boundary end would have never spawned the timer in the first place, leaving the player endlessly stalling.
  • When crossing a boundary, the MSE resets but never completes (as explained earlier). In this case, the timer will advance the playhead. However, due to the incomplete MSE reset, the video element remains paused. Since the previous state was paused, playback does not resume automatically after crossing the boundary. I now keep a variable that indicates we need to resume playback when MSE reset completes.

Reproduce:

  • Load example
  • Use streaming.crossBoundaryStrategy set to RESET or RESET_TO_ENCRYPTED.
  • Seek to 1000 (this would cross the boundary at 888.015)
  • Seek back to 888 (which is 0.015s from the boundary end)

@matvp91 matvp91 marked this pull request as draft March 26, 2025 16:33
@matvp91 matvp91 changed the title feat: Improve boundary gap mitigation at DASH period transitions fix: Improve boundary gap mitigation at DASH period transitions Mar 26, 2025
@avelad avelad added type: bug Something isn't working correctly priority: P1 Big impact or workaround impractical; resolve before feature release labels Mar 26, 2025
@avelad avelad added this to the v4.15 milestone Mar 26, 2025
@shaka-bot
Copy link
Collaborator

Incremental code coverage: 100.00%

@matvp91 matvp91 requested a review from avelad March 26, 2025 19:54
@avelad
Copy link
Member

avelad commented Mar 26, 2025

@matvp91 is it ready to review? If yes, please, switch draft to ready!

@matvp91 matvp91 marked this pull request as ready for review March 26, 2025 19:59
@avelad
Copy link
Member

avelad commented Mar 27, 2025

@shaka-bot test

@shaka-bot
Copy link
Collaborator

@avelad: Lab tests started with arguments:

  • pr=8344

@avelad
Copy link
Member

avelad commented Mar 27, 2025

@shaka-bot test

@shaka-bot
Copy link
Collaborator

@avelad: Lab tests started with arguments:

  • pr=8344

@avelad avelad merged commit c46963f into shaka-project:main Mar 28, 2025
44 of 47 checks passed
avelad pushed a commit that referenced this pull request Mar 31, 2025
With resetting MSE on boundary crossing, we might seek into a gap. This
would cause MSE not to reset properly, and playback will stall. The
following changes are made:

- We rely on `seeking` to check if we need to start the boundary timer.
The timer assumes we will cross a boundary in a short period of time,
and is built to handle edge cases like misalignment & subtle gaps. We
first relied on `seeked` but that event might never come when MSE does
not reset. Thus seeking into a gap near a boundary end would have never
spawned the timer in the first place, leaving the player endlessly
stalling.
- When crossing a boundary, the MSE resets but never completes (as
explained earlier). In this case, the timer will advance the playhead.
However, due to the incomplete MSE reset, the video element remains
paused. Since the previous state was paused, playback does not resume
automatically after crossing the boundary. I now keep a variable that
indicates we need to resume playback when MSE reset completes.
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label May 27, 2025
@shaka-project shaka-project locked as resolved and limited conversation to collaborators May 27, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
priority: P1 Big impact or workaround impractical; resolve before feature release status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants