[gst-devel] Scheduler requirements

[Martin Soto]

Hi David:

On Sun, 2004-03-14 at 01:04, David Schleef wrote:
[...]
> Yes. no. bad things.
[...]
> No.
[...]
> No.
[...]
> 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
> function.)
> 
> In this situation, the scheduler will never be able to finish an
> iteration, since each loop function leaves the other element
> "unfinished".

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.

M. S.
-- 
Martin Soto <soto at informatik.uni-kl.de>