aggregator: Reset EOS flag after receiving a stream-start event
authorSebastian Dröge <sebastian@centricular.com>
Mon, 18 Jul 2022 12:46:21 +0000 (15:46 +0300)
committerSebastian Dröge <sebastian@centricular.com>
Mon, 18 Jul 2022 12:46:21 +0000 (15:46 +0300)
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: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2769>

subprojects/gstreamer/libs/gst/base/gstaggregator.c

index a970c51..54d19e4 100644 (file)
@@ -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: