[gst-devel] Continuing work on DVD (long)

[Benjamin Otte]

On Fri, 30 Jan 2004, Martin Soto wrote:

> Well, the schedulers have to be fixed.  By the way, it would be nice to
> discuss the scheduling algorithms here "in the open", before
> implementing them.  A big problem I see is that it is not really clear
> what basic behavior should be expected from a scheduler.  IMO,
> schedulers could differ in things like performance for different
> applications, but their behavior in terms of how buffers are routed and
> processed should always be predictable.  This doesn't seem to be the
> case now.
>
Apart from the current schedulers being very buggy wrt tearing down
pipelines or parts thereof, there's also the problem of cothread
switching. To illustrate the problem:
Imagine loopsrc ! loopsink, both loopbased. This means both require their
own cothread. Opt however doesn't use cothreads. It runs the loopsink. If
the loopsink requests a buffer, it runs loopsrc and puts all the buffers
loopsrc throws out into some sort of queue (opt names it "bufpen"). After
that it continues with loopsink. When loopsink is done, the iteration is
finished. (This is a simplified view of course, but it illustrates the
problems I'm coming to now.) The problems with this are:
1) You cannot assume that a buffer is processed after you've send it out
before you send the next one. Some plugins rely on that.
2) There might be unhandled buffers lying around in bufpens after the
iteration returns. THis is bad when you start unlinking.
3) If plugins have long loopfunctions, bufpens get huge. I believe
asfdemux is an offender there (I think it never end the loopfunction
until EOS). This is exceptionally bad when you do clocking and easily fill
up GstQueues with that crap.
This is easy to see with our example if you assume loopsrc always pushes
two buffers and loopsink always requests three during one run of the
loopfunction.Thern it works like this:
1) loopsink loopfunction starts and needs buffers.
2) loopsrc puts two buffers in bufpen. (problem 1 for second buffer)
3) loopsink requests more buffers
4) loopsrc puts two buffers in bufpen. (problem 1 for second buffer)
5) loopsink grabs one buffer out of bufpen and finishes loop.
6) iteration done (problem 2)
The only way I know to get around those limitations (and I'd like to get
around them) is to use cothreads again. That would require someone with
enough knowledge about makecontext and friends to write a portable
cothreads implementation though and I believe that's hard.

> On the other hand, the problem I'm tackling with my new element is not
> just the deficiencies in the current schedulers.  The fact is that you
> have pads that change their capabilities on the fly (for example from
> 48Khz PCM sound to AC3 when going from a menu to the main film) and
> someone has to react and route the buffers to the corresponding
> decoders.  That's what my new element does.  There's probably a way (I
> don't have the GStreamer sources available here) to do that from the
> application side, but the element that selects its output pad based on
> the caps of the attached elements looks like a cleaner solution to me.
> Am I missing something?
>
In theory this is a job an autoplugger should do. And my intention is
to makie the new one do that. Well, what you did is kind of a specialized
autoplugger already. :)


Benjamin