-
Notifications
You must be signed in to change notification settings - Fork 6k
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
Conversation
// 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 |
There was a problem hiding this comment.
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.
201ece9
to
ef93727
Compare
long startOfPlaylistInPeriodUs = | ||
mediaPlaylist.startTimeUs - playlistTracker.getInitialStartTimeUs(); | ||
long relativePositionUs = positionUs - startOfPlaylistInPeriodUs; | ||
int segmentIndex = |
There was a problem hiding this comment.
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.
library/hls/src/main/java/com/google/android/exoplayer2/source/hls/HlsChunkSource.java
Show resolved
Hide resolved
ef93727
to
71a4fb1
Compare
`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.
71a4fb1
to
f6488d3
Compare
library/hls/src/main/java/com/google/android/exoplayer2/source/hls/HlsChunkSource.java
Show resolved
Hide resolved
library/hls/src/test/java/com/google/android/exoplayer2/source/hls/HlsChunkSourceTest.java
Show resolved
Hide resolved
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.
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 |
getPlaylistSnapshot()
can return a cached but potentially quite stale playlistthat 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:
Timeline.Window
The seek request is issued with
Timeline.Window
from playlist B, yet the call togetAdjustedSeekPositionUs()
occurs:
The check is simple, does basic sanity check on
targetPositionInPlaylistUs
(that itis < durationUs of the selected playlist). This covers the positions WWW.