[gst-devel] Scheduler requirements
in7y118 at public.uni-hamburg.de
Mon Mar 15 08:29:29 CET 2004
Quoting David Schleef <ds at schleef.org>:
> I'd prefer the definition that "no buffers are in flight". I.e., no
> buffers are currently held by the scheduler in bufpens.
That's the definition I'D aim for, too.
> Relinking in PAUSED is a lot easier, since a switch to PAUSED happens
> between iterations, meaning there are no buffers wedged between
1) Currently state changes can happen during iterations - think signal
callbacks and EOS/ERROR.
2) Having to pause an element just to change something is extremely bad for
stuff like autoplugging. You always need to pause the autoplugger when a new
SOMETIMES pad arrives just to go on plugging.
I've had in mind allowing plugging at any time (though that might become
interesting wrt request pads) and allowing the scheduler to disallow
unplugging while PLAYING and probably even in PAUSED.
The problem here is the following:
Imagine a pipeline like this: ... ! loopbased ! chainbased ! ... where the
scheduler decided to schedule the loopbased and the chainbased element in the
same cothread. Further imagine that the chainbased element pushes lots of
buffers from its chain function before returning. If you now happen to unlink
those two elements while the chainbased element is in the process of
outputting buffers, the cothread will end up with a stack that calls into the
chainbased element and returns to the loopbased element though they aren't
And I don't know how to solve that without giving every element its own
More information about the gstreamer-devel