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 701509 - dashdemux selects first fragment in the manifest for live streams
dashdemux selects first fragment in the manifest for live streams
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other All
: Normal normal
: 1.1.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-06-03 11:40 UTC by A Ashley
Modified: 2013-07-03 18:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to change first fragment selection for live (7.39 KB, patch)
2013-06-03 11:40 UTC, A Ashley
needs-work Details | Review
Change first fragment selection for live streams (5.26 KB, patch)
2013-06-11 13:37 UTC, A Ashley
needs-work Details | Review
calculate start position using period start and suggestedPresentationDelay (4.59 KB, patch)
2013-06-18 11:17 UTC, A Ashley
none Details | Review

Description A Ashley 2013-06-03 11:40:34 UTC
Created attachment 245912 [details] [review]
Patch to change first fragment selection for live

When dashdemux selects its first fragment, it always selects the first fragment listed in the manifest. For on-demand content, this is the correct behaviour. However for live content, this behaviour is undesirable because the first fragment listed in the manifest might be some considerable time behind "now".

I have attached a patch that shows one way that the selection of the first fragment could be achieved. The patch uses the host's idea of UTC and tries to find the oldest fragment that contains samples for this time of day.

Ultimately I think a more sophisticated selection algorithm will be required, to allow dashdemux to build up a buffer of fragments. For example maybe starting 'n' fragments behind "now" or 'm' seconds behind "now".
Comment 1 Will Manley 2013-06-04 18:49:13 UTC
Would it make sense to use minBufferTime from the mpd file to decide how many seconds to start before "now"?  Greg Rutz mentioned it in #701404 and it seems like it may be a good fit providing the content providers with control over when "live" is.
Comment 2 Olivier Crête 2013-06-10 22:42:06 UTC
Review of attachment 245912 [details] [review]:

::: ext/dash/gstdashdemux.c
@@ +235,3 @@
     GST_DEBUG_CATEGORY_INIT (gst_dash_demux_debug, "dashdemux", 0,
+        "dashdemux element");
+    );

Please don't mix re-ident changes into your patch.

::: ext/dash/gstmpdparser.c
@@ +1888,3 @@
         && Representation->SegmentList->MultSegBaseType->SegBaseType
+        && Representation->SegmentList->MultSegBaseType->SegBaseType->
+        Initialization) {

Spurious change..

@@ +3235,3 @@
+  g_assert (t1 != NULL && t2 != NULL);
+
+  /* TODO: Assumes difference is less than a day. */

You could use GDateTime here, it has a g_date_time_difference () function..

@@ +3421,3 @@
     *uri =
+        gst_mpdparser_get_initializationURL (stream->cur_segment_base->
+        Initialization);

Spurious change again
Comment 3 A Ashley 2013-06-11 13:37:52 UTC
Created attachment 246522 [details] [review]
Change first fragment selection for live streams

The patch uses the host's idea of UTC and tries to find the
oldest fragment that contains samples for this time of day.
Comment 4 A Ashley 2013-06-11 13:40:13 UTC
Thanks Olivier.

I have re-created the patch with a rewrite of the gst_mpd_client_calculate_time_difference using g_date_time_difference as suggested. I've also removed the spurious changes caused by gst-indent.
Comment 5 Greg Rutz 2013-06-12 20:37:55 UTC
Review of attachment 246522 [details] [review]:

::: ext/dash/gstmpdparser.c
@@ +3259,3 @@
+  seg_duration = gst_mpd_client_get_next_fragment_duration (client);
+  g_assert (seg_duration > 0);
+gst_mpd_client_get_segment_index_at_time (GstMpdClient * client,

The earliest segment start time also needs to take into account the Period start time.  The Period start time is relative to the MPD availabilityStartTime, so the two would be added together.  Period start time is optional, so it will not always be added in.  Also, the optional MPD@suggestedPresentationDelay should be taken into account and added to the start time.
Comment 6 A Ashley 2013-06-18 11:17:51 UTC
Created attachment 247124 [details] [review]
calculate start position using period start and suggestedPresentationDelay

The patch uses the host's idea of UTC and information from the manifest (MPD@availabilityStartTime, MPD@suggestedPresentationDelay, Period@start) to select the fragment that contains samples for this time of day.
Comment 7 Thiago Sousa Santos 2013-07-03 18:37:41 UTC
Comment on attachment 247124 [details] [review]
calculate start position using period start and suggestedPresentationDelay

I squashed both patches together and rebased on top of git before pushing.

Also updated to seek to 'now' time individually per stream because streams can have very different fragment durations.
Comment 8 Thiago Sousa Santos 2013-07-03 18:38:20 UTC
commit 5ad2a2d161aad6dc64db53aa5c10daf6ed3d74b4
Author: Alex Ashley <bugzilla@ashley-family.net>
Date:   Tue Jun 11 14:28:53 2013 +0100

    dashdemux: Change first fragment selection for live streams
    
    When dashdemux selects its first fragment, it always selects the
    first fragment listed in the manifest. For on-demand content,
    this is the correct behaviour. However for live content, this
    behaviour is undesirable because the first fragment listed in the
    manifest might be some considerable time behind "now".
    
    The commit uses the host's idea of UTC and tries to find the
    oldest fragment that contains samples for this time of day.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=701509