[Bug 742979] New: adaptivedemux: Adaptive bitrate algorithm does not react to declining bitrate

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=742979
  GStreamer | gst-plugins-bad | git

           Summary: adaptivedemux: Adaptive bitrate algorithm does not
                    react to declining bitrate
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: bugzilla at ashley-family.net
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


The logic used by GstAdaptiveDemux is to accumulate the total number of bytes
downloaded and the time it takes to perform those downloads:

    bitrate =
         (stream->download_total_bytes * 8) /
         ((double) stream->download_total_time / G_GUINT64_CONSTANT(1000000));

The problem with this approach is that this algorithm does not allow
GstAdaptiveDemux to rapidly react to a declining throughput, because prior
downloads disproportionately impact the bitrate calculation.

I think we need something that reacts rapidly to a drop in bandwidth but is
more cautious when increasing bandwidth - a bit like the way the TCP congestion
window works.

Here's my starter for ten:

When selecting the first fragment upon starting to play content,
GstAdaptiveDemux selects the Representation with the lowest bitrate for each
active AdaptationSet.

GstAdaptiveDemux calculates the effective download rate of each fragment by
monitoring the amount of time required to download each fragment and the size
of this fragment. It maintains a record of the download rate of the last three
fragments for each active AdaptationSet.

GstAdaptiveDemux maintains a record of the amount of compressed data that has
been downloaded and has not been rendered, in terms of the amount of time that
this compressed data would take to render at normal playback speed. 

NOTE 1: Not sure if that is even possible - would a buffering query do the job?

GstAdaptiveDemux should suspend downloading of fragments if the amount of
compressed data that has been downloaded and has not been rendered exceeds
buffer_limit seconds.

NOTE 2: buffer_limit would be a configurable property, with a suggested default
of 30 seconds

NOTE 3: For MPEG DASH content that uses the live profile, other factors such as
availability start time restrictions might mean that the amount of buffered
data never reaches the buffer_limit.

Prior to downloading each fragment, GstAdaptiveDemux would use the following
rules to select a Representation from an AdaptationSet:
* If less than three fragments have been downloaded, select the Representation
with the lowest bitrate, 
* otherwise:
    a) Calculate the mean download rate using the recorded download rates and
define this as mrate
    b) Select the Representation that has a bitrate that is less than or equal
to bandwidth_usage% of mrate
    c) Calculate the estimated time to download a fragment using the selected
Representation:
        est = fragment->duration * representation->bitrate / mrate
    d) If est is greater than the amount of data buffered for this
AdaptationSet, select the Representation with the next lowest bitrate. If no
suitable Representation is available, select the Representation with the lowest
bitrate, otherwise repeat from step (c)

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.