[Bug 783075] adaptivedemux: Check live seeking range more often

[GStreamer (GNOME Bugzilla)]

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

Edward Hervey <bilboed at bilboed.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|1.12.1                      |1.12.2

--- Comment #9 from Edward Hervey <bilboed at bilboed.com> ---
Pushed to both master and 1.12

commit 50f92fab89893246f309680bdbdc336cbce38100
Author: Edward Hervey <edward at centricular.com>
Date:   Thu Jul 13 12:57:12 2017 +0200

    adaptivedemux: Workaround for live seek ranges when advancing

    This is a workaround for a regression introduced by
    f4190a49c04f1d5d174cebba0bc9a03a7ec721c2
     ( adaptivedemux: Check live seeking range more often )

    The goal of the previous commit was to be able to cope with non-1.0
    rates on live streams which have a "seeking window" (i.e. the server
    keeps around quite a bit of the live stream so you can seek back into
    it).

    Without that commit, two different kind of issues would happen:
    * When doing reverse playback, you would never check whether you
      are outside of the seekable region. And would then continuously
      try to download fragments that are no longer present.
    * When doing fast forward, you would end up requesting fragments
      which are not present yet.

    In order to determine whether one was *really* outside of the seekable
    window, we check whether the current stream position is still
    within the seekable region.

    The *problem* though with that commit is that it assumes that subclasses
    will return continuously updated seeking ranges (i.e. dependent on the
    current time), which is *NOT* the case.

    For example:
    * dashdemux does use the current UTC to determine the seekable region
    * hlsdemux uses the values from the last updated manifest

    Therefore if one downloads fragments faster than realtime, for HLS
    we would end up at the end of the last manifest seekable range, and
    the previous commit would consider the stream as being ended... which
    is not the case.

    In the long run, we need to figure out a way to cope with non-1.0
    rates on live streams for all types of stream (including HLS).

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

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