You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
UI: Support different UI modes for live events #2213
I give you an example:
We have a live mpd with total duration of 2 hours. Start the player and wait 1h24m
The total segments stored on server are for 1 hour, the current player time is 1h24, but the user is not able to see segments older than an 1 hour.
User should see the seekbar like this
1h24m |----------------------------------|xxxxxxxxxxxxxxxxxxxxxxxxxxxxx|-------------------------| 2h
.......................segments unavailable...............segments available..........................future segments
In current implementation when moving the scrubber to the beginning it will show to the user the segments 1 hour older. User will be confised because the show started 2 hours ago and it is able to see only segments 1 hour older.
Exactly what the seek bar should look like is a matter of opinion, and the desired choice may vary between apps depending on exactly what the use case is. As an example, for live TV broadcast where a live stream has been running for months continuously, the UI as shown would be useless.
ExoPlayer exposes all of the information necessary to create your own player UI components that behave as described. We don't have any short/mid-term plans to support this directly.
But the native IOS player has the upper explained implementation. If they did it, wasn't a good reason for Apple to take such decision in implementation? E.g. Currently when the live stream past segments is 15 min and the stream plays for 20min, when seek to the beginning the users are expecting to see min t-20, but actually is t-15.
The only valid reason in not implementing this feature is that is needed custom seek bar component, and takes time for coding.
How to display the seek bar in these cases doesn't have a single right answer. There are different approaches, as noted here, and the one that's "best" is likely dependent on both the app, the nature of the streams being played and personal preference. "What Apple did" is not a ground truth for correctness. I suspect that a user will largely expect what they're used to from using other apps (or your app if they're a regular user). There are existing players that take both of the approaches described in this thread.
As an example of where our approach might be more useful than the one you describe, consider a case where the event duration is much longer than the seekable window. For example consider a 24 hour event where the seekable window is 15 minutes. In the approach you describe only 1% of the width of the seek bar would be usable for seeking, making it very hard to seek accurately within the 15 minutes. In our approach 100% of the width of the seek bar would be usable and accurate seeking would be possible.
As above, if you require different behaviour there's nothing stopping you from implementing your own player UI components to do this. If you were to modify the library player UI components to support an alternate mode that behaves as you describe, enabled via some kind of setLiveSeekMode(mode) method, then we would also consider accepting a pull request should you wish to contribute that back to the project.
changed the title [-]Seekbar/player does not take into account the entire duration of a live stream, if older segments are not available[/-][+]UI: Allow seek bar to represent entire duration of a live event (not just the available window)[/+]on Jun 6, 2019
I give you an example:
We have a live mpd with total duration of 2 hours. Start the player and wait 1h24m
The total segments stored on server are for 1 hour, the current player time is 1h24, but the user is not able to see segments older than an 1 hour.
User should see the seekbar like this
1h24m |----------------------------------|xxxxxxxxxxxxxxxxxxxxxxxxxxxxx|-------------------------| 2h
.......................segments unavailable...............segments available..........................future segments
In current implementation when moving the scrubber to the beginning it will show to the user the segments 1 hour older. User will be confised because the show started 2 hours ago and it is able to see only segments 1 hour older.
changed the title [-]UI: Allow seek bar to represent entire duration of a live event (not just the available window)[/-][+]UI: Support different UI modes for live events[/+]on Dec 21, 2019
Activity
ojw28 commentedon Dec 16, 2016
Exactly what the seek bar should look like is a matter of opinion, and the desired choice may vary between apps depending on exactly what the use case is. As an example, for live TV broadcast where a live stream has been running for months continuously, the UI as shown would be useless.
ExoPlayer exposes all of the information necessary to create your own player UI components that behave as described. We don't have any short/mid-term plans to support this directly.
Duna commentedon Jan 20, 2017
But the native IOS player has the upper explained implementation. If they did it, wasn't a good reason for Apple to take such decision in implementation? E.g. Currently when the live stream past segments is 15 min and the stream plays for 20min, when seek to the beginning the users are expecting to see min t-20, but actually is t-15.
The only valid reason in not implementing this feature is that is needed custom seek bar component, and takes time for coding.
ojw28 commentedon Jan 20, 2017
How to display the seek bar in these cases doesn't have a single right answer. There are different approaches, as noted here, and the one that's "best" is likely dependent on both the app, the nature of the streams being played and personal preference. "What Apple did" is not a ground truth for correctness. I suspect that a user will largely expect what they're used to from using other apps (or your app if they're a regular user). There are existing players that take both of the approaches described in this thread.
As an example of where our approach might be more useful than the one you describe, consider a case where the event duration is much longer than the seekable window. For example consider a 24 hour event where the seekable window is 15 minutes. In the approach you describe only 1% of the width of the seek bar would be usable for seeking, making it very hard to seek accurately within the 15 minutes. In our approach 100% of the width of the seek bar would be usable and accurate seeking would be possible.
As above, if you require different behaviour there's nothing stopping you from implementing your own player UI components to do this. If you were to modify the library player UI components to support an alternate mode that behaves as you describe, enabled via some kind of setLiveSeekMode(mode) method, then we would also consider accepting a pull request should you wish to contribute that back to the project.
ojw28 commentedon Jun 6, 2019
Reopening this as a feature request to support different modes with our default UI components.
[-]Seekbar/player does not take into account the entire duration of a live stream, if older segments are not available[/-][+]UI: Allow seek bar to represent entire duration of a live event (not just the available window)[/+]Shadkirill commentedon Jun 6, 2019
ojw28 commentedon Jun 6, 2019
1 remaining item
ojw28 commentedon Aug 29, 2019
Sicarius4u commentedon Nov 29, 2019
Hi Duna!
You know, I'm facing the same issue for a requirement at work, were you able to achieve this? any hint you can provide?
Thanks in advance!
Duna commentedon Nov 29, 2019
[-]UI: Allow seek bar to represent entire duration of a live event (not just the available window)[/-][+]UI: Support different UI modes for live events[/+]ojw28 commentedon Dec 21, 2019
Generalising this feature request to track multiple requests for more UI flexibility for live playbacks:
Y2JChamp commentedon Jul 2, 2021
is there any update on this? I would like to have a UI that is more suitable for live videos on EXOPlayer
javaboboApp commentedon Jul 13, 2021
I think this feature is really needed it's a shame that we have to make playgrounds in order to customize ui in live events.
hamid97m commentedon Jan 21, 2022
Have you any estimates on it? it's really needed.
jrhager84 commentedon Oct 30, 2023
Is this still not done?
hansolowireless commentedon Jul 4, 2024
Nothing yet?
ELCHULI190 commentedon Jun 24, 2025
It's been quite a while since this issue was created, any update?
thathorizon commentedon Aug 11, 2025
Updates?
[ui-compose-material3] Add LIVE support to ProgressSlider