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

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Tue Jan 20 08:55:46 PST 2015


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

--- Comment #9 from Mathieu Duponchelle <mathieu.duponchelle at epitech.eu> 2015-01-20 16:55:39 UTC ---
This patch uses the moving average bitrate in every case, which means that
subclasses will also go up a bitrate based on it. Using the total average
bitrate in case the moving average bitrate is superior to it seems a bit too
conservative to me, as it will get less and less reactive with time.

I considered using an exponential moving average, which would have simplified
the implementation, but the interval as calculated by g_get_monotonic_time () -
stream->download_start_time fluctuates too wildly.

The length of the "lookback window" is hardcoded to 100 buffers for now, should
I just #define it or expose it as a property?

As for testing, one can use the RangeHttpServer implemented in
gst-devtools/validate/launcher :

Apply this diff: http://www.fpaste.org/172014/21772678/

Then run the server at the root of the directory from which you wish to serve
files, in my case :

[ptv] [meh at meh medias]$ pwd
/home/meh/gst-validate/gst-integration-testsuites/medias
[ptv] [meh at meh medias]$ ls
big  defaults  extras-ges
[ptv] [meh at meh medias]$ python
/home/meh/devel/pitivi-git/gst-devtools/validate/launcher/RangeHTTPServer.py

And in another terminal :

gst-launch-1.0 playbin
uri=http://127.0.0.1:8079/defaults/watermelon/Manifest.mpd

You can then input new bandwidth values, in bytes per second.

-- 
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.


More information about the gstreamer-bugs mailing list