Skip to content

aggregator: Always handle serialized events/queries directly before waiting

Otherwise it can happen that we start waiting for another pad, while one pad already has events that can be handled and potentially also a buffer that can be handled. That buffer would then however not be accessible by the subclass from GstAggregator::get_next_time() as there would be the events in front of it, which doesn't allow the subclass then to calculate the next time based on already available buffers.

As a side-effect this also allows removing the duplicated event handling code in the aggregate function as we'll always report pads as not ready when there is a serialized event or query at the top of at least one pad's queue.

Fixes #428 (closed)


CC @meh, @thiblahute

With this my tests are running reliable for 10 minutes or more in a loop.

Merge request reports