aggregator: don't try to take STREAM_LOCK on sink pad flush

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.
This commit is contained in:
Mathieu Duponchelle 2019-06-11 22:09:33 +02:00
parent 4087361da3
commit 6d16615093

View 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