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

1. Load the playlist into the sample player
2. Seek from the beginning to (e.g.) 270757ms (I accomplished this by hardcoding the seek location into PlayerControlView.seekToTimeBarPosition)
3. Playback resumes at approximately 240047ms
4. 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.

[ojw28]

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 decodeOnly flag 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 apply decodeOnly too all buffers up to the one immediately proceeding that position.

[ojw28]

@kschults - We’re getting around to implementing a better fix for this. Would it be possible for you to send us another test stream, so we can make sure the final fix still works properly? Thanks!