aggregator: Queue "latency" buffers at each sink pad.
authorOlivier Crête <olivier.crete@collabora.com>
Sat, 7 Mar 2015 00:50:08 +0000 (19:50 -0500)
committerTim-Philipp Müller <tim@centricular.com>
Sat, 2 Dec 2017 15:10:26 +0000 (15:10 +0000)
commit22dc57f84ed2f5cdb1013cab94068a3b3034ae79
treeb61ad0a7e99c1f07c1cf744eac650363d5bf2f48
parent5db97caef705c5e556c16dffdfc3cf24fbb4042c
aggregator: Queue "latency" buffers at each sink pad.

In the case where you have a source giving the GstAggregator smaller
buffers than it uses, when it reaches a timeout, it will consume the
first buffer, then try to read another buffer for the pad. If the
previous element is not fast enough, it may get the next buffer even
though it may be queued just before. To prevent that race, the easiest
solution is to move the queue inside the GstAggregatorPad itself. It
also means that there is no need for strange code cause by increasing
the min latency without increasing the max latency proportionally.

This also means queuing the synchronized events and possibly acting
on them on the src task.

https://bugzilla.gnome.org/show_bug.cgi?id=745768
libs/gst/base/gstaggregator.c
libs/gst/base/gstaggregator.h