[gst-devel] autoplugging V2 (RFC)
Matt Howell
matth at ridgerun.com
Fri Feb 2 23:37:18 CET 2001
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
More information about the gstreamer-devel
mailing list