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

[Martin Soto]

On Fri, 2004-01-30 at 14:40, Benjamin Otte wrote:
> 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.
...
> 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:
...
> 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.

I agree.  I cannot really see how it would be possible to have loop
based elements without (co)threads.  Since loop functions can keep
"rolling" so long as they need before returning, there's no way you can
guarantee a fair behavior of the pipeline without having many threads of
control.  You could, of course, require loop functions to do only small
work batches before returning, but this would defeat the purpose of
having them at all.  Instead of living with such a restriction, you'd
rather get rid of all loops and implement everything chain based, which
is always possible, but often very hard.

Now, I'm not really aware of the portability problems with the cothreads
implementation. Isn't it possible to use Pth, for example? 

> > 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. :)

Well, my element is not really an autoplugger since it doesn't
automatically find the decoders.  The element has one input pad, and
many possible outputs, that are actually request pads.  When caps are
negotiated for the input pad, it just goes through all connected output
pads and tries to negotiate based on the caps for the input.  The first
output pad that accepts the input caps, will be taken as active output. 
Thereafter, all input buffers will be forwarded to that pad.  The
element is (or should be ;-) intelligent enough to handle caps being
renegotiated on any pad, and having pads connected and disconnected on
the fly.

Intended usage is that you connect the input to the audio pad of the DVD
demux, and connect decoders for the different types of DVD sound to the
outputs.  If the DVD sound type changes, the demux will renegotiate the
caps on the sound pad, and my element will automagically select the
right decoder.  I suppose this is useful functionality for an
autoplugger, but the logic necessary to identify the right decoder
elements, instantiate and plug them, is still beyond me ;-)

Cheers,

M. S.
-- 
Martin Soto <soto at informatik.uni-kl.de>