Skip to content
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

Audio out of sync when seeking in HLS source #9411

Closed
strangesource opened this issue Sep 9, 2021 · 2 comments
Closed

Audio out of sync when seeking in HLS source #9411

strangesource opened this issue Sep 9, 2021 · 2 comments
Assignees
Labels

Comments

@strangesource
Copy link

strangesource commented Sep 9, 2021

Description

When playing back an HLS stream and seeking directly to the end of the stream, audio is out of sync and continues playing for severals seconds.
This started happening after updating from ExoPlayer 2.12.3 to 2.13.3 and is also reproducible in the latest 2.15.0.

Steps to reproduce

  1. Load HLS stream https://bitdash-a.akamaihd.net/content/sintel/hls/playlist.m3u8 into the demo app
  2. Seek right to the end
  3. Observe audio playing back for several seconds and current time ticking up to 15:05 of 14:48

When playing back the content from e.g. 13:50 and not seeking very close to the end, this does not occur.

Thanks in advance!

Edit: forgot to mention that the audio track has additional segments in it. I.e. video has 443 segments with 2sec each while audio has 452 segments with the same length.

@christosts
Copy link
Contributor

The root cause is similar to that of #2233, although it manifests differently in recent ExoPlayer versions (we are now in 2.15.1 compared to 2.1 at #2233).

The segment durations listed in the audio media playlists are rounded to integer precision. When the player seeks, it picks a segment based on the playlist information however the timestamps of the downloaded audio segments are behind the expected timestamp.

In 2.12.3, that made seeking slow: the player starts downloading audio segments and then drops them because it realizes they are behind the seek point. That adds delay until the player is able to resume playback after a seek.

As of 2.13 however, the samples are not dropped and instead the player adjusts the timestamps (in an attempt to fix a timestamp drift), causing the sync issues. Apart from the sync issue when seeking at the end of the video, seeking in general is also not good with this playlist: testing with 2.15.1, when you seek, there's a frozen video frame with audio playing and video starts playing later.

The HLS spec does allow durations to be rounded up, however Apple's HLS Authoring Specification, section 8.1 says

8.1. You MUST use sufficiently accurate segment durations to ensure that the sum of the EXTINF durations of any contiguous group of segments is within one video frame duration of the actual duration of the content.

My recommendation is to update the playlist with accurate segment durations. The player should address the case of inaccurate segment durations but this is likely going to be a low priority. I'll mark this as a duplicate and close it in favor of #2233.

@strangesource
Copy link
Author

Thanks for the detailed feedback, I will have a closer look and take according actions. 👍

@google google locked and limited conversation to collaborators Dec 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants