From 08df711c0cfbbf29dd4813ed94afde3fcbd1fb21 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Olivier=20Cr=C3=AAte?= Date: Fri, 6 Mar 2015 19:50:08 -0500 Subject: [PATCH] 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 --- gst/audiomixer/gstaudioaggregator.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gst/audiomixer/gstaudioaggregator.c b/gst/audiomixer/gstaudioaggregator.c index b7e5cff674..351b1d70a4 100644 --- a/gst/audiomixer/gstaudioaggregator.c +++ b/gst/audiomixer/gstaudioaggregator.c @@ -723,7 +723,7 @@ gst_audio_aggregator_do_clip (GstAggregator * agg, bpf = GST_AUDIO_INFO_BPF (&pad->info); GST_OBJECT_LOCK (bpad); - *out = gst_audio_buffer_clip (buffer, &bpad->segment, rate, bpf); + *out = gst_audio_buffer_clip (buffer, &bpad->clip_segment, rate, bpf); GST_OBJECT_UNLOCK (bpad); return GST_FLOW_OK;