[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