[gst-devel] Scheduler requirements

[Benjamin Otte]

Quoting David Schleef <ds at schleef.org>:

> > - 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?
> 
> Yes. no. bad things.
>
Actually it's "Yes. Yes, but the chainfunction is ignored. It works just as 
other loopfunctions.", but I prefer your answer ;)
 
> > - Where are get functions allowed? Can all elements have source pads
> > with a get function, or just source elements?
> 
> In source elements only.
> 
I want this changed btw. I think there's a lot to gain (mainly: getting rid of 
memcpy's) if you could pull an exact number of bytes in elements that 
currently use bytestreams.

> > - Can a loop or chain function invoke gst_pad_push in a pad having a get
> > function? What happens in this case?
> 
> No.  Bad things.
> 
I think it's "get functions are ignored on loop- or chainbased elements that 
aren't decoupled", but your answer is of course how it should be.
The core should definitely check the setup better.

> Actually, I'm in favor of tightening a lot of restrictions on elements.
> Erik always wanted to write a complex core that allows one to write
> really crappy plugins (since several years ago, lots of libraries were
> quite crappy).  I think that model has failed.
> 
We could wrap bad elements in a lot of overhead (think threads and the inf 
loop discussion earlier). Writing bad elements should still be possible, 
though not encouraged or easy.

Benjamin