There could be a race where the new segments were pushed after
a seek on some / all pads before the operation had had its basetime
updated, and thus incoming segments were tweaked wrongly.
Reproducible with 3 clips composited and multiple seeks,
FIXME hard to validate.
Avoiding races where we would launch a seek right after a FLUSH_STOP and
before we get a Buffer which would possibly lead to ERROR message when upstream
elements try to push a buffer and check_sticky fails because downstream
is flushing.
* In the action closure invokation we were alway leaking the composition.
* gst_bin_add will actually take an extra ref since we already gst_object_ref_sink so we
own the object, other call to that method will increase the refcount which means we do
not need to pass an extra ref to the bin.
* We want to ref_sink right when the object is added to the composition, making things
cleaner and simpler to follow in the tests.
Since commit 060b16ac75
"pad: don't accept flush-stop on inactive pads" in -core, the flush_stop event will not be
fowarded downstream in case the pad is not activated. In our case the element is in
READY state, so pads are deactivated. In that commit we simply make sure that the
event can be fowarded downstream
It means stop using a dedicated probe to restart task so that the main probe does not
drop the FLUSH_STOP event before we have a chance to restart the task. (and this is
for sure cleaner/and simpler to read).
