GNOME Bugzilla – Bug 707648
queue2: Update the buffering state before stalling for more data
Last modified: 2013-09-18 16:51:43 UTC
In some cases the wait for more data was happening without updating the buffering state, meaning the API user would not be able to notice it should pause the pipeline and update UI to indicate that is the case, the video would likely stutter instead.
Created attachment 254296 [details] [review] Update the buffering state before stalling for more data
Created attachment 254298 [details] Test case This is a test case I am using to test clutter-gst 3.0 buffering behaviour. It should assert if it stops to buffer a second time, but that won't happen without the patch, because queue2 never realizes it needs to buffer, since the information it uses to decide is outdated.
commit 4cb596ddd6919701744387339e9a957a6f71b2b6 Author: Gustavo Noronha Silva <gns@gnome.org> Date: Fri Sep 6 15:09:46 2013 -0300 Update the buffering state before stalling for more data In some cases the wait for more data was happening without updating the buffering state, meaning the API user would not be able to notice it should pause the pipeline and update UI to indicate that is the case, the video would likely stutter instead. https://bugzilla.gnome.org/show_bug.cgi?id=707648
This patch introduces a crash: gst-launch-1.0 queue2 use-buffering=1 max-size-buffers=3
*** Bug 707772 has been marked as a duplicate of this bug. ***
commit b25b9ad6bda052d013a5531f7fe43f84256117b7 Author: Sebastian Dröge <slomo@circular-chaos.org> Date: Tue Sep 10 10:15:03 2013 +0200 queue2: Only update current level if we already downloaded a range Otherwise queue->level is NULL and dereferencing that is not a good idea in general. https://bugzilla.gnome.org/show_bug.cgi?id=707648
FWIW, there is some suspicion this patch may have caused issues for aurena - it would simply not play - but I have not been able to reproduce.
Gustavo, see bug #707530. Unrelated to this change