[Bug 753751] Dashdemux: returned seekable range for live streams is not usable

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Tue Sep 29 08:10:01 PDT 2015


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

--- Comment #16 from A Ashley <bugzilla at ashley-family.net> ---
There was a problem with the BBC example stream that was causing it to 404 when
it shouldn't be. It should be ok now.

We probably need another ticket to track what the behaviour should be for 404
errors on a live stream. Moving on to the next segment is probably a reasonable
option. The DVB DASH specification defines quite a few rules for this,
involving manifest refreshes and refreshing clock drift compensation.

I could live with making the ACCURATE flag having a slightly different meaning
for live streams, but it does seem a bit ugly.

For any "sliding window" live stream (e.g. DASH or HLS) we have the situation
that the values returned by GST_QUERY_SEEKING are only valid for short period
of time, because fragments are being added and removed by the server. In the
case of HLS, this isn't normally an issue because the values returned by
GST_QUERY_SEEKING are valid until the playlist is reloaded. In the case of DASH
this doesn't work because it is based upon wall clock time. One nanosecond
after the response to GST_QUERY_SEEKING, the start value can no longer be used.

There is another issue in that it will take time to download a fragment. There
is no point returning a position in GST_QUERY_SEEKING that refers to a fragment
that cannot be downloaded before it will have been deleted from the server.

Another problem is that GST_QUERY_SEEKING returns a stop value that is beyond
the available range. If you have a look at the
gst_mpd_client_check_time_position() and
gst_mpd_client_get_next_segment_availability_end_time() functions in
gstmpdparser.c, they include the segment duration when checking if a segment is
available. The gst_dash_demux_get_live_seek_range() function in gstdashdemux.c
ignores the segment duration.

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


More information about the gstreamer-bugs mailing list