[gst-devel] Scheduler requirements
soto at informatik.uni-kl.de
Sun Mar 14 05:15:04 CET 2004
On Sun, 2004-03-14 at 01:04, David Schleef wrote:
> Yes. no. bad things.
> No. Bad things.
I agree with you. Only negative and bad things can be expected from such
evil actions as I described. It's a relief that I'm not the only one to
think that way.
> Bad things happen if loop functions push too many buffers. asfdemux
> does this, which means that a lot of things don't work. Consider the
> case of a pipeline with two loop elements A and B:
> ... ! A ! B ! ...
> and that A pushes two buffers per iteration. Also assume that
> B pulls one buffer in its first iteration, and two buffers per iteration
> after that. (I'm calling "iteration" as being one call to the loop
> In this situation, the scheduler will never be able to finish an
> iteration, since each loop function leaves the other element
Is it really that bad that elements remain "unfinished" after a
scheduler iteration? I don't see why. IMO, schedulers should be able
live with that.
> I would prefer that loop functions push or pull a
> maximum of one buffer per iteration.
In which case they would be just glorified chain functions. If you're
going to impose such a restriction, you can just as well get rid of loop
functions completely. Don't call me to fix the broken plugins, though.
> Actually, I'm in favor of tightening a lot of restrictions on elements.
> Erik always wanted to write a complex core that allows one to write
> really crappy plugins (since several years ago, lots of libraries were
> quite crappy). I think that model has failed.
Well, in fact we should start by defining it properly. Actually, it
seems everyone has a slightly (or even not that slightly) different idea
of what an element should and shouldn't be allowed to do. We need first
to reach an agreement in that area, I guess.
Martin Soto <soto at informatik.uni-kl.de>
More information about the gstreamer-devel