[gst-devel] Scheduler requirements

[Martin Soto]

Hello Andy:

Thanks for bringing up this issue. I was thinking of writing up my own
thoughts on the subject, but you certainly have much more experience
with the topic than I do.

On Wed, 2004-03-10 at 18:28, Andy Wingo wrote:
> Someone was asking recently (Martin?) about the requirements for
> schedulers. This is an outline of what needs to be specified, as well as
> a draft specification.
> 
> A scheduler in GStreamer has an interface, defined by the abstract base
> type GstScheduler. All schedulers must implement this interface fully.
> (Note that this condition is not fulfilled by any scheduler at the
> moment.)
> 
> The scheduler is what allows a network to run. A network is defined by
> elements and connections. The scheduler must run, in the sense of
> gst_scheduler_iterate, only during the PLAYING state.
> 
> One ambiguity is when (meaning "in what state") can a pad be linked or
> unlinked. The opt scheduler allows this to occur during PLAYING, but the
> basic one only allows this during PAUSED and before. Thoughts? I'm
> leaning towards linking and unlinking in any state.

For certain applications (specially stuff related to real time
streaming) hot linking and unlinking could be very useful. I didn't find
it useful for DVD playing, though, and ended up writing elements that
allow me to have a (sort of) fixed pipeline, but that's just a
particular case.

> Another ambiguity is regarding pipeline iteration: what does it mean to
> iterate a pipeline? I propose that this mean that a terminal sink in the
> pipeline (an element that does not push) process one buffer, or exit
> from the loop function if the terminal group is loop-based.
> 
> 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?

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

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

- Is a get function allowed to invoke gst_pad_push?

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

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.

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