[gst-devel] Autoplugger meta-element

Erik Walthinsen omega at temple-baptist.com
Sat May 12 00:41:43 CEST 2001


I've started to work on a dynamic autoplugger meta-element, which is
actually derived from a Bin.  It starts out containing an autoplugcache,
with both sink and src pads ghosted to the outside.  It then makes its
decisions based on what happens (connection, caps) to the pads.

There are a number of scenarios, in two groups.  The first group is inline
autoplugging, where we're simply going to do a conversion between two
formats.  The second group is the 'renderer autoplug', which has no output
pads, but simply renders the final output internally.  That's a more
interesting problem, and one that can be tackled later.

So, for the inline autoplugger, there are two fundamental situations, upon
which all the scenarios are built:

a) source pad has caps
b) source pad doesn't have caps

In the first case, we can autoplug straight through, as is done with the
current autoplugger.  In the second, we have to insert a typefind element
to determine the sinkpad's caps.  In fact, even in the first case, we may
still have to use the typefind, or at least an autoplugcache or three.


1) Source element has accurate caps (i.e. from a typefind, or demuxer),
sink element has fuzzy caps (like an osssink):

Application creates source, autoplugger, and sink.  When they're
connected, negotiation happens and the autoplugcache's sink pad gets set
to those caps.  The autoplugger can then create a shortest path between
those caps and the srcpad caps (that of the sink element, which have to be
obtained by checking the peer pad's padtemplate) and attach that to the
autoplugcache before the sink element.  Note that this has to wait until
*after* the sink element is connected, else the autoplugger doesn't know
what the sink caps are.  As soon as the data flows successfully (with
complete capsnego to the sink element), the autoplugcache is removed.


2) Source and sink both have fuzzy caps:

When the source is connected, no caps are set, but the autoplugger can
look at the padtemplates of the peer pads of each end, and form autoplug
options, using the autoplugcache to attempt them.


3) Source has no caps

If an element is connected to the sink pad of the autoplugger, and the
first buffer arrives without caps being set, the autoplugger must
disconnect the autoplugcache from the sink element and attach a typefind
in place.  This unfortunately means that the sink element won't have
anything attached to it.  This is a significant problem with scheduling,
so much so that it may require a minor conceptual change.  Previously,
Bin's were not schedulable at all.  A new flag I've added (but not tested)
allows certain bins (like the autoplugger, or any meta-element that needs
it) to be schedulable like any other Element.  This lets the autoplugger
have a pad of its own, which it would attach in place of its inner
pipeline, in order to placate the scheduler.

The problem with this is that if for some reason the scheduler gets the
bright idea to pull something from this pad, either we have to tell the
scheduler to forget what it just tried to do and switch back into a useful
part of the autoplugger, or.....

Another method entirely would be to add a ACTIVE/DISABLED state to the
pads.  Any time a pad is DISABLED, data is not allowed to flow through
that connection.  A pad takes on its peer's DISABLED state, but not its
ACTIVE state.  This would likely have the effect of causing the scheduler
to split chains up at those boundaries, as well as temporarily replace the
push/pull proxies with versions that do something at least somewhat
intelligent when they're called.

Once typefind signals that it has a set of caps, the autoplugger can then
go on as usual to create a pipeline.


4) Sink has no caps, or no sink connected

Can we even try to proceed when this is the case?  In order to autoplug
from one type to another, we have to know what's expected out...  We could
either fail state change when !caps && !padtemplate->caps, or just work
toward the appropriate */raw format(s)...  Thoughts?


      Erik Walthinsen <omega at temple-baptist.com> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_




















More information about the gstreamer-devel mailing list