GNOME Bugzilla – Bug 779069
multiqueue: limit queueing to absolute minimum when dealing with single stream
Last modified: 2018-11-03 12:39:40 UTC
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.
lgtm
I am still wondering what the behaviour should be in that case - really, we could reduce down to 1 buffer in the single stream case. We still need a story about how to do gapless playback into decodebin3, but the multiqueue was never about buffering enough to make that feasible, so I think it's OK to shrink it. What I don't want to do is introduce a stall when a 2nd stream is added dynamically - so we might need to recalculate interleave on a new pad request and on release to accomodate switching from single stream to multiple and vice versa?
fwiw, the minimum interleave period is now configurable via properties. This issue is still valid imho.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/222.