[gst-devel] Meta-plugins: a proposal

[Thomas Nyberg]

On Sat, Mar 17, 2001 at 06:53:20PM +0000, Richard Boulton wrote:
> 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.
>

The problem here is simple, there is no way that you can easily use the
autoplugger to use for instance LADSPA-plugins. The user/app-developer
should most likely want to be able to select which plugin to use. If
the user creates the stream, he would most likely want to select a certain
echo-filter, reverb or noise and place it in the stream. Since these
plugins are loaded dynamicly it is hard to know which are available before
hand.

In this case, you would most likely want to be able to retrieve a list
over all plugins matching something specific. I've done some lobbying on
this before(as you can see), because I think this is important.

> 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.
> 

Ahh, this sounds more like it. Of course, you can't find a common sollution
to all kinds of applications out there. It is, as you hint, good if it were
possible to retrieve a list of all plugins matching some criteria.

If one would use a common standard to assign types to each plugin, an
audiosink might be "Audio/Sink", and an echo-filter might be "Audio/Filter"
(using anything but text for this, seem to have some resistance :)

Then one could simply do a
gst_factory_get_me_my_list_of_nice_plugins_matching_my_type("Audio/Filter")
and then retrieve the list.

This would hide the tricky implementation of traversing the plugins, to speed
this up one could use all kinds of cool algorithms and datastructures and
stuff - but no code would need to be duplicated.

It is even better to have macros for these, like:
#define GST_TYPE_AUDIO_FILTER "Audio/Filter"
to avoid spelling-errors and such.

(there are some fancy things that one could do, like registring these types
dynamicly, if you specify "Audio/filter" no such type would be registered
and a warning/error occurs - makes spotting these real easy)

This would make the life of the app-developer a lot easier, he gets his
precious list of audio-filters, and everyone is happy.


Since types are already added to the factories, one could use those - the only
thing important is to agree on a common naming-standard. I propose the
following:

"media/action/whatever" giving birth to "Audio/Sink", "Video/Filter",
"Audio/Parser" and so on...

It would look like mime-types, but using other names(since mime doesn't
contain these names...)

Thus the factory becomes:

static GstPadFactory audiosink_sink_factory = {
  "Audio/Sink", /* difference, the type of this factory */
  "sink",
  GST_PAD_FACTORY_SINK,
  GST_PAD_FACTORY_ALWAYS,
  GST_PAD_FACTORY_CAPS (
    "audiosink_sink",
    "audio/raw",
    "format", GST_PROPS_INT (AFMT_S16_LE),
    "depth", GST_PROPS_LIST (
               GST_PROPS_INT (8),
               GST_PROPS_INT (16)
             ),
    "rate", GST_PROPS_INT_RANGE (8000, 48000),
    "channels", GST_PROPS_INT_RANGE (1, 2)
  ),
  NULL
);

A minor difference, but would give "us" the possibility to determine exactly
what this does more precisely.


It is not very difficult to apply these changes, but one would need to
change alot of factory-declarations... Then the api for the retrieval of this
information would be needed to add - this is also simple. Just traverse all
plugins(this can be done in O(N) ;)

The hardest part is to agree on what types would be needed, and of the
naming standard.

As I said before,
"media/type/whatever..."
is the way to do it.

"Audio" and "Video" are the basic, what to call both of them together is a
naming-issue - perhaps "AudioVideo", "AV" or something else.

Then we need: "Sink", "Source", "Filter", "Parser"

I believe it is important to call the types of filter that functions on the
streams themself - like 'tee' - something different than filter. "Network" or
"Stream" perhaps. The 'tee' is more likely never to be used directly by a
user. It should be hidden away from them by the GUI or whatever. There are
more examples of this too.


"The home of bad ideas" :)

/Thomas <thomas at codefactory.se>


-- 
Thomas Nyberg                    thomas.nyberg at codefactory.se
CodeFactory AB                   http://www.codefactory.se/
Office: +46 (0)90 71 86 10       Cell: +46 (0)70 335 61 64