GNOME Bugzilla – Bug 787405
[REGRESSION] - Seeking in NLE is broken
Last modified: 2017-09-19 15:42:03 UTC
Since https://ci.gstreamer.net/job/Gstreamer-Manifest-Update/9434/ (ie. adding support for allocation query in tee), the GES seeking integration tests fail: https://ci.gstreamer.net/job/GStreamer-master-validate/lastCompletedBuild/testReport/ The tests time out (no deadlock but all thread are waiting).
So far, what I see: - nlecomposition queue an incoming seek - The pipeline is in paused, blocked on wait-for-preroll - Nothing happens Normally, when seeks aren't queued, a flush operation will unblock the preroll, and everything should be fine. Dropping the allocation query (hence not blocking in while executing gst_aggregator_do_allocation() seemed to work, but was of course just hiding an existing bug.
About the task that is supposed to run the seek, it's not running anymore, according to what I read, it's suppose to run always while in READY + state.
Created attachment 359370 [details] [review] WIP Always execute seeks Ignoring the seeks results in stalled pipeline when tee forward the allocation queries. It's possible that all we want is to execute the flush sequence, though don't ask me why this "optimization" was put in place, I can't figure-out. In general, when I run a flushing seek from my application, I expect a flush and a seek to happen.
Created attachment 359873 [details] [review] WIP: nlecomposition: Don't wait for a buffer to start the task If the pipeline is paused, the allocation query may block, hence we may never get a buffer.
Just piling hacks as I'm building knowledge around what this code is doing. So now I think I understand the idea with dropping seeks (which I've disabled in first patch). I think it is to avoid a userless seek that would for sure return EOS. Something like: seek, EOS, change stack, implicit-seek I think it's fine to drop the first seek, but not the associated flush, which won't be forwarded downstream when the "implicit-seek" happens. For the second issue, which gst-validate didn't pick up, but I was seeking in PiTiVi, it's really simple. The audio sink is in paused, there is buffer, caps segment in the queue already and it's blocked on allocation query. The seek is queued, but the task that will exectute this seek is waiting for a buffer (which is the current condition for a stack to be ready). So if I simply assume stack is ready on segment, this situation is avoided. events don't take any "space" in queues, so they should not block on downstream queue. These two event are definitely expected before the allocation query take place.
Created attachment 359877 [details] [review] nlecomposition: Also start task on allocation query The allocation query may block on the sink when in pause. As a side effect, we may never get a buffer now that tee does forward the allocation query. This would often lead in a pipeline stall.
Comment on attachment 359370 [details] [review] WIP Always execute seeks Actually this one is still needed according to gst-validate. I think we need to minimally run the FLUSH, but that's much more complicated then just letting the seek run on the dead stack.
Created attachment 359878 [details] [review] nlecomposition: Always execute seeks We have an optiominisation to avoid double seeks when a seek is passed the end of the current stack. The problem, is that we no longer flush the pipeline when this code is reached. This patch comments out this optimization adding a FIXME. As mention, flushing the stack instead of seeking would work, but does not seem trivial considering all the mechanic inplace to forward or not the events.
I made some minor fixes., Thanks for investigating! Attachment 359877 [details] pushed as faf44ac - nlecomposition: Also start task on allocation query Attachment 359878 [details] pushed as 5dd5b16 - nlecomposition: Always execute seeks