[gst-devel] Scheduler requirements
wingo at pobox.com
Fri Mar 26 08:19:00 CET 2004
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
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>
More information about the gstreamer-devel