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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #28 from Duncan Palmer <dpalmer at digisoft.tv> ---
These patches are against hlsdemux in 1.4, and implement the scheme I outlined
in my previous comment.

I've tossed up whether or not to modify souphttpsrc to have it tell us the
bitrate, but I prefer getting this information from the queue, as it means
we're independent of the element uridownloader chooses to place before the
queue.

So, I added a property named avg-in-rate to queue2 to retrieve the average
bitrate. This is not the overall bitrate, but a weighted running average, which
I think is fine. If we try and get the bitrate in the first 0.2 seconds, it
will not yet have been calculated, so I added a something to handle this case.

Testing:
- Modify hlsdemux so that _src_chain() sleeps for 7 seconds after a fixed
  number of fragments are received. Observe that the bitrate calculated by the
  queue is correct, and that calculated by the old hlsdemux method is way too
  high. This test simulates the issue which triggers this bug.
- Playback using dripls to switch bitrate a number of times. Observe that the
  calculated bitrate is correct for all segments.

I'd be interested in feedback on these changes.

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