aggregator: don't hold stream lock when flushing

Releasing a GRecMutex from a different thread is undefined
behaviour.

There should be no reason to hold the stream lock from the
moment aggregator receives a flush_start until it receives
the last flush_stop: the source pad task is stopped, and can
only be restarted once the last flush_stop has arrived.

I can only speculate as to the reason why this was done,
as it was that way since the original commit. My best
guess is that aggregator originally didn't marshall events
and queries to the aggregate thread, and this somehow
helped work around this.
This commit is contained in:
Mathieu Duponchelle 2019-06-10 17:23:29 +02:00
parent 25383eaa5c
commit c55c61eb84

View file

@ -1335,10 +1335,6 @@ gst_aggregator_flush_start (GstAggregator * self, GstAggregatorPad * aggpad,
GST_INFO_OBJECT (self, "Flushing, pausing srcpad task"); GST_INFO_OBJECT (self, "Flushing, pausing srcpad task");
gst_aggregator_stop_srcpad_task (self, event); gst_aggregator_stop_srcpad_task (self, event);
GST_INFO_OBJECT (self, "Getting STREAM_LOCK while flushing");
GST_PAD_STREAM_LOCK (self->srcpad);
GST_LOG_OBJECT (self, "GOT STREAM_LOCK");
event = NULL; event = NULL;
} else { } else {
gst_event_unref (event); gst_event_unref (event);
@ -1436,9 +1432,7 @@ gst_aggregator_default_sink_event (GstAggregator * self,
SRC_BROADCAST (self); SRC_BROADCAST (self);
SRC_UNLOCK (self); SRC_UNLOCK (self);
GST_INFO_OBJECT (self, GST_INFO_OBJECT (self, "Flush stopped");
"Flush stopped, releasing source pad STREAM_LOCK");
GST_PAD_STREAM_UNLOCK (self->srcpad);
gst_aggregator_start_srcpad_task (self); gst_aggregator_start_srcpad_task (self);
} else { } else {