UI: Support different UI modes for live events

[Duna]

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

[ojw28]

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]

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]

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]

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

[Shadkirill]

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

[ojw28]

There is currently no ETA for this.

[Shadkirill]

When can I expect this important feature to be implemented?

[ojw28]

There is currently no ETA for this.

[Sicarius4u]

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!

[Duna]

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

[ojw28]

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)

[Y2JChamp]

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

[javaboboApp]

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]

Have you any estimates on it? it's really needed.

[jrhager84]

Is this still not done?

[hansolowireless]

Nothing yet?