Seek at a chunk level when seeking to chunk start positions #1031
Conversation
|
Thanks for the contribution! The general idea sounds great, we probably need to do some testing to verify it works as expected, but otherwise I think we can merge this change. Can I ask you to do two changes though?
|
|
Thanks @tonihei. Apologies, I'll correct the target branch on Monday. Regarding HLS independent chunks, I'd first like to highlight that there is already a check here: The result is SeekParameters are effectively disabled for content that doesn't declare the independent segments HLS tag. getAdjustedSeekPositionUS() does not adjust the seek position to the start of the chunk, and so this added code is not used. That being said, let me know if a secondary check is still required. |
2eeb54e
to
21bb2ac
Compare
Someone could still manually seek to exactly the start of a chunk even without adjustments via seek parameters. Given chunk durations are often 'round' numbers, this isn't too unlikely actually. |
This avoids issues that can arise due to the slight discrepancies between chunk start times (obtained from the manifest of segment index) and the timestamps of the samples contained within those chunks.
21bb2ac
to
173dbc8
Compare
Sure. I've added a conditional on the chunkSource having independent segments. This required adding a getter to HlsChunkSource. Let me know if this was a reasonable thing to do. |
|
That should work, thanks! I'm going to test this a bit to see what happens. |
|
Also added a test case for this. Thanks again, we'll merge this change soon! |
PiperOrigin-RevId: 603008793 (cherry picked from commit 45bd5c6)
This avoids issues that can arise due to the slight discrepancies between chunk start times (obtained from the manifest of segment index) and the timestamps of the samples contained within those chunks.
This PR adds the equivalent logic of google/ExoPlayer@a4114f5, for HLS TS streams. I have copied the description from that commit.
It is apparent when SeekParameters are used, added for HLS in google/ExoPlayer#9536, that the video sample chosen is not the first keyframe in the chunk, rather the last keyframe of the preceding chunk.
It is ultimately down to using "findSampleBefore()":
media/libraries/exoplayer/src/main/java/androidx/media3/exoplayer/source/SampleQueue.java
Line 978 in f6fe90f
It can be reproduced using the Exoplayer Demo "HLS Apple multivariant playlist advanced (TS)" stream. The first video keyframe PTS in the chunks are offset back by 16.666ms, hence not snapped to. The previous keyframe is used,
some 1983.334ms out of sync with the chunk PTS and that of the audio PTS.
As far as I can tell, it is only visually apparent for tunneled playback where HW AV sync is used, resulting in a jarring acceleration of video decode to catch up with audio.