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.

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

Seek nearest SYNC does not adjust stale playlists #10484

Closed
wants to merge 1 commit into from

Conversation

stevemayhew
Copy link
Contributor

getPlaylistSnapshot() can return a cached but potentially quite stale playlist
that may be unsuitable for resolving a seek position.

This change fixes a race conditon that can cause a failed attempt to resolve
a seek position with a stale playlist.

Pre-conditions for the race:

  • A is the cached snapshot from previous playback of playlist A
  • B is the selected playlist at time of the seek
  • * — is current playback position in period
  • QQQ — positions in A cannot be seek targets from B, they have rolled out from Timeline.Window
  • WWW — are positions in A that cannot be resolved in A, but would be in A`
+=================*==+
|       Period       |
+=================*==+

     +QQQ-------+
     |     A    |
     +QQQ-------+
         +-------WWW+
         |     B    |
         +-------WWW+

           seek and switch back to A occur here...

          +----------+
          |    A'    |
          +----------+

The seek request is issued with Timeline.Window from playlist B, yet the call to getAdjustedSeekPositionUs()
occurs:

  1. After the current track selection swithces back to A
  2. But before playlist snapshot A` is loaded, replacing the old A

The check is simple, does basic sanity check on targetPositionInPlaylistUs (that it
is < durationUs of the selected playlist). This covers the positions WWW.

// is non-empty, and the playlist is fresh enough that the period position falls in side of
// the playlist bound, so we can use segment start times as sync points.
//
// If (a) an adaptive quality switch occurs between the adjustment and the seek being
// performed, and (b) segment start times are not aligned across variants, it's possible that
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Add comment about position exceeds duration check, note track switch on seek is not really a rare condition. And the stale playlist issue happens for live if there are lots of ABR changes.

long startOfPlaylistInPeriodUs =
mediaPlaylist.startTimeUs - playlistTracker.getInitialStartTimeUs();
long relativePositionUs = positionUs - startOfPlaylistInPeriodUs;
int segmentIndex =
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Moved this up to allow early return style.

`getPlaylistSnapshot()` can return a cached but potentially quite stale playlist
that may be unsuitable for resolving a seek position.

This change fixes a race conditon that can cause a failed attempt to resolve
a seek position with a stale playlist.

Pre-conditions for the race:

* A is the cached snapshot from previous playback of playlist A
* B is the selected playlist at time of the seek
* \* &mdash; is current playback position in period
* QQQ &mdash; positions in A cannot be seek targets from B, they have rolled out from `Timeline.Window`
* WWW &mdash; are positions in A that cannot be resolved in A, but would be in A`

```
+=================*==+
|       Period       |
+=================*==+

     +QQQ-------+
     |     A    |
     +QQQ-------+
         +-------WWW+
         |     B    |
         +-------WWW+

           seek and switch back to A occur here...

          +----------+
          |    A'    |
          +----------+
```

The seek request is issued with `Timeline.Window` from playlist B, yet the call to `getAdjustedSeekPositionUs()`
occurs:

1. After the current track selection swithces back to A
2. But before playlist snapshot A` is loaded, replacing the old A

The check is simple, does basic sanity check on `targetPositionInPlaylistUs` (that it
is < durationUs of the selected playlist).  This covers the positions WWW.
stevemayhew referenced this pull request Jul 28, 2022
The comment "all should be same" is not correct,  it is extremely likely they will be the same but not assured.   In either case the seek position will work, it just may not land exactly on a sync point in every variant.
@icbaker icbaker requested a review from christosts August 1, 2022 09:46
@icbaker
Copy link
Collaborator

icbaker commented Apr 15, 2024

Closing all PRs on this deprecated project. We are now unable to merge PRs from here. If you would like us to consider this change again please file a new PR on the media3 project: https://github.com/androidx/media/pulls

@icbaker icbaker closed this Apr 15, 2024
@google google locked and limited conversation to collaborators Jun 15, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants