multiqueue: limit queueing to absolute minimum when dealing with single stream
Submitted by Carlos Rafael Giani
Link to original bug (#779069)
Description
Run this test pipeline:
GST_DEBUG=2,*decodebin3*:9 gst-launch-1.0 concat name=x ! decodebin3 ! fakesink sync=true silent=false urisourcebin uri=file://$(pwd)/test-1000ms-48000hz.wav ! identity ! x. urisourcebin uri=file://$(pwd)/test-1000ms-48000hz.wav ! identity ! x. -v
From the logs and the verbose fakesink output you can then see that from the time decodebin3 to the time fakesink see the stream-start event, about 300ms pass.
(You can use audiotestsrc to generate test-1000ms-48000hz.wav like this: audiotestsrc num-buffers=1 samplesperbuffer=48000 ! "audio/x-raw, rate=48000, format=S16LE, channels=1" ! wavenc ! filesink location=test-1000ms-48000hz.wav
)
multiqueue's max-size-time size is set to a pretty high value (250ms) for a single stream. One improvement that was suggested by thaytan was this:
--- a/plugins/elements/gstmultiqueue.c
+++ b/plugins/elements/gstmultiqueue.c
@@ -1279,7 +1279,8 @@ calculate_interleave (GstMultiQueue * mq)
interleave = high - low;
/* Padding of interleave and minimum value */
/* FIXME : Make the minimum time interleave a property */
- interleave = (150 * interleave / 100) + 250 * GST_MSECOND;
+ if (mq->nbqueues > 1)
+ interleave = (150 * interleave / 100) + 250 * GST_MSECOND;
/* Update the stored interleave if:
* * No data has arrived yet (high == low)
However, as he said: "I don't want to break a case where we don't have any interleave and it causes a deadlock waiting to request a 2nd pad that would then have allowed interleave."
So I opened this bugreport for discussing this.