ExoPlayer: HLS/MP3: SeekTo does not seek to exact location
[REQUIRED] Issue description
Calling seekTo when playing from an HLS playlist does not always seek to the exact location. After calling seekTo, playback appears to begin at the beginning of the playlist chunk containing the requested location. From the docs, it appears that exact seeking should be supported.
[REQUIRED] Reproduction steps
- Load the playlist into the sample player
- Seek from the beginning to (e.g.)
270757ms(I accomplished this by hardcoding the seek location intoPlayerControlView.seekToTimeBarPosition) - Playback resumes at approximately
240047ms - Once the playhead is within the current chunk, seeking to that location behaves as expected.
[REQUIRED] Link to test content
Sample playlist has been sent to the dev.exoplayer email.
[REQUIRED] A full bug report captured from the device
Bug report has been sent with the sample playlist.
[REQUIRED] Version of ExoPlayer being used
I have reproduced this on 2.9.4 and 2.10
[REQUIRED] Device(s) and version(s) of Android being used
I am currently using a Pixel 3 running Android 9. We’ve had a couple instances of it happening on a Pixel 1 running 9 as well, but less frequently. I’ve been thus far unable to reproduce it on an emulator.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 26 (11 by maintainers)
Commits related to this issue
- Split SampleQueue.advanceTo for advance & seek use cases This method has two use cases: 1. Seeking. Calls are immediately preceded by a call to rewind(), and the returned value isn't important un... — committed to google/ExoPlayer by ojw28 4 years ago
- HLS: Fix slow seeking into long MP3 segments Issue: #6155 PiperOrigin-RevId: 290117324 — committed to google/ExoPlayer by ojw28 4 years ago
- Split SampleQueue.advanceTo for advance & seek use cases This method has two use cases: 1. Seeking. Calls are immediately preceded by a call to rewind(), and the returned value isn't important un... — committed to google/ExoPlayer by ojw28 4 years ago
- HLS: Fix slow seeking into long MP3 segments Issue: #6155 PiperOrigin-RevId: 290117324 — committed to google/ExoPlayer by ojw28 4 years ago
I’ve filed an internal bug about this [Internal ref: 137524007]. The problem is that the MP3 decoder on affected devices is adjusting buffer presentation timestamps in a way that we don’t expect.
That said, it may be possible (and a good idea) for us to adjust the way we’re handling this type of seeking so that the implementation is not sensitive to these types of decoder adjustment.
We currently associate a
decodeOnlyflag with each buffer, and we pass these flags around the side of the decoder as metadata, using the buffer timestamp as the key. Hence any modifications to the buffer timestamps by the decoder prevent correct re-association of the metadata on the output side. A simpler (but less flexible) alternative is to have the renderer know what the seek position is, and applydecodeOnlytoo all buffers up to the one immediately proceeding that position.