[gst-devel] Scheduler requirements

[Andy Wingo]

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.

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.

***

It would be interesting to implement a bus-based element network. That
is, pushing from a pad would put a buffer in a slot on a bus, and
pulling from a pad copies the buffer from the proper slot. That way
scheduling would, for well-behaved elements, simply consist of calling a
list of functions in the proper order. Clearly this is not
general-purpose, as it operates more along clock-tick lines. But of
course special-purpose schedulers are still allowed.
-- 
Andy Wingo <wingo at pobox.com>