The Wayback Machine - https://web.archive.org/web/20250424091545/https://github.com/androidx/media/issues/2209
Skip to content

Forcing the use of SeekParameters.CLOSEST_SYNC in a HLS stream #2209

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.

Sign up for GitHub

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

Jump to bottom
Closed
DovydasKl opened this issue Mar 5, 2025 · 4 comments
Closed

Forcing the use of SeekParameters.CLOSEST_SYNC in a HLS stream #2209

DovydasKl opened this issue Mar 5, 2025 · 4 comments
Assignees
@tianyif
Labels
needs triage question

Comments

@DovydasKl
Copy link

Hello,

We're trying to enable SeekParameters.CLOSEST_SYNC in our player instance for our HLS streams, but it doesn't seem to work. We checked the code out and it seems for HLS the HlsChunkSource only calculates adjusted seek positions if the playlist has an EXT-X-INDEPENDENT-SEGMENTS tag. Our streams do not have this tag and we have no way of adding it server-side.

Is there any way to force exoplayer to use the timestamp adjusting logic? Our segments are independent and we have tested an imperfect workaround of calculating the position ourselves before seeking and it speeds up seeking significantly, but letting exoplayer do this would be much more preferable.

The main reason we are trying to do CLOSEST_SYNC seeks, because seek times to exact positions are significantly slower for some reason. If there's any other way to speed up seeking without SeekParameters I'd appreciate input too.

We are on version 1.5.1.
@tianyif
Copy link
Contributor

tianyif commented Mar 7, 2025 •
edited
Loading

Hi @DovydasKl,

Our streams do not have this tag and we have no way of adding it server-side.

Could you please explain a bit why there is difficulty in adding the EXT-X-INDEPENDENT-SEGMENTS server side? In my opinion as of now, we should still trust as much as possible on the playlist, as it should be created logically consistent with the segments in a streaming server. As a library at client side, we definitely cannot assist on server side though, such information will help us to evaluate your case and decide whether we should add a "force" solution. Thanks!
@DovydasKl
Copy link
Author

@tianyif we use a proprietary solution for the server that transcodes and creates the HLS streams. That solution does make independent segments (each segment does have a keyframe in it) but so far we have found no option to make it add the EXT-X-INDEPENDENT-SEGMENTS tag by itself. We could resort to some hackery - like intercepting the playlist and editing it before passing it on to the client, but it would be much simpler to assume the segments are independent when they come from that streaming server.
copybara-service bot pushed a commit that referenced this issue Mar 17, 2025
@tianyif @copybara-github
Loosen the condition for seeking to sync positions in a HLS stream
42b71c2 
Previously we only enable `SeekParameter.*_SYNC` for HLS when `EXT-X-INDEPENDENT-SEGMENTS` is set in the playlist. However, this condition can actually be loosened. To seek in HLS, we need to download the segment in which the resolved seek position locates under any circumstance. If `SeekParameter.PREVIOUS_SYNC` or `SeekParameter.CLOSEST_SYNC` is passed, and that segment happens to start with sync samples, then the seek can be done quicker with that adjusted seek position. And if that segment doesn't start with sync samples, then the behaviour will be the same as we set the adjusted seek position to the exact original position. But we still cannot safely enable `SeekParameter.NEXT_SYNC` as it will potentially cause the seeking to miss more content than seeking to the exact position.

Issue: #2209
PiperOrigin-RevId: 737580861
tonihei pushed a commit that referenced this issue Mar 19, 2025
@tianyif @tonihei
Loosen the condition for seeking to sync positions in a HLS stream
f357f0a 
Previously we only enable `SeekParameter.*_SYNC` for HLS when `EXT-X-INDEPENDENT-SEGMENTS` is set in the playlist. However, this condition can actually be loosened. To seek in HLS, we need to download the segment in which the resolved seek position locates under any circumstance. If `SeekParameter.PREVIOUS_SYNC` or `SeekParameter.CLOSEST_SYNC` is passed, and that segment happens to start with sync samples, then the seek can be done quicker with that adjusted seek position. And if that segment doesn't start with sync samples, then the behaviour will be the same as we set the adjusted seek position to the exact original position. But we still cannot safely enable `SeekParameter.NEXT_SYNC` as it will potentially cause the seeking to miss more content than seeking to the exact position.

Issue: #2209
PiperOrigin-RevId: 737580861
(cherry picked from commit 42b71c2)
@tianyif
Copy link
Contributor

tianyif commented Mar 21, 2025

We submitted a commit to loosen the condition for seeking to sync positions in HLS, and the SeekParameters.CLOSEST_SYNC is allowed to give a try even EXT-X-INDEPENDENT-SEGMENTS is not in the playlist. This is already in the latest 1.6.0 prerelease, and will be in 1.6.0 stable soon.
@tianyif tianyif closed this as completed Mar 21, 2025
@efemoney
Copy link

we use a proprietary solution for the server that transcodes and creates the HLS streams

@DovydasKl If your proprietary solution is ffmpeg you can add -hls_flags independent_segments and if not, do consider using ffmpeg instead!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs triage question
4 participants
@efemoney @google-oss-bot @tianyif @DovydasKl