[gst-devel] Scheduler requirements

[Benjamin Otte]

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
> elements.
> 
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 
connected anymore.
And I don't know how to solve that without giving every element its own 
cothread.

Benjamin