After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 725435 - hlsdemux: enable seek for live streams
hlsdemux: enable seek for live streams
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other All
: Normal enhancement
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-03-01 11:19 UTC by A Ashley
Modified: 2015-01-05 21:34 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
enable seek for live streams (10.58 KB, patch)
2014-03-01 15:32 UTC, A Ashley
needs-work Details | Review
Rebase to master (8.68 KB, patch)
2014-03-13 14:01 UTC, A Ashley
needs-work Details | Review
enable seek for live HLS streams (12.49 KB, patch)
2014-04-04 15:55 UTC, A Ashley
none Details | Review
adaptivedemux: prepare for supporting seeks in live streams (5.60 KB, patch)
2014-12-31 03:42 UTC, Thiago Sousa Santos
committed Details | Review
hlsdemux: Implement live seeking (9.04 KB, patch)
2014-12-31 03:42 UTC, Thiago Sousa Santos
committed Details | Review

Description A Ashley 2014-03-01 11:19: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.
Comment 1 A Ashley 2014-03-01 15:32:12 UTC
Created attachment 270625 [details] [review]
enable seek for live streams
Comment 2 Sebastian Dröge (slomo) 2014-03-01 15:38:36 UTC
(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 3 Sebastian Dröge (slomo) 2014-03-01 15:40:19 UTC
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).
Comment 4 A Ashley 2014-03-01 18:18:24 UTC
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.
Comment 5 Sebastian Dröge (slomo) 2014-03-03 18:48:48 UTC
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.
Comment 6 A Ashley 2014-03-13 14:01:11 UTC
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.
Comment 7 Sebastian Dröge (slomo) 2014-03-15 12:37:23 UTC
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
Comment 8 A Ashley 2014-04-04 15:55:37 UTC
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.
Comment 9 Nicolas Dufresne (ndufresne) 2014-04-04 16:42:16 UTC
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 { }
Comment 10 Thiago Sousa Santos 2014-12-31 03:42:16 UTC
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
Comment 11 Thiago Sousa Santos 2014-12-31 03:42:27 UTC
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.
Comment 12 Thiago Sousa Santos 2014-12-31 03:42:51 UTC
Updated patches for rebased hlsdemux version
Comment 13 Thiago Sousa Santos 2015-01-05 21:32:49 UTC
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