From 205034dea9dfa85436288d08770a434d984a73e9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Sebastian=20Dr=C3=B6ge?= Date: Mon, 18 Jul 2022 15:46:21 +0300 Subject: [PATCH] aggregator: Reset EOS flag after receiving a stream-start event And also don't assert that there are no buffers queued up when handling an EOS event. The pad's streaming thread might've already received a new stream-start event and queued up a buffer in the meantime. This still leaves a race condition where the srcpad task sees all pads in EOS state and finishes the stream, while shortly afterwards a pad might receive a stream-start event again, but this doesn't seem to be solveable with the current aggregator design. Part-of: --- subprojects/gstreamer/libs/gst/base/gstaggregator.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/subprojects/gstreamer/libs/gst/base/gstaggregator.c b/subprojects/gstreamer/libs/gst/base/gstaggregator.c index a970c51357..54d19e4651 100644 --- a/subprojects/gstreamer/libs/gst/base/gstaggregator.c +++ b/subprojects/gstreamer/libs/gst/base/gstaggregator.c @@ -1707,7 +1707,6 @@ gst_aggregator_default_sink_event (GstAggregator * self, { SRC_LOCK (self); PAD_LOCK (aggpad); - g_assert (aggpad->priv->num_buffers == 0); aggpad->priv->eos = TRUE; PAD_UNLOCK (aggpad); SRC_BROADCAST (self); @@ -1734,6 +1733,9 @@ gst_aggregator_default_sink_event (GstAggregator * self, } case GST_EVENT_STREAM_START: { + PAD_LOCK (aggpad); + aggpad->priv->eos = FALSE; + PAD_UNLOCK (aggpad); goto eat; } case GST_EVENT_GAP: