[gst-devel] autoplugging V2 (RFC)

[Wim Taymans]

On 02 Feb 2001 15:37:18 -0700, Matt Howell wrote:

<snip>

> >
> >   - autoplugging algorithms can be added and removed at run time.
> >   - autoplugging algorithms can be defined by plugins.
> 
> it's not clear to me what a plugin's autoplug algorithm does...
> can an application (e.g. player) use an autoplug algorithm added
> by a plugin?  could you elaborate more?

The autoplugger is an algorithm to find an element that can convert from
one media
type to another one. It can be a very complex thing, dealing with
threads, dynamic pads
and QoS/EOS issues.

I envision something like a property panel in the player where the user
can configure
his favorite autoplugger (hmm, farfetched I admit). I also envision a
system where some
media types cause another autoplugger to be used (not sure where,
though).

the user app cen present a drop down box of the available autopluggers
or it can 
choose to use some autoplugger that is better suited for the task.

Unless we can create the ueber autoplugger I think we will need to
experiment a bit
and find out which one works best, there is no better way to test that
than to use
a pluggable mechanism I think.

<snip>

> > 5) the autoplugger object
> > -------------------------
> >
> > the autoplugger object will be an abstract class with the following
> > properties:
> >
> >  - name, description, more text to identify the autoplugger.
> >
> >  - a class method autoplug_construct that has to be implemented by
> >    the real autoplugger.
> >
> >  - possible PadTemplates that this autoplugger can handle well?
> >
> > optionally, the core autoplugger code can provide convenience
> > functions to implement custom autopluggers. The shortest path
> > algorithm with pluggable weighting and list functions come to
> > mind.
> >
> > signals will be added to the autoplugger so that user apps can
> > modify the constructed pipeline by adding extra objects.
> > A possible use case would be to let gstmediaplay perform an
> > autoplug on the media stream and insert a custom sound/video
> > effect in the pipeline when an appropriate element is created.
> 
> what about using an interface like
>   gst_autoplug_add(GstAutoplug *autoplug, GstElement *element)
> that lets the autoplugger decide how to add the element (or return
> failure - invalid object, or ambiguous) instead of a signal?

I think it needs more context. like what thread the element is going to
live in, what
pads to connect, etc..

> 

> maybe there's a benefit of using Gtk signal model that i don't
> understand???  (i don't know that much about them.)

Signals are an implementation of the subscriber/listener pattern. You
can listen to
a named signal on an object and receive notifications from it. Signals
add the 
benefit that you don't need header files in order to be able to get
notified (as opposed
to callback functions which need a typedef) and it is allready very well
implemented
in GtkObject.

Wim