[gst-devel] Meta-plugins: a proposal

[Richard Boulton]

Something that has been worrying me for a while got brought up recently on the
list, and I think I have a decent solution, so here goes. ;-)

The problem is that different systems will have different plugins
available, and application programmers need to know what's there so that
the application can work correctly.  The autoplugging mechanism solves this
problem (to a large extent) for filter plugins, but it still requires the
application programmer to provide detailed start and end points.

With the current setup, there is likely to be a lot of code duplication
between applications to allow them to use whatever audio and video inputs
and outputs are available.  What we want instead is for the application
writer to say something like "send this data to an audio output, I don't
care which but let the user specify if desired".

One suggestion is that the application has a simple way to get a list of
all the available plugins, or possibly those of a given type, and can then
offer a list to the user.  However, this still requires lots of duplicated
code in applications, is messy to implement, and doesn't help when the
application isn't interactive so can't ask questions.  Besides, its better
to avoid annoying the user with questions unless it is really neccessary.


A better idea would be to have a set of meta-elements, whose behaviour is
clearly defined in the GStreamer specification, but whose implementation is
defined in a simple configuration file.  For example, we would have a
meta-element which is an audiosink.

We could name all meta plugins with a simple consistent naming scheme so
that application writers would know which plugins were which.  The reason
that application writers should know this is because meta-plugins will
always be available (in the sense that the system will understand them:
there may be no working implementation available, but that's not the
application's problem).  I'd suggest calling them all "meta-*".

For example, there would be a "meta-audiosink" element.  This would have a
single input pad named "sink" which accepts data of the type "audio/raw".
The configuration file would then specify how the meta-audiosink element
should be implemented. Ideally, the configuration would be able to specify
several different possible implementations 

There should, as ever, be a system configuration file, and a user specific
file which overrides the system file.

An enhancement would be for the application to be required to specify an id
for the element whenever it were requested.  The configuration file could
then specify different implementations for each id, allowing the user to
specify.  The id's should be the application name, optionally followed by
an identifier specifying what the element is wanted for.
eg "gstmediaplay/mainaudio"


An example: configuration file containing implementations for
meta-audiosink (my XML is very rusty, so this is merely for illustration)

<meta-element>
  <interface>
    <name=meta-audiosink>
    <pad type=sink name=sink>
  </interface>
  <implementation>
    <name=audiosink>
    <pad>
      <externalname=sink>
      <internalname=sink>
    </pad>
  </implementation>
  <implemenation>
    <name=esdsink>
    <pad>
      <externalname=sink>
      <internalname=sink>
    </pad>
  </implementation>
  <implemenation id="gstmediaplay/mainaudio">
    <name=esdsink>
    <pad>
      <externalname=sink>
      <internalname=sink>
    </pad>
  </implementation>
</meta-element>

This configuration specifies a default implementation for meta-audiosink
of audiosink, with the "sink" pad of audiosink being used for the "sink"
pad of meta-audiosink.  If that implementation cannot be used, the next
implementation would be used, which is to use esdsink.
However, if the id supplied when creating the meta-audiosink element was
"gstmediaplay/mainaudio", then an alternative implementation would be used;
that of trying esdsink first.  If all possible implementations fail, the
element fails to be created.


How could this be implemented?  Well, one way which suggests itself to me
is to make a new container for meta elements, which uses shadow pads to
map the actual pads onto the external pads.  It doesn't seem to be something
that would be very hard to implement: the trickiest bit would be checking
whether an implementation was available - it would be neccessary to create
the element and put it into the READY state to check it, I think.


This scheme hides the implementation of the meta-elements from application
writers and users: a nice graphical tool could be put together to allow
customisation of the configuration file, but in a lot of cases a standard
configuration file would suffice.

The scheme also allows for multiple soundcards: in the simplest case each
time an audiosink is requested, the next card in the list will be used.  If
desired, the card to be used could be specified by specifying that


It is also easy to allow new meta-plugins to be defined: they simply need
to be specified clearly, and have their interfaces documented.

It would be possible to allow the settings to be overridden by environment
variables, to allow runtime specification of the audiosink to be used for a
single instance of an application, for example.

If the application wants to be able to specify the element to be used
itself, it can implement whatever scheme it likes using non-meta elements,
but has the added option of falling back to a meta- element if its
selection system fails to choose a working element.

-- 
Richard