[Bug 758539] New: adaptivedemux: start of play is delayed for live streams

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=758539

            Bug ID: 758539
           Summary: adaptivedemux: start of play is delayed for live
                    streams
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: florin.apostol at oregan.net
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

When identifying the current segment to be played for a live stream, the
gst_dash_demux_setup_streams will use the now moment (adjusted with
presentationDelay). The gst_mpd_client_seek_to_time function will compute
ts_microseconds = g_date_time_difference (time, start) and
gst_mpd_client_stream_seek will search the segment corresponding to this
ts_microseconds in the presentation timeline.

But the standards defines the availabilityStartTime for a media segment to be
at the end of the segment:
"For services with MPD at type='dynamic', the Segment availability start time of a
Media Segment is the sum of the value of the MPD at availabilityStartTime, the
PeriodStart time of the containing Period as defined in 5.3.2.1, the MPD start
time and the MPD duration of the Media Segment."

This leads to adaptive demux waiting for the identified segment to be
available.

For a visual scenario, let's consider the following data:
MPD at availabilityStartTime = 12:00:00
suggestedPresentationDelay = 0
Segment templates are uses, there are several segments, each having a duration
of 1s. Segment numbers start at 1, so segment 1 is between 12:00:00 and
12:00:01, etc.
Now is 12:00:05.3

Based on now value, ts_microseconds = 5.3 * 1000 * 1000, choosing segment 6
(which is between 12:00:05 and 12:00:06). When trying to play it, the
gst_adaptive_demux_stream_download_loop function will use
gst_adaptive_demux_stream_get_fragment_waiting_time to determine how much to
wait for the segment to be available. In our case, it will be 6-5.3=0.7s

The longer the segment duration, the longer the initial wait period when
starting to play a live stream.

Question: shouldn't gst_dash_demux_setup_streams function try to choose the
latest available segment (the segment previous to the one it currently
identifies)? That would save the waiting time.

Also, do notice that if suggestedPresentationDelay is not 0, the identified
segment is already available on the server so
gst_adaptive_demux_stream_download_loop will not wait and playback will start
immediately, violating the suggestedPresentationDelay which is not observed
entirely.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.