[gst-devel] autoplugging V2 (RFC)

[Matt Howell]

looks good!  see comments/questions inline...

> Autoplugger V2
> ==============
>
> The current autoplugger as described in autoplug1 has some
> serious shortcommings:
>
>  - it is embedded in GstPipeline and cannot be used with a
>    generic interface. A lot of complexity is inside the
>    pipeline, more specifically the creation of threads and
>    subbins and the pad connections.
>  - it is not (easily) pluggable.
>
> 1) definition
> -------------
>
> We want to define a plugable framework for autoplugging this
> includes:
>
>   - 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 build to handle simple media playback but
> could also be used to create more complex pipelines.
>
> The main focus will be on creating an element (can be a bin)
> that has *one* input pad and *one or more* output pads.
>
> It must be possible for a user app to insert its own elements in
> the autogenerated element.
>
> The autoplugger will be an interface to the low level plugin
> system based on the functional requirements of the user app.
> the app will for example request an object that can convert
> media type X to media type Y, the user app is not interested in
> any intermediate steps to accomplish this conversion.
>
> 2) the API
> ----------
>
> The API for the user apps should be no more then this:
>
>   GstElement* gst_autoplug_construct (GstAutoplug *autoplug,
>                                       GstCaps *incaps,
>                                       GstCaps *outcaps, ...);
>
>   autoplug is a reference to the autoplug implementation
>   incaps is a GstCaps handle for the source pad, the last set
>   of arguments is a va_list of destination caps.
>
> A handle to the autoplugger implementation can be obtained
> with
>
>   GList* gst_autoplug_get_list (void);
>
> which will return a GList* of autopluggers.
>
>   GstAutoplug* gst_autoplug_get ("name");
>
> is used to get an autoplugger.
>
> 3) the plugins API
> ------------------
>
> plugins can add their own autoplugger implementation by
> subclassing an abstract autoplugger class and implementing/
> overriding various methods.
>
> the autoplugger can be registered with:
>
>   gst_plugin_add_autoplugger (GstPlugin *plugin,
>                               GstAutoplug *autoplug);
>
> This will allow us to only load the autoplugger when needed.
>
> 4) implementation
> -----------------
>
> We will implement two autopluggers:
>
>  - a static autoplugger. This autoplugger recursively adds
>    elements to the target element until all of the possible
>    pads are connected to something. The static autoplugger
>    only operates on padtemplates and ALWAYS pads. The pipeline
>    is not started before all elements are connected, hence
>    the 'static' autoplugger. This autoplugger will be a rework
>    of the current autoplugger.
>
>  - a dynamic autoplugger. This autoplugger configures the
>    pipeline at runtime based on the pad capabilities when they
>    become available. this allows for more fine grained
>    autoplugging than can be achieved with the static one because
>    it can be based on the actual media stream you are handling.
>
> the autopluggers will be implemented in their separate plugins,
> outside of the core libraries and are therefore optional.
>
> 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?

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


>
> comments?
>
> Wim
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/gstreamer-devel