[gst-devel] Scheduler requirements

[David Schleef]

On Sat, Mar 13, 2004 at 11:08:00AM +0100, Martin Soto wrote:
> > Specifying these three conditions should make the differences between
> > schedulers irrelevant. Their differences would only be in the numbers
> > and kinds of bugs that they have.
> 
> There is at least another area that, IMO, should be disambiguated.
> Namely, the exact scheduler behavior with respect to loop, chain and get
> based elements. I have a number of questions here:
> 
> - Do chain and loop based modes of operation exclude each other? So, for
> example, is it possible for a loop based element to have sink pads with
> chain functions? If so, what happens when the loop function tries to
> pull a buffer from such a pad?

Yes. no. bad things.

> - Is a chain function allowed at all to invoke gst_pad_pull? If so,
> under which conditions is that supposed to work?

No.

> - Where are get functions allowed? Can all elements have source pads
> with a get function, or just source elements?

In source elements only.

> - Is a get function allowed to invoke gst_pad_push?

No.

> - Can a loop or chain function invoke gst_pad_push in a pad having a get
> function? What happens in this case?

No.  Bad things.

> Another, separate question I have is related to loop functions. Are loop
> functions allowed to run once for a whole stream, or are they expected
> to return every once in a while. I think the answer to this question has
> large repercussions in the way schedulers can be implemented. Namely,
> allowing loop functions that don't return implies, as far as I can see,
> that you need at least cothreads/coroutines to implement a scheduler.

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".  I would prefer that loop functions push or pull a
maximum of one buffer per iteration.

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.



dave...