GNOME Bugzilla – Bug 719893
multiqueue: spams overrun signal
Last modified: 2014-01-24 13:27:17 UTC
multiqueue emits the overrun signal as soon as the buffer limit is reached, instead of waiting until the hard limits (bytes or time) are reached. This behavior was introduced by commit 17bff49262489950e40f6775e9ba0d2b574537bf. That results in the signal spamming and not filling it's purpose.
Created attachment 263572 [details] [review] Suggested patch for the problem.
Review of attachment 263572 [details] [review]: I don't think this is correct. Now you'll only ever emit the signal for bytes/time overruns, not buffer overruns.
(In reply to comment #2) > Review of attachment 263572 [details] [review]: > > I don't think this is correct. Now you'll only ever emit the signal for > bytes/time overruns, not buffer overruns. I think we should then start by determine what the purpose of the overrun signal is. What use case is it supposed to solve. As I see it overrun should be used to handle the case where the pipeline might deadlock. For example when one queue is full while an other is empty, and a muxer with collect pads are waiting for buffers from both before continuing. If overrun is emitted as soon as one queue reaches it's buffer limit, overrun will be spammed when the source produces buffers faster than the sink consumes them.
That's the use case, yes. For example decodebin uses it to detect when it should stop waiting for the no-more-pads signal and declare a demuxer as finished and not adding more streams. Why would you handle the buffers limit different to the other two limits? I think you can get this spamming behaviour with the other limits too easily. The main difference with the buffers limit is that it is not fixed and can grow in the beginning.
Comment on attachment 263572 [details] [review] Suggested patch for the problem. As discussed on IRC this does not seem to make much sense, but there's something broken here somewhere still :(
Created attachment 265521 [details] [review] diff This at least handles the case correctly when all other pads are not linked. But that shouldn't be the problem of this bug.
Might make sense to change the queue_is_empty() check to a queue_get_length() < X, where X is a configurable value.
Comment on attachment 265521 [details] [review] diff commit c343ebd454e0e5846f6d5b3a22ed0dd3ffdd98e8 Author: Sebastian Dröge <sebastian@centricular.com> Date: Wed Jan 8 09:53:09 2014 +0100 multiqueue: Allow growing a queue if all other queues are not linked See https://bugzilla.gnome.org/show_bug.cgi?id=719893
Closing, related discussion happening in bug #722900