[Bug 793607] New: aggregator: flushing state never resets with a tee

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 793607
           Summary: aggregator: flushing state never resets with a tee
    Classification: Platform
           Product: GStreamer
           Version: 1.13.1
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: fzwoch at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

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.

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