[gst-devel] Scheduler requirements

[Benjamin Otte]

Quoting Martin Soto <soto at informatik.uni-kl.de>:

> 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.
> 
My view has always been that calling _push or _pull means the element gives 
control to the rest of the world - which could mean its pads get unconnected, 
reconnected, states get changed or whatever. The element should certainly be 
able to cope with this.
Apart from this schedulers have a way to get out of such a situation. Someone 
invented GstEventInterrupt for this purpose.

> > 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.
> ;-)
> 
In my view a loopbased element should try to do as little and as flexible as 
possible pushing or pulling in one iteration, but if that's not possible the 
core should somehow be able to handle that.
(mod players will probably read the whole file in their first iteration 
forever, unless someone writes a new modplayer)


Benjamin