The Optimal Scheduler

The optimal scheduler takes advantage of the fact that several elements can be linked together in one thread, with one element controlling the other. This works as follows: in a series of chain-based elements, each element has a function that accepts one piece of data, and it calls a function that provides one piece of data to the next element. The optimal scheduler will make sure that the gst_pad_push () function of the first element directly calls the chain-function of the second element. This significantly decreases the latency in a pipeline. It takes similar advantage of other possibilities of short-cutting the data path from one element to the next.

The disadvantage of the optimal scheduler is that it is not fully implemented. Also it is badly documented; for most developers, the opt scheduler is one big black box. Features that are not implemented include pad-unlinking within a group while running, pad-selecting (i.e. waiting for data to arrive on a list of pads), and it can't really cope with multi-input/-output elements (with the elements linked to each of these in-/outputs running in the same thread) right now.

Some of our developers are intending to write a new scheduler, similar to the optimal scheduler (but better documented and more completely implemented).