Skip to content
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

Jump to bottom

Update fragPrevious when attempting to load an already-buffered fragment #5013

Merged
merged 2 commits into from
Nov 10, 2022
Merged

Update fragPrevious when attempting to load an already-buffered fragment #5013

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
bc44030
Update fragPrevious when attempting to load an already-buffered fragment
Nov 7, 2022
bdd9f0d
Move already buffered fragment logic to base-stream-controller
Nov 10, 2022
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
6 changes: 6 additions & 0 deletions src/controller/stream-controller.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -351,6 +351,12 @@ export default class StreamController
} else if (this.media?.buffered.length === 0) {
// Stop gap for bad tracker / buffer flush behavior
this.fragmentTracker.removeAllFragments();
} else if (fragState === FragmentState.OK) {
// Move fragPrevious forward to support forcing the next fragment to load
// when the buffer catches up to a previously buffered range.
if (frag.sn !== 'initSegment') {
this.fragPrevious = frag;
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

Makes sense. Wondering if this can happen in getFragmentAtPosition so that we pick the right fragment on the first pass rather than (assuming) on the next tick.

Copy link
Collaborator

@robwalch robwalch Nov 9, 2022 •
edited
Loading

Choose a reason for hiding this comment

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

That would also move this fix to base-stream-controller so that it addresses the same lookup issue in audio playlists.

Copy link
Collaborator

@robwalch robwalch Nov 9, 2022 •
edited
Loading

Choose a reason for hiding this comment

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

If you add this to getFragmentAtPosition in base-stream-controller then it happens in place and doesn't modify the fragPrevious property (in this case I just did let { fragPrevious } = this;. I prefer that since other parts of the code we are not thinking of may depend on this.fragPrevious not being updated in this way.

   if (frag) {
      const curSNIdx = frag.sn - levelDetails.startSN;
      // Move fragPrevious forward to support forcing the next fragment to load
      // when the buffer catches up to a previously buffered range.
      if (this.fragmentTracker.getState(frag) === FragmentState.OK) {
        fragPrevious = frag;
      }
      if (fragPrevious && frag.sn === fragPrevious.sn && !loadingParts) {
        // Force the next fragment to load if the previous one was already selected. This can occasionally happen with
        // non-uniform fragment durations

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the feedback! That makes a ton of sense and seemingly reduces the risk of my change (one of my worries of the original change not having a ton of exposure to the codebase.)

I've added the changes you proposed. Let me know if there's anything else I can do to help get this change in place.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Thank you! Great catch and fix.

}
}

Expand Down