[Bug 771479] streamsynchronizer: Setting invalid segment.base if SEEK events are handled in parallel and some streams are finished flushing before others started

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=771479

--- Comment #3 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.