aggregator: Query the peer latency again on the next opportunity after a pad was...
authorSebastian Dröge <sebastian@centricular.com>
Tue, 28 Jul 2015 18:15:43 +0000 (21:15 +0300)
committerTim-Philipp Müller <tim@centricular.com>
Sat, 2 Dec 2017 15:10:26 +0000 (15:10 +0000)
commit9ab98e9b225c1b9b4f7e5145589a85c57b1f04a2
treeb329f334b70a2dee315fab085476f336f6ee0ef7
parent07247f01ca001d85ffc9f97923aa2305d2dc7bca
aggregator: Query the peer latency again on the next opportunity after a pad was added or removed

Adding a pad will add a new upstream that might have a bigger minimum latency,
so we might have to wait longer. Or it might be the first live upstream, in
which case we will have to start deadline based aggregation.

Removing a pad will remove a new upstream that might have had the biggest
latency, so we can now stop waiting a bit earlier. Or it might be the last
live upstream, in which case we can stop deadline based aggregation.
libs/gst/base/gstaggregator.c