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.
This commit is contained in:
Sebastian Dröge 2015-07-28 21:15:43 +03:00 committed by Tim-Philipp Müller
parent 07247f01ca
commit 9ab98e9b22

View file

@ -1099,6 +1099,7 @@ gst_aggregator_release_pad (GstElement * element, GstPad * pad)
gst_aggregator_pad_set_flushing (aggpad, GST_FLOW_FLUSHING);
gst_element_remove_pad (element, pad);
self->priv->has_peer_latency = FALSE;
SRC_BROADCAST (self);
SRC_UNLOCK (self);
}
@ -1143,6 +1144,7 @@ gst_aggregator_request_new_pad (GstElement * element,
}
GST_DEBUG_OBJECT (element, "Adding pad %s", GST_PAD_NAME (agg_pad));
self->priv->has_peer_latency = FALSE;
if (priv->running)
gst_pad_set_active (GST_PAD (agg_pad), TRUE);