[Bug 733235] decodebin:Handle the multi-queue size flexible

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Tue Sep 1 03:02:53 PDT 2015


https://bugzilla.gnome.org/show_bug.cgi?id=733235

--- Comment #59 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
So not sure what to do about this.

Currently we set the limits to the playing limits on no-more-pads/overrun and
then wait for caps. Which can easily lead to waiting forever for caps, while we
would get caps if we just kept the preroll limits a bit longer. It is also
completely non-deterministic as we might or might not get enough data until the
point when the playing limits are set thanks to things happening in other
threads.

Immediately exposing pads on overrun and ignoring all pads that have no caps
yet leads to the problem that it often we don't expose pads just because the
caps events did not travel far enough yet downstream of the multiqueue before
the multiqueue was running full upstream.

Not waiting for caps would break applications that expect decodebin and friends
to have caps immediately on the pads they add. And there are many.

Also the way how things are right now, the overrun case seems mostly useless.
It doesn't change anything, pads are still not considered ready to be exposed
because of the overrun but we're waiting for caps on all of them.


Independent of that, just increasing the preroll limits does not solve anything
unless you're lucky with how timing works. The extra buffering patches in this
bug changed timing in a way that made some test streams work relatively
reliable, but that's obviously not a real solution :)

I think what should happen regarding the buffering is that there are (higher)
preroll limits that are kept until we are actually starting to output data
(conflict with bug #740689), and then the new playing limits are based on some
minimum value and the current queues fill levels.


All this is relatively intrusive, so not sure if anything will happen here at
all before 1.6. Unless someone has a great idea :)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list