[Bug 733959] hlsdemux: download bitrate alogoritmus don't reflect real download rate

[bugzilla at gnome.org]

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

Duncan Palmer <dpalmer at digisoft.tv> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dpalmer at digisoft.tv

--- Comment #9 from Duncan Palmer <dpalmer at digisoft.tv> ---
I've observed this as well - it happens because of the buffering which occurs
when downstream elements are handling buffers from hlsdemux, and the problem is
very severe in my test environment.

The simplest to reproduce is to simply playback content over a link which is
shaped to a relatively low bitrate (e.g. 5mbit/s) so that we're using a low
bitrate variant. I use a uridecodebin with buffer-duration set to 3.5s, and
buffer-size to something large, so that after a short time, hlsdemux spends
most of it's time pushing data downstream (as the first multiqueue spends a lot
of time in overrun). 

In the senario I've described, the time taken for souphttpsrc to produce a
buffer is generally very small, as the buffer comes from the socket read buffer
most of the time. The result is that we calculate quite a high bitrate.

In testing, where I've shaped port 80 on my http server to 5mbit/s using tc:
- hlsdemux takes 2.93s to download a 3s hls segment. Of this, 2.44s is spent
pushing buffers downstream, and 0.49s is spent retrieving buffers from
souphttpsrc. Segment size is 1528440 bytes.
- hlsdemux reports a bitrate of 23 mbit/s for this particular hls segment. 
- Using wget to download the same segment on my device indicates the download
rate is 4 mbit/s. 
- If I mess about with the socket read buffer sizes, setting min to 1024 and
max to 2048 using /proc/sys/net/ipv4/tcp_rmem , /proc/sys/net/core/rmem_max and
/proc/sys/net/core/rmem_default , hlsdemux reports the rate as 8 mbit/s

As msko indicated, this behaviour was triggered by the multiqueue fix. If I set
max-size-buffers on the first multiqueue to 0 (unlimited), the calculated
bitrate is not too bad (tho is it a bit high). This is because we're
continually reading from souphttpsrc, and so spend a lot of that time fetching
data over the network.

I'm not sure what the solution is. One simple solution would be to buffer up
some amount of data in hlsdemux, and measure how long it takes to fill the
buffer. Empty the buffer before fetching more data. The buffer would need to be
large enough to reduce the effects of the socket read buffers. Using a larger
blocksize for souphttpsrc would help as well, but there are downsides to this I
imagine.

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