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

Seeking to a negative value makes the ExoPlayer to pause over HLS #8906

Closed
nandovelazquez opened this issue May 5, 2021 · 5 comments
Closed
Assignees

Comments

@nandovelazquez
Copy link

Passing a negative value to the player.seekTo() function makes the ExoPlayer puts itself in a "pause" state and it never re-positions the playhead to 0 seconds. Still, we can see that the seek command is executed in the logcat.

To reproduce this we can use the Exo demo app. In the PlayerActivity set a delay of, could be 10 seconds, and then execute a player.seetTo(-3000). Then the video will pause, the current position label will be at -0:00 but the Play/Pause button will stay as playing, and nothing else will happen.
There is no error message returned/thrown by the ExoPlayer nor printed in the logcat.

This is only with HLS videos. DASH and SmoothStreaming videos work fine.

Could you take a look, please?

@christosts
Copy link
Contributor

christosts commented May 6, 2021

Thanks for reporting this, I can verify it happens on r2.13.3. I'm still investigating to see exactly what's happening

[update]
I can see there's inconsistent behavior, not only between different kind of sources (DASH vs HLS), but also between videos of the same kind. From the demo app, seeking to -5000:

  • the "Clear DASH" assets can seek but the "60fps DASH" freezes.
  • From the HLS content, " the "Apple 4x3 basic stream (TS)" freezes but "Apple 16x9 basic stream (TS)" works with the negative position.

The correct fix of this would be to not allow seeking to a negative position at all and make this behavior consistent for all media types.

For your application: please make sure you are not seeking with negative timestamps. If you are already performing this on DASH content and it works, I'd suggest you change that. Otherwise, when this fix is implemented, it might break your app.

@nandovelazquez
Copy link
Author

That was fast!

Thank you, I'll keep this in mind. 👍

@LuGO0
Copy link
Contributor

LuGO0 commented Aug 6, 2021

Hi @christosts @claincly can I take this up ?

@LuGO0
Copy link
Contributor

LuGO0 commented Sep 8, 2021

@ojw28 apart from assertions what could be possible ways to not allowing negative seek for various media types?

ojw28 added a commit that referenced this issue Sep 10, 2021
This is a candidate fix for #8906. As mentioned in that issue,
negative positions within windows might be (kind of) valid in
live streaming scenarios, where the window starts at some
non-zero position within the period. However, negative positions
within periods are definitely not valid. Neither are positions
that exceed the period duration.

There was already logic in ExoPlayerImplInternal to prevent a
resolved seek position from exceeding the period duration. This
fix adds the equivalent constraint for the start of the period.
It also moves the application of the constraints into Timeline.
This has the advantage that the constraints are applied as part
of state masking in ExoPlayerImpl.seekTo, removing any UI flicker
where the invalid seek position is temporarily visible.

Issue: #8906
PiperOrigin-RevId: 395917413
@ojw28 ojw28 closed this as completed Sep 10, 2021
@ojw28
Copy link
Contributor

ojw28 commented Sep 10, 2021

This should be fixed by the commit above, which constrains the seek position after it's resolved to a period position, for which negative values really are always invalid.

christosts pushed a commit that referenced this issue Sep 21, 2021
This is a candidate fix for #8906. As mentioned in that issue,
negative positions within windows might be (kind of) valid in
live streaming scenarios, where the window starts at some
non-zero position within the period. However, negative positions
within periods are definitely not valid. Neither are positions
that exceed the period duration.

There was already logic in ExoPlayerImplInternal to prevent a
resolved seek position from exceeding the period duration. This
fix adds the equivalent constraint for the start of the period.
It also moves the application of the constraints into Timeline.
This has the advantage that the constraints are applied as part
of state masking in ExoPlayerImpl.seekTo, removing any UI flicker
where the invalid seek position is temporarily visible.

Issue: #8906
PiperOrigin-RevId: 395917413
@google google locked and limited conversation to collaborators Nov 10, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants