GNOME Bugzilla – Bug 762875
queue: unsatisfied min-threshold-time blocks ALLOCATION query, resulting in stalled pipeline after deinterlace's RECONFIGURE event
Last modified: 2018-03-01 21:36:31 UTC
We use pipelines with capsfilter caps-change-mode=1 where we dynamically change the frame rate of pipeline parts. This worked well with a build back from November '15, but is currently broken. I'll provide more information later.
I was able to bisect the issue (we use deinterlace upstream of capsfilter): 2e8d4e8c7a7c24af7301793d32b77f4ec5d2d75c is the first bad commit commit 2e8d4e8c7a7c24af7301793d32b77f4ec5d2d75c Author: Sebastian Dröge <sebastian@centricular.com> Date: Tue Jan 26 17:50:30 2016 +0100 deinterlace: Implement reconfiguration a bit better And e.g. consider reconfiguration caused by RECONFIGURE events too. https://bugzilla.gnome.org/show_bug.cgi?id=720388
Created attachment 322757 [details] reproducing test case simple test application that reproduces the stalling pipeline
Created attachment 322758 [details] *:6 debug logs of test application
Created attachment 322759 [details] deinterlace:6 debug logs of test application
Created attachment 322760 [details] stack trace of ALLOCATION query that is stuck in queue
I was able to reproduce the issue outside of our application (see test application attachment posted previously). Turns out that the actual problem is that an allocation query is stuck in a queue that has min-threshold-time set to something, and where currently not enough data is held by the queue. I assume that the deinterlace commit that I found during bisecting just triggers the ALLOCATION query. The test application reproduce the issue: It will launch a pipeline where every 3 seconds the frame rate is changed from 10/1 to 25/1. After launch it is immediately set to 10/1, then it should switch back to 25/1, but it will stall instead. Note that if you remove the min-threshold-time property in the test application, everything works fine. I have also attached a stack-trace of the stalled test application. See thread #3 for the allocation query that is stuck.
The problem is that the code to ignore the threshold was ignored if the head of the queue was a query.. but the query got added to the queue. I think it's a regression from one of the refactoring that happened, so I added a unit test to prevent futurue problems. commit 23b32d56008d364257d1d186da52650cb4475aa4 (HEAD -> master, upstream/master) Author: Olivier Crête <olivier.crete@collabora.com> Date: Thu Mar 1 16:19:09 2018 -0500 queue: Ignore thresholds if a query is queued The queue gets filled by the tail, so a query will always be the tail object, not the head object. Also add a _peek_tail_struct() method to the GstQueueArray to enable looking at the tail. With unit test to prevent future regression. https://bugzilla.gnome.org/show_bug.cgi?id=762875