multiqueue: limit queueing to absolute minimum when dealing with single stream
Submitted by Carlos Rafael Giani
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:
@@ -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.