HLS: Can't seek on stream without an EXT-X-ENDLIST tag

In a HLS playlist that doesn't yet have a #EXT-X-ENDLIST tag, but that contains over 2 hours of media segments available in that playlist, the player doesn't let the user seek in the past. Most players that I've seen that support this, would play the video in the most recent time (as does VLC), but would position the playhead at the end of the progress-bar (or however it's called). The current time would be for example: 2:00:00 and incrementing as the available window grows on the playlist. If the playlist is a sliding-window, then the current time would stay around 2:00:00 and technically wouldn't increment by much before going back down to 2:00:00 once the segments are removed from the playlist.

If VLC would act like this, we could technically make it easy for the user to seek between 0:00:00 and 2:00:00. The player will then be able to seek at the user defined time by calculating which segment to load based on the playlist.

I've tried the latest nightly build of VLC 2.2.2 and 3.0.0 on Windows. The only thing I've noticed is that VLC 3.0.0 seems to put the playhead at the beginning of the progress bar, while indicating a not-well calculated current time on that left-side and displays 00:00 on the right-hand side. This isn't yet what I'd expect.

Note: If the behavior described above was implemented, when a user seeks at the far-right of the progressbar on a sliding window or non sliding window , unclosed (without a EXT-X-ENDLIST tag yet) M3U playlist, the player would technically be going back to what people consider as "back to LIVE".

I'd love to see this fixed in the 2.x versions.

So the only issue of 3.0.0 is:

• while indicating a not-well calculated current time on that left-side and displays 00:00 on the right-hand side

?

No EXT-X-ENDLIST means LIVE You can't seek on live content

Agreed.

added Status::will not fix label

closed

Why wouldn't you be able to seek on LIVE stream ? Many web players support this (ex: Clappr, Some implementation of Video.js, Youtube (though in this latter case it's DASH, but still the same concept), just to name a few.

The RFC's sure doesn't state that EXT-X-ENDLIST means you can't seek live content. It just means : "The EXT-X-ENDLIST tag indicates that no more media files will be added to the Playlist file." ref: https://tools.ietf.org/html/draft-pantos-http-live-streaming-06#page-9

Regarding playback behavior, all it says is: "The client SHALL choose which media file to play first from the Playlist when playback starts. If the EXT-X-ENDLIST tag is not present and the client intends to play the media regularly (i.e. in playlist order at the nominal playback rate), the client SHOULD NOT choose a file which starts less than three target durations from the end of the Playlist file." ref: https://tools.ietf.org/html/draft-pantos-http-live-streaming-06#page-17

which means, just don't play the 2nd last, or last segment when the EXT-X-ENDLIST tag isn't present. The client can decide to start playback wherever he wishes in the available playlist (usually through the seeking functions). This type of playlist is very often available from services that store a sliding-window playlist, which for example permits you to seek up to X amounts of minutes/hours in the past from the live stream. Akamai HLS streams often have this if the owner of the stream decides to enable it, in all cases the minimum is 3 segments according to the specs, but there are no maximum on live streams.

On the server side, if the segments are in the playlist, those files MUST be available for the player to load at the time that the playlist was loaded, thus a client should be able to seek anywhere within that playlist (which needs to be constantly reloaded since it's a un-finished playlist) ref: https://tools.ietf.org/html/draft-pantos-http-live-streaming-06#page-14

Obviously, the behavior of the Player / Client in such a case is 100% at the discretion of the developer, but I wanted to offer my opinion. This is why I've opened this bug.

To resume the types of playlists that happen in the wild:

1. Finished fixed playlist: The EXT-X-ENDLIST tag is present. EXT-X-PLAYLIST-TYPE MAY be present with a value of VOD or might not be present.
2. Unfinished fixed playlist: The EXT-X-ENDLIST tag is not present, but the EXT-X-PLAYLIST-TYPE tag is present with a value of EVENT (which means that NO media can be removed from the playlist - no sliding window)
3. Unfinished sliding-window playlist: The EXT-X-ENDLIST tag is not present and the EXT-X-PLAYLIST-TYPE tag is not present.

Regarding 3.0.0, it still doesn't seek and it's behavior is not right. The only difference between 2.2.x and 3.0.0 is that 3.0.0 displays a current time, and it's not well calculated, but the playhead doesn't move.

The behavior I would expect in 2.2.x and 3.0.0:

1. If the playlist does NOT contain #EXT-X-ENDLIST AND (#EXT-X-PLAYLIST-TYPE:EVENT is PRESENT or NOT PRESENT): The current time (playhead) to be at the tail of the playlist (or close to the tail (~3 segments from the end) on startup. I would expect the current time to be equal to the total duration of all URIs #EXTINF duration value preceding the currently played URI (segment) + the current time within the currently played segment. I would expect the total-duration of the playlist to be equal to the total of all the URIs #EXTINF duration values.I would also expect the user to be able to seek within the available total duration of the current playlist revision*. (*: Current playlist revision: Since it's an ever changing playlist in this case, the playlist is in such a case periodically reloaded to reflect it's latest state)
2. If the playlist contains #EXT-X-ENDLIST AND #EXT-X-PLAYLIST-TYPE IS or IS NOT present: The current time (playhead) to be at the head of the playlist on startup. I would expect the current time to be equal to the total duration of all URI's #EXTINF duration value preceding the currently played URI + the current time within the currently played URI. I would expect the total-duration of the playlist to be equal to the total of all the URIs #EXTINF duration values. I would expect the user to be able to seek within the playlist (this latter already works in a playlist that has an #EXT-X-ENDLIST tag, but the current time and total duration aren't right).

removed Status::will not fix label

reopened

Here's a list of players that can be tested that support DVR on LIVE streams that have more than 3 segments (Playlists that don't yet have the #EXT-X-ENDLIST tag in them):

• http://osmfhls.kutu.ru/ There's a sample player: Select Grind Player, Enter a URL to a m3u8 playlist that doesn't have an #EXT-X-ENDLIST and that has a large set of segments available and that keeps on appending segments to the end of the playlist. Finally select "is DVR" and click Play.

• Flowplayer: https://www.peer5.com/examples/video/flowplayer.html?stream=https://livestream.peer5.com/video/kite/index.m3u8 (seems to only render video in chrome here)

• Clappr (best behavior) : https://www.peer5.com/examples/video/clappr.html?stream=https://livestream.peer5.com/video/kite/index.m3u8

• Media Element Player: http://www.flashls.org/mediaelement/demo/mediaelementplayer-hls.html (At the bottom of the page you can enter your own URL and it'll support Live with DVR (sliding window or not) m3u8 files.

• HLS.js : http://dailymotion.github.io/hls.js/demo/ Just enter a URL to a live m3u8 that has either a sliding window with a reasonable list of segments or a non sliding window, as long as it does not contains a #EXT-X-ENDLIST tag.

• JWPlayer: http://support.jwplayer.com/customer/portal/articles/1430265-dvr-live-streaming . This one uses a negative current time, which is a bit confusing.. I don't particularly like this negative thing. They call this feature: On-demand and sliding window live DVR streaming.

Here's a list of players that have a nice timeline/seek behavior on VOD stream (finished playlists, that contains a #EXT-X-ENDLIST). The above players also typically behave properly with such streams.

• Video.js : https://www.peer5.com/examples/video/videojs.html?stream=https://cdnapisec.kaltura.com/p/1375472/sp/137547200/playManifest/entryId/0_ncvvnzfe/flavorIds/0_obbhtwhw,0_ikr2ob7t/format/applehttp/protocol/https/a.m3u8

From those samples, I conclude that if you need a LIVE M3U8 with some sliding window, you could use: https://livestream.peer5.com/video/kite/index.m3u8 as a basic sample, but maybe it's best to find one that has a bigger window and no discontinuity (since the files are recycled in this case and could cause confusion within the player to know where to seek), nevertheless it should work for basic testing. I've also found this Live m3u8 that has DVR enabled https://stream1.la1tv.co.uk:1936/bailriggfm/studio_out_720p/playlist.m3u8?DVR but it's pitch black.

Note: some of the players that use the MSE (Media Source Engine), like HLS.js do sometimes have issues with the stream just stopping playback, those issues seem to be caused by the MSE api pickiness , but that's beside the point.

added Component::Input: network streams Severity::normal labels

assigned to @fcartegnie

Code has been updated in 4.0. Seek works with some limitations.