GNOME Bugzilla – Bug 701509
dashdemux selects first fragment in the manifest for live streams
Last modified: 2013-07-03 18:38:20 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".
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.
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
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.
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.
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.
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 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.
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