[Bug 766929] New: Adaptive demuxer CANNOT estimate bandwidth precisely under QOS service

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 766929
           Summary: Adaptive demuxer CANNOT estimate bandwidth precisely
                    under QOS service
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Windows
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: r97922153 at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 328624
  --> https://bugzilla.gnome.org/attachment.cgi?id=328624&action=edit
Experimental environment & result

Dear all:

I found a potential issue about adaptive demuxer's bitrate calculation.

>From the experiment below, it shows the unstable problem for bitrate
calculation.

1. Set media content server's QOS to max 400k bits/sec.

2. Playback a DASH media with two representation sets. Their bandwidths are of
256k & 1500k bits/sec.

3. As the result, we expect to playback the profile of 256k bits/sec since it
is not greater than the QOS bandwidth = 400k bits/sec. However, by the attached
figure you can see the result depends on the size of internal buffer.

Notice that the Vertical axis of  NG case shows that the ESTIMATE bitrates MAY
be over 1500K bits/sec sometimes. In fact, there are total 8 times in 32
measures. It means current flow to calculate bandwidth has a potential issue.
Under some cases it will OVER estimate network bandwidth.

The difference is the inter buffer you apply to Gstreamer's pipeline.

For example, the attached file also give the internal buffer settings to NG &
OK cases.
For NG's case internal buffer AT MOST can buffer ~ 5~6 seconds.
But for OK's case it can almost buffer the entire DASH period.

Why this issue happens? The root MAY be like the example below.

1. Assume each DASH's segment is fixed to 3 second, the internal buffer is full
soon since QOS's bandwidth (= 400K bits/second) is larger than 256K bits/sec &
at the beginning we select the representaion in 256K. It tasks about
(256*5)/(400-256) = 8.889 sec to have internal buffer full (in fact, the (256K
* 3) is the MAX size each segemnt could be but they are usually smaller than
it).

2. Once the internal buffer is full the source in adaptive stream can NOT push
data into multiqueue0 & get stuck here. Notice that the time spent in waiting
push data in NOT included into the calculation to bandwidth.

3. The QOS sever does NoT receive any data request from the client for a while
since the client's source is stuck in pushing data into mq0, for example, 0.8
sec. Once client can push data into mq0 again, the QOS server think it can
deliver the rest quota of 400K in the remaining 0.2 sec & it indeed does.

The Gstreamer player start to download the next fragment & complete receiving
it soon within 0.2 sec. So it believe the bandwidth is perfectly GOOD to over
(256K/0.2) > 1280K. It is the case you see the NG case there are some wrongly
estimated bandwidth which is far larger than the real QOS limit = 400K
appeared.

I think the problem is we do estimate the bandwidth by "after downloading a
fragment with N bytes & spend T second, Bandwidth = N*8/T".

It has problem in handling the burst read where T (smaller than 1 second) is
very small. However for QOS service the unit is usually in second so the burst
read will give us a wrong estimation to current bandwidth. Potentially it may
lead to UNDER-RUN issue by over-estimate current network’s bandwidth.

But if we do estimate the bandwidth by " trigger the bandwidth estimator every
second & see how many bytes we have downloaded = N, Bandwidth = N*8", this
issue could be avoided.

Please estimate if we can do estimate the bandwidth by the mentioned method.

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