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

[GStreamer (GNOME Bugzilla)]

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

Vincent Penquerc'h <vincent.penquerch at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|git master                  |1.9.2

--- Comment #102 from Vincent Penquerc'h <vincent.penquerch at collabora.co.uk> ---
Thanks for the reviews!

commit dc6e4ccbf9d23962cf39ce7bd9f9152e9d41a6e3
Author: Alex Ashley <bugzilla at ashley-family.net>
Date:   Wed Jan 20 16:42:24 2016 +0000

    tests: dashdemux: add test for gst_mpd_client_get_maximum_segment_duration

    Add a test of the gst_mpd_client_get_maximum_segment_duration() function
    to check that it first checks the MPD at maxSegmentDuration and then falls
    back to checking all of the segment durations.

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

commit d9bcf4dbd93df05255feb6f52dec68dbe13622ac
Author: Alex Ashley <bugzilla at ashley-family.net>
Date:   Wed Feb 24 15:54:54 2016 +0000

    dashdemux: include segment duration when calculating seek range

    The gst_dash_demux_get_live_seek_range () function returns a stop value
    that is beyond the available range. The functions
    gst_mpd_client_check_time_position() and
    gst_mpd_client_get_next_segment_availability_end_time() in
    gstmpdparser.c 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.

    According to the DASH specification, if maxSegmentDuration is not present,
    then the maximum Segment duration is the maximum duration of any Segment
    documented in the MPD.

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

commit 535f10b61d0c45c8e7f73de298432b5e97385e05
Author: Vincent Penquerc'h <vincent.penquerch at collabora.co.uk>
Date:   Wed Feb 24 15:52:41 2016 +0000

    adaptivedemux: retry once on 4xx/5xx in certain conditions

    This helps catch those 404 server errors in live streams when
    seeking to the very beginning, as the server will handle a
    request with some delay, which can cause it to drop the fragment
    before sending it.

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

commit 341cdb198f4f1a8da8e85bbf2a7da75a7ee3ab6b
Author: Alex Ashley <bugzilla at ashley-family.net>
Date:   Wed Feb 24 15:47:09 2016 +0000

    adaptivedemux: expose HTTP status

    To allow adaptivedemux to make retry decisions, it needs to know what
    sort of HTTP error has occurred. For example, the retry logic for a
    410 error is different from a 504 error.

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

commit 5b7f60dada60ce1b8dfcddc25012a906357e92e3
Author: Vincent Penquerc'h <vincent.penquerch at collabora.co.uk>
Date:   Mon Mar 7 17:04:33 2016 +0000

    adaptivedemux: allow seeking before start in live streams

    Some derived classes (at least dashdemux) expose a seeking range
    based on wall clock. This means that a subsequent seek to the start
    of this range will be before the allowed range.

    To solve this, seeks without the ACCURATE flag are allowed to seek
    before the start for live streams, in which case the segment is
    shifted to start at the start of the new seek range. If there is
    an end position, is is shifted too, to keep the duration constant.

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

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