HLS/MP3: SeekTo does not seek to exact location

[kschults]

[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 cannot reproduce this. What are you looking at to determine (3)?

[kschults]

In the demo application, I'm seeing that the seekbar goes to ~4:30 (270757ms) when I drop it (I hardcoded the seekbar to use that number - this is replicating a seek based on chapter metadata), but then it jumps back to ~4:00 (240047ms) when playback resumes.

In my own app, I've verified the location where playback resumes by polling the current state of the player.

[ojw28]

I do not observe this behavior with 2.9.4, 2.10.0 or the current dev branch, using the sample provided. The seek bar goes to 4:30, and then stays there. When playback resumes the seek bar goes to 4:31, 4:32 etc as expected.

[kschults]

That's really odd. I can consistently reproduce this using the most up-to-date version of the demo library. To expand my steps:

• I changed PlayerActivity L 333 to hardcode a list containing my playlist URI
• I changed PlayerControlView and inserted positionMs = 270757; as L 1013
• I launch the app, and select the first HLS track.
• Once playback starts, I drag the seekbar to anywhere in the middle and release

When I do that, the seekbar first snaps to 4:31 as it requests the seek, and then jumps back to 4:00 as playback jumps to that location. A second seek to that location works correctly, but the issue reproduces every time I close and re-open the player activity.

I attached a debugger in my own application, and followed the seekTo request, and determined that internally, exoplayer is calling seekTo with the desired value, but I was unable to follow any further than determining that it started loading the chunk that contains 4:30.

Would it be helpful if I provided a video of the behavior?

[ojw28]

I tried on a few different devices and this doesn't reproduce for me. A video would be useful just to see what you're seeing, however I'm not sure what we'll be able to do if we're still unable to reproduce!

[kschults]

Here's a gif of the screen recording, since GitHub doesn't allow mp4 attachments. It lost a little of the framerate in the conversion, but it still shows the issue. You an see where when I release the seekbar, it snaps to 4:31 as it calls seekTo(270757), and then jump to 4:00 as playback changes to there.

If I pause the player before seeking, it stays at 4:31 until I hit play, at which point it jumps to 4:00.

[ojw28]

Hmm! Weird. I do not see that. Do you definitely see this across all devices? I tested on a Galaxy S8 and a Pixel 2 so far.

[kschults]

@ojw28 Sorry, I had thought from our QA team that it was happening across devices. I just double-checked with them, and it's more limited.

It's happening extremely frequently to myself and to our QA lead. We're both using Pixel 3 (9.0). One other QA person has experienced it on a Pixel 1 (9.0), but only infrequently. We don't have any Pixel devices on other versions, so we haven't been able to test that out.

I also just tested across a range of emulators, and couldn't reproduce it on any of them, including a "Pixel 3" 9.0.

I'll update the ticket that it seems to be limited to Pixel devices, mostly Pixel 3, and I'll get the rest of the team to keep trying other devices.

[kschults]

The QA team has also been able to reproduce it consistently on a Nokia 6 (8.1.0) and a Note 4 (6.0.1)

[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.