[Bug 759333] New: hlsdemux/others: Bad drift compensation for live streams

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 759333
           Summary: hlsdemux/others: Bad drift compensation for live
                    streams
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: slomo at coaxion.net
        QA Contact: gstreamer-bugs at lists.freedesktop.org
                CC: thiagossantos at gmail.com
     GNOME version: ---

Currently with live streams we will just fall behind more and more based on
clock drift and also because of rebuffering due to BUFFERING messages.

The only time when we resync (in hls to the 3rd newest fragment, no idea for
the others) is when we fall off the Manifest completely. If the Manifest is
huge (I have one here that has about 1 hour of fragments), we would get up to
one hour behind.

Instead we should probably start resyncing earlier. Like once we are 3 or 6 or
$number fragments behind the one we would resync to, or 1 minute or whatever
worth of fragments behind the fragment that we would resync to.

It doesn't seem a good idea to have live streams go that far away from being
live.


I'll provide a patch for HLS later, but unfortunately the same work has to be
redone for DASH and the others individually.

DASH fortunately has an optional extension that allows to compensate for this
based on the server clock, but if that is not available we should also do
something like I proposed above.

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