[gst-devel] Scheduler requirements

[Andy Wingo]

On Sun, 2004-03-14 at 15:18, Martin Soto wrote:
> > [...]
> > 
> > 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 agree. And the current schedulers do live with this, pretty well.

> > 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.
> ;-)

When you know that each element is going to process one buffer over each
iteration, you can optimize by making a sorted list of functions to
call. Iterating the pipeline becomes a matter of calling that list in
order.

So I see the need for that option, but I don't understand what's so bad
about the scheds now. Sure, bufpens make things tricky. But they work,
and allow more flexible plugins.

> 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.

I agree on the need for agreement :)
-- 
Andy Wingo <wingo at pobox.com>