ExoPlayer UI: Support different UI modes for live events

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.

Sample screenshot: https://drive.google.com/file/d/0B_ElWh6cyPN0S0hQaGRWcjFOclk/view?usp=sharing

iOS dash player have this implementation support

Dec 16 '16 16:12 Duna

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.

Dec 16 '16 16:12 ojw28

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.

Jan 20 '17 21:01 Duna

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.

Jan 20 '17 22:01 ojw28

Reopening this as a feature request to support different modes with our default UI components.

Jun 06 '19 20:06 ojw28

Can i expect on fix? On what date i can expect ?

Jun 06 '19 21:06 Shadkirill

There is currently no ETA for this.

Jun 06 '19 21:06 ojw28

When can I expect this important feature to be implemented?

Aug 29 '19 13:08 Shadkirill

There is currently no ETA for this.

Aug 29 '19 16:08 ojw28

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.

Sample screenshot: https://drive.google.com/file/d/0B_ElWh6cyPN0S0hQaGRWcjFOclk/view?usp=sharing

iOS dash player have this implementation support

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!

Nov 29 '19 14:11 Sicarius4u

It's been 3 years and Google doesn't move his a.s to fix the BUG

Nov 29 '19 16:11 Duna

Generalising this feature request to track multiple requests for more UI flexibility for live playbacks:

Option for seek bar to represent entire duration of a live event (not just the available window)
Option for position to be relative to the live edge (requested in #6487)
Option to disable forward button if playback is already close to the live edge (requested in #6487)

Dec 21 '19 13:12 ojw28

is there any update on this? I would like to have a UI that is more suitable for live videos on EXOPlayer