aggregator: flushing state never resets with a tee

Submitted by Florian Zwoch @fzwoch

Link to original bug (#793607)

Description

Actually I noticed with 1.12.4 - But looking at the code makes me belief this affects 1.13.x as well.

I'm not 100% sure how flushing works in detail, so maybe help me out here. But I made an element based on GstAggregator and it works just fine so far. I noticed that seeking is broken when I attach a tee element downstream to the aggregator.

The basic use case is to listen on the bus for an EOS, and then seeking back to the start (with flushing). But I think it also happened when I tried a regular seek while in PAUSED.

The result is that the aggregator is processing data just fine but does not output any more data after the first seek.

A little bit of tracing lead me to this code:

(gstaggregator.c:1985)
if (flush) {
priv->pending_flush_start = TRUE;
priv->flush_seeking = TRUE;
}

[..]

(gstaggregator.c:2004)
if (!evdata.result || !evdata.one_actually_seeked) {
GST_OBJECT_LOCK (self);
priv->flush_seeking = FALSE;
priv->pending_flush_start = FALSE;
GST_OBJECT_UNLOCK (self);
}

So when I have a tee downstream I do get two seek events (correct?). The first one seems to work just fine - the second one however has much less debug log (not doing any flushing?).

Basically the second seek was a success (evdata.result == 1) but I think evdata.one_actually_seeked was also 1 because after that point I kept hitting this:

(gstaggregator.c:555)
GST_INFO_OBJECT (self, "Not pushing (active: %i, flushing: %i)",
self->priv->flush_seeking, gst_pad_is_active (self->srcpad));

with "active: 1, flushing: 1". Which indicates that "priv->flush_seeking = FALSE;" was not hit again, leaving its state in flush_seeking.

To verify I boldly moved the "priv->flush_seeking = FALSE;" line out of the brackets so it gets set regardless of the results and it did "fix" my original problem.

Surely this is not the correct fix, but maybe your understanding is much better and you already have an idea what may cause this behavior in case a tee is present downstream?

I can attach some traces for this particular case - just lacking access to the right machine.

Version: 1.13.1