[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