HLS Live start play from end on window

[LSDsl]

I have live hls stream with 2 min window. Exoplayer start play from end of it. How to tell exo to play from start? (from first chunk in playlist)

[stevemayhew]

I'm assuming "end of it" you means the live-edge (most recent segments).

ExoPlayer defaults to the 3 target-durations back from the live edge, this is from the Client Responsibilities section Section 6.3.3 of the spec.

So, with your example of 2 min window, assuming 6 second segments, and EXT-X-TARGETDURATION:6 you would have 20 segments in your window and ExoPlayer would start playing the 17th segment.

The origin server may specify the EXT-X-START tag in the playlist if behavior other than the default is desired.

If this is not what is happening, then please provide an example URL for triage.

[AquilesCanta]

What @stevemayhew said is one option.

If the live stream you are serving is only going to add segments to the media playlist then you can also indicate that the playlist is an "event" type of playlist, using the EXT-X-PLAYLIST-TYPE tag and ExoPlayer will start playback from the start of the playlist.

If the playlist is a sliding window (segments are removed from the start of the playlist), then playing from the start increases the likelihood of a BehindLiveWindowException, so please keep that in mind so as to handle it gracefully. There's plenty of material in this issue tracker about BehindLiveWindowException.

Passing over to @marcbaechinger to indicate whether there's an API to configure the default start time in the new MediaItem API (without clipping the content, so that we are allowed to seek before the start position of the clip).

[LSDsl]

This all nice if I can change server side. But if no? I want to control this on player side.

[AquilesCanta]

Passing over to @marcbaechinger to indicate whether there's an API to configure the default start time in the new MediaItem API (without clipping the content, so that we are allowed to seek before the start position of the clip).

Please wait for a response from @marcbaechinger. Until you get an answer, if you are in a hurry, you can inject a playlist parser which wraps the default one and "injects" the custom start time in the playlist, so as to emulate one of the tags described above in your client-side.

[marcbaechinger]

Sorry for my late response.

I think with the released version there is currently no option to do that programmatically. We are working on improving HLS live support for low latency. With this there will be the option to set the offset to the live edge also for standard, non-low latency stream. I can not give you a timeline when this will be available in the release branch I'm afraid.

[LSDsl]

@AquilesCanta yes. Now I use fixed HlsPlaylistParser to do this.
@marcbaechinger Hope this will be soon. thx

[Jenjen1324]

We currently also have the desire for this feature. Our use case is for Replaying Live-TV. If a user swaps to a channel, we obviously want to start at the live-edge as is currently the case. But when the user selects the EPG (which is not finished) we want to start at the beginning. Currently we patched HlsMediaSource.onPrimaryPlaylistRefreshed to be able to inject a flag if we want to force from start or not.

In the future, we would also like to be able to start at an arbitrary position, in case the user was watching within that EPG, swaps away and then wants to resume playback where he was, all while that EPG still is in a "Live" state.

EPG is interchangable with a HLS Playlist

[marcbaechinger]

Since 2.13 you can build a media item with a LiveConfiguration. Something like

MediaItem mediaItem = new MediaItem.Builder()
        .setUri(uri)
        .setLiveTargetOffsetMs(10 * 60_000)
        .build();

The above media item would make the player use a target offset of 10 minutes behind the live edge. This would allow the to set an arbitrary position. If you know the duration of the live window of your stream you can set it appropriately at the beginning of the live window (possibly with some margin to avoid running into a BehindLiveWindowException).

Would that help in your case? Or are you asking for a constant or something which makes the player figure out the beginning of the live window if the duration of is unknown to you?

[tonihei]

If you want to start at the beginning of the live stream window, you can also specifically call player.seekTo(0) (or any other position) before player.prepare().

[stevemayhew]

The `setLiveTargetOffsetMs()` does exactly what we would want. Careful with seeking to position 0 in a live playlist, you’ll need to gracefully deal with `BenindLiveWindowException` in that case

…

On Thu, Mar 25, 2021 at 10:27 AM tonihei ***@***.***> wrote: If you want to start at the beginning of the live stream window, you can also specifically call player.seekTo(0) (or any other position) before player.prepare(). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#8218 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADBF6DAL3626SCJJUS6ZVDTFNXANANCNFSM4TUPZQ4Q> .

[Jenjen1324]

@marcbaechinger & @stevemayhew thanks for the insight. It does seem that it's a possible solution to the problem (while seekTo is not since it incurs a significant startup delay for the stream).

It does feel a bit like a workaround though since the live edge can only be approximated by the client application. My current solution with the modified HlsMediaSource is a hack though, so having a wrapped PlaylistParser might be a better solution. Just have to figure out how I will pass the required data to the Parser.

If I understand correctly, in order to inject "configuration" I utilize the MediaItem.tag. Further to make the HlsPlaylistParser behave differently depending on the MediaItem.tag, I need to have a custom MediaSourceFactory which then has to create a new HlsMediaSourceFactory for each MediaItem because I need to inject a unqiue HlsPlaylistParserFactory with my configuration for the specific MediaItem.

May I suggest making some metadata available (e.g. the MediaItem/MediaSource Tag) for the different factories required for HLS? If I had access to the tag within the HlsPlaylistParserFactory I could create all the factories once and handle logic within the HlsPlaylistParserFactory. (Within the ParsingLoadable would also work in this case). Perhaps having some sort of MediaContext throughout all of these may simplify this.

[marcbaechinger]

It does feel a bit like a workaround though since the live edge can only be approximated by the client application.

I understand you want to override the start time in the playlist with your wrapper. What information is in your tag and where do you get that information from? The start position which you then replace in the playlist?

[Jenjen1324]

@marcbaechinger it is kind of an edge case but the use case is as follows:

1. User watches live programme which is an #EXT-X-PLAYLIST-TYPE:EVENT
2. User seeks back to perhaps start watching at the beginning of the programme
3. The App stores the ongoing playback position
4. User switches to other channel / away from the App
5. When the user comes back, he can choose to continue from his recent watches
6. The App should now continue from the stored playback position, regardless if the playlist is still a EVENT or has since switched to VOD

The stored playback position is what I'm adding to the MediaItem Tag in order to somehow pass that information along. If the programme is still ongoing I'm able to approximate the live edge because it should be near the current time - start time of the programme (which is known). Clock sync + recording delays in the backend make this inaccurrate for up to ~15 seconds worst case which I feel is insufficient for a clean "resume where I left off" experience.

In contrast, if I intercept the playlist, I can override EXT-X-START to start exactly at the desired time (if I understood correctly, haven't tried this yet).

[Jenjen1324]

I also found some related issues:

• Provide ForwardingMediaSource to simplify custom implementations #7279 Provide ForwardingMediaSource to simplify custom implementations
• Start position of 0 always resolves to default position for live playbacks #7975 Start position is ignored for some HLS streams

[marcbaechinger]

Something like a method to override the start time in the playlist for a given media item would work for you?

MediaItem mediaItem = new MediaItem.Builder()
        .setUri(uri)
        .setRequestedLiveUnixStartTimeMs(unixStartTimeMs)
        .build();

The liveTargetOffset would then be calculated from that start time you are declaring in the media item.

[Jenjen1324]

@marcbaechinger yep, that would be the ideal solution. Pretty similar to what were doing via the tag at the moment.

[jrocharodrigues]

This would be nice to have also dor Dash streams.

[stevemayhew]

@marcbaechinger our use case is more to adapt to networks that cannot maintain adequate buffering with 3 segments back from live. The dynamic live edge support added to 2.13 should cover this use case.

[marcbaechinger]

Closing as duplicate of #9122