GNOME Bugzilla – Bug 771479
streamsynchronizer: Setting invalid segment.base if SEEK events are handled in parallel and some streams are finished flushing before others started
Last modified: 2018-11-03 11:49:59 UTC
Problem here is that we send steps only to the video sink, which makes sense. BUFFERS format makes no sense for audio, but for video it is frames. That however causes the audio sink to not move anywhere, which has to negative side effects: 1) in reverse mode, this means that the video position goes backwards with every step but audio stays the same. The position query returns the maximum of all values, so it always returns the (constant) audio position 2) in general, we move video but not audio. After a while queues run full and we lock up because the audio did not consume any data at the same time. My idea for a solution here is to keep track of how much video we stepped (position queries and the step messages), and then do a TIME step on the audio sink in the same way to catch up. And only then forward the step-done message.
That it already does, but there are other problems. I have a fix but need to debug it a little bit more.
Created attachment 335858 [details] [review] basesink: Use timestamp based running time instead of element start time This is not correct, but it works around the problem of flush events happening in the middle of a step event, which breaks running time calculations and causes the step event to step for a huge amount usually.
So the problem here is basically https://bugzilla.gnome.org/show_bug.cgi?id=750013#c15 and https://bugzilla.gnome.org/show_bug.cgi?id=760408 When streamsynchronizer gets a flush-stop, it takes over the group start time from the furthest non-flushes stream. This generally works fine if SEEK events are handled by a single demuxer, and it flushes all streams one after another before it starts again. However in GES (or when using multiple uridecodebins), this is not the case. We then end up with the group start time after a flushing seek to be either a) the old one, or b) some random value based on where we're at at this point. The solution for this seems to be to ensure that a flushing seek in streamsynchronizer always blocks and serializes all the flush-stop events. This however can lead to deadlocks in the multiple uridecodebins case, or when only some but not all streams are seeked (as seeks are per stream, but we need to combine all here). It also doesn't handle properly if there is a new seek while the current one is still being handled (sidenote: aggregator seems to fail on that too). We also can't just reset the group start time whenever a single flush-stop is received, as some streams might already/still be running while others are being flushed currently... and we might end up with wrong values then for the segment events.
commit 0c151f6bb27b3261a0a813720bbcb1fa9e9c7279 Author: Sebastian Dröge <sebastian@centricular.com> Date: Tue Sep 20 15:12:22 2016 -0400 streamsynchronizer: Correctly calculate group start times in reverse playback mode We have to calculate from the segment.stop, not the segment.start, as playback goes from stop to start. This fix works around another race condition in streamsynchronizer in my testcase. See https://bugzilla.gnome.org/show_bug.cgi?id=771479 Still the original bug is valid.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/293.