[gst-devel] autoplugging V2 (RFC)
wim.taymans at chello.be
Fri Feb 2 22:06:39 CET 2001
The current autoplugger as described in autoplug1 has some
- 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.
We want to define a plugable framework for autoplugging this
- autoplugging algorithms can be added and removed at run time.
- autoplugging algorithms can be defined by plugins.
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 *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
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,
This will allow us to only load the autoplugger when needed.
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
- 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
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.
More information about the gstreamer-devel