GNOME Bugzilla – Bug 600269
Gstreamer's Queue will leak Events in LEAK_DOWNSTREAM mode
Last modified: 2009-11-03 16:56:34 UTC
While perusing the source code of Queue, I noticed that leak_downstream() appears to leak Buffers and Events: http://cgit.freedesktop.org/gstreamer/gstreamer/tree/plugins/elements/gstqueue.c#n884 Notice that the value of is_buffer is never checked, so Events could easily be dequeued. However, I have been told that even a leaking Queue should never lose an Event. Either the code is incorrect, the documentation is misleading, or I am just not understanding the situation.
It should not leak events
OK. Unfortunately, I'm not enough of a gstreamer expert to know how to test this, but I strongly suspect that events will be leaked in LEAK_DOWNSTREAM mode, if the element at the downstream end of the queue is running slower than real time, causing frequent queue leaking.
Hard to fix, in some cases we do need to drop events as well (segment accumulation event), in other cases we shouldn't. I would suggest to not use the leaky options on queue as they are broken and not needed in a properly functioning pipeline.
Interesting. I presume you mean that a properly functioning pipeline would use QoS messages to achieve the desired effect without leakiness? For the record, I was reading the code while implementing leakiness in Cortado's jst Queue plugin [1]. I suppose QoS would be even better, but jst does not appear to have any support for QoS messages, so that seemed like a much larger project. I suppose that makes this a CANTFIX. [1] http://lists.xiph.org/pipermail/theora-dev/2009-October/004005.html
wtay, can't we check the type and iterate until we find a buffer (there is g_queue_pop_nth() ).