[Bug 763757] multiqueue: Make sure mq->percent remains valid after modifying high-percent value
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Fri Apr 15 13:05:22 UTC 2016
https://bugzilla.gnome.org/show_bug.cgi?id=763757
Sebastian Dröge (slomo) <slomo at coaxion.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #11 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
commit 3bd5aeac52a7e88860270a3e4a460409d68b50cd
Author: Carlos Rafael Giani <dv at pseudoterminal.org>
Date: Thu Apr 14 11:54:32 2016 +0200
multiqueue: Recheck buffering status after changing low threshold
https://bugzilla.gnome.org/show_bug.cgi?id=763757
commit a1d2f387c60e3bc9da93ddd0cf976fad96d53b95
Author: Carlos Rafael Giani <dv at pseudoterminal.org>
Date: Thu Apr 14 00:09:44 2016 +0200
multiqueue: Recalculate fill level after changing high-threshold
This ensures the following special case is handled properly:
1. Queue is empty
2. Data is pushed, fill level is below the current high-threshold
3. high-threshold is set to a level that is below the current fill level
Since mq->percent wasn't being recalculated in step #3 properly, this
caused the multiqueue to switch off its buffering state when new data is
pushed in, and never post a 100% buffering message. The application will
have received a <100% buffering message from step #2, but will never see
100%.
Fix this by recalculating the current fill level percentage during
high-threshold property changes in the same manner as it is done when
use-buffering is modified.
https://bugzilla.gnome.org/show_bug.cgi?id=763757
--
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