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>
{
SRC_LOCK (self);
PAD_LOCK (aggpad);
- g_assert (aggpad->priv->num_buffers == 0);
aggpad->priv->eos = TRUE;
PAD_UNLOCK (aggpad);
SRC_BROADCAST (self);
}
case GST_EVENT_STREAM_START:
{
+ PAD_LOCK (aggpad);
+ aggpad->priv->eos = FALSE;
+ PAD_UNLOCK (aggpad);
goto eat;
}
case GST_EVENT_GAP: