[gst-devel] some queue advice

[in7y118 at public.uni-hamburg.de]

Quoting Thomas Vander Stichele <thomas at apestaart.org>:

> Ugh.  What can I say ? In my mind all schedulers should act in exactly
> the same way (theoretically; of course the current set of bugs in all of
> them breaks this :)).  Ie, an app shouldn't depend on the property of
> one scheduler that it somehow manages to change pipelines without having
> to be paused.  If gst-player relies on this, I think that's broken.
>
Schedulers and races at the PLAYING/PAUSED border is an evil thing where nobody 
has an idea how it should work and we're currently happy that it does.
The fact that opt should support state changes in PLAYING is from Wim, I'm just 
repeating what he told me.
Though I'd vote against that, too.
 
> In this example, the queue needs to be very small in order to make the
> app respond quickly enough.
> 
Queues can be limited in size. The queue only needs to be big enough for the 
audiosink to not run out of buffering while the rest is PAUSED.

> I suppose both the input thread/bin and output thread need to go in a
> pipeline, right ? or can two threads function without either of them
> being inside another pipeline ?
> 
I think in theory they do. They shouldn't though. So yes, there needs to be a 
pipeline around them.

> If a bin is inside a pipeline, can the bin be paused without having to
> pause the whole pipeline ?
> 
Yes. Spider pauses itself when adding elements to it. It currently is and it 
should always be possible to set any state on an element regardless of the 
parent's state.

> (I'm asking these questions on two levels; whether or not they "should"
> and whether or not they "currently do", since these don't always match
> and I'd like for us to move to a point where we all can trust these two
> to line up properly :))
> 
The problem is this - I've only recently begun to think about that:
When a state change or relinking or whatever happens - anything that affects 
the pipeline/scheduler - the design must make sure that this works, especially 
asynchronously.
And since schedulers add information to elements (like cothreads, which might 
be in the middle of some chainfunction when something of the above happens) we 
must somehow make sure that the scheduler can be exchanged/reset/... at that 
point.

I have no idea what policies are necessary to do it right. So I'm mostly 
guessing right now.
I could construct use cases though that would currently break. If someone wants 
to listen to them, I'll write up some.

Benjamin