GNOME Bugzilla – Bug 725435
hlsdemux: enable seek for live streams
Last modified: 2015-01-05 21:34:19 UTC
hlsdemux does not support the GST_EVENT_SEEK event for live streams, nor does it support GST_QUERY_SEEKING query for live streams. Some services provide HLS live streams that contain several hours of media segments. An example use case for this is a broadcaster providing a simulcast of their live broadcast channels, with an option to restart a show from the start. They achieve this use case by seeking backwards in the HLS stream to the point in the live stream where the show started.
Created attachment 270625 [details] [review] enable seek for live streams
(Related, hlsdemux for live pipelines is rather suboptimal right now: bug #724983) That would indeed be a good idea and shouldn't be too hard to implement with the current code. Trickiest bit will be to make sure the timestamps still make sense after such a seek.
Comment on attachment 270625 [details] [review] enable seek for live streams Can you update that to apply cleanly (and work) with latest GIT master? The pieces for proper timestamps are missing here at least (which were broken in hlsdemux until a few days ago).
Sorry, thought I had updated to head before re-basing the patch. I was originally working against 1.2 when I wrote the code. It's going to be a while before I get back to this as I'm on vacation for the next week, and it will take me a while to get up to speed with the new timestamps code and re-base the patch. I don't think the timestamps after a seek will be any different between VOD and live, because that code is common. However there might need to be some house keeping to remember how many (nano)seconds of video have fallen off the front of the live playlist.
Yeah, exactly that is needed :) And in a way that works reliable. If you look at the new code, it should be easier to understand and simpler than the old one. But if you have questions feel free to ask me on IRC, here or via mail.
Created attachment 271722 [details] [review] Rebase to master Re-based to git master. However, it's only had minimal smoke tests and should have more testing before integration.
Review of attachment 271722 [details] [review]: ::: ext/hls/m3u8.c @@ +48,3 @@ + if (m3u8) + m3u8->first_sequence_number = -1; This if will always be true, g_new0() calls abort() if it fails to allocate @@ +426,2 @@ self->mediasequence = val; + if (self->first_sequence_number < 0) { == -1 Is this going to be reset to -1 whenever you udpate the playlist? @@ +771,3 @@ + (file->sequence - + client->current->first_sequence_number) * + client->current->targetduration; The duration of a fragment is not (necessarily) related to the targetduration
Created attachment 273592 [details] [review] enable seek for live HLS streams This patch replaces the previous one. Two defects were found with the previous patch: 1. The time offset used a 32bit int, which overflows when playing for more than 2^31 nanoseconds 2. After a seek, the timestamps attached to the buffers pushed from hlsdemux were incorrect if the zero time seek position was no longer available. This patch fixes those two defects and has been re-based to current git master head.
Review of attachment 273592 [details] [review]: Looks good to me, though I'll let Sebastien decide as I know he was working on HLS lately. ::: ext/hls/gsthlsdemux.c @@ +622,3 @@ + if (gst_m3u8_client_get_seek_range (hlsdemux->client, &start, &stop)) { + ret = TRUE; + } Style: remove the { }
Created attachment 293506 [details] [review] adaptivedemux: prepare for supporting seeks in live streams Add function to allow subclasses to specify seeking range for live streams
Created attachment 293507 [details] [review] hlsdemux: Implement live seeking hlsdemux assumes that seeking is not allowed for live streams, however seek is possible if there are sufficient fragments in the manifest. For example the BBC have live streams that contain 2 hours of fragments. The seek code for both live and on-demand is common code. The difference between them is that an offset has to be calculated for the timecode of the first fragment in the live playlist. When hlsdemux starts to play a live stream, the possible seek range is between 0 and A seconds. After some time has passed, the beginning of the stream will no longer be available in the playlist and the seek range is between B and C seconds. Seek range: start 0 ........... A later B ........... C This commit adds code to keep a note of the B and C values and the highest sequence number it has seen. Every time it updates the media playlist, it walks the list of fragments, seeing if there is a fragment with sequence number > highest_seen_sequence. If so, the values of B and C are updated. The value of B is used when timestamping buffers. It also makes sure the seek range is never closer than three fragments from the end of the playlist - see 6.3.3. "Playing the Playlist file" of the HLS draft.
Updated patches for rebased hlsdemux version
commit 50b5d94b2a1dfa702107c9f9203baf6df517f61e Author: Alex Ashley <bugzilla@ashley-family.net> Date: Fri Apr 4 16:45:51 2014 +0100 hlsdemux: Implement live seeking hlsdemux assumes that seeking is not allowed for live streams, however seek is possible if there are sufficient fragments in the manifest. For example the BBC have live streams that contain 2 hours of fragments. The seek code for both live and on-demand is common code. The difference between them is that an offset has to be calculated for the timecode of the first fragment in the live playlist. When hlsdemux starts to play a live stream, the possible seek range is between 0 and A seconds. After some time has passed, the beginning of the stream will no longer be available in the playlist and the seek range is between B and C seconds. Seek range: start 0 ........... A later B ........... C This commit adds code to keep a note of the B and C values and the highest sequence number it has seen. Every time it updates the media playlist, it walks the list of fragments, seeing if there is a fragment with sequence number > highest_seen_sequence. If so, the values of B and C are updated. The value of B is used when timestamping buffers. It also makes sure the seek range is never closer than three fragments from the end of the playlist - see 6.3.3. "Playing the Playlist file" of the HLS draft. https://bugzilla.gnome.org/show_bug.cgi?id=725435 commit af78e2501ca02d2f9cf19a2dd4713b46ff64aca0 Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Mon Jan 5 17:58:54 2015 -0300 adaptivedemux: prepare for supporting seeks in live streams Add function to allow subclasses to specify seeking range for live streams https://bugzilla.gnome.org/show_bug.cgi?id=725435