aggregator: don't try to take STREAM_LOCK on sink pad flush
authorMathieu Duponchelle <mathieu@centricular.com>
Tue, 11 Jun 2019 20:09:33 +0000 (22:09 +0200)
committerMathieu Duponchelle <mathieu@centricular.com>
Tue, 11 Jun 2019 20:09:33 +0000 (22:09 +0200)
This was a misguided effort to try and guarantee the buffers of
the sink pads would not change during aggregate, when an upstream
branch is seeked independently, however this is simply incorrect
as downstream has not necessarily been flushed, or the aggregate
function might be waiting to receive buffers on other pads.

libs/gst/base/gstaggregator.c

index 32f64e9..079dd0b 100644 (file)
@@ -1410,13 +1410,7 @@ gst_aggregator_default_sink_event (GstAggregator * self,
       aggpad->priv->last_flush_stop_seqnum = seqnum;
       PAD_UNLOCK (aggpad);
 
-      /* aggregate might be running if this FLUSH_STOP was not
-       * sent following a flushing seek, let's make sure we don't
-       * flush the pad's current buffer before aggregate has returned
-       */
-      GST_PAD_STREAM_LOCK (self->srcpad);
       gst_aggregator_pad_flush (aggpad, self);
-      GST_PAD_STREAM_UNLOCK (self->srcpad);
 
       GST_OBJECT_LOCK (self);
       if (priv->flushing