[gst-devel] plugin directory/hierarchy

[Wim Taymans]

On 07 Mar 2001 23:39:07 +0100, Thomas Nyberg wrote:
> On Wed, Mar 07, 2001 at 10:14:16PM +0100, Wim Taymans wrote:
> > In GStreamer all plugins are techically filters, the only way they
> > can be considered sources or sinks (input/output) elements is
> > by the absence of src/sink pads. 
> 
> This really sucks!
> If you are writing an application, you should not assume that a given
> plugin exists on the system. Perhaps you want to use an alas_sink if it
> exists - else an oss_sink. Perhaps someonee has renamed the oss_sink into
> audio_output-sink. This is a real problem I believe.

not really.
An app programmer will use the hierarchy as a global plugin selection
mechanism. When
you want to select a plugin, you're always going to query the repository
for a plugin that
can, say, convert raw audio to mp3 using the capabilities of the pads.
The new autoplugger
lets you do super-repository-queries. As an app programmer you don't
even want to know 
what plugins are needed to do a certain conversion at all.

> 
> The best way to solve this, and one of the easier, is to create a numeric
> identifier for each type. This way you could easily determine what kind
> of a filter a filter really is. You do not need to analyze the plugins
> kinds of pads to find out if you can use for output.
> A simple gst_element_factory_get_type(...) function should do it. Then
> you could test the type.
> 
> By looking at gst/elements/gstaudiosink.c one finds
> ...
> "Sink/Audio"
> ...
> however, this string is only a description nothing more.
> 
> Instead of using Sink/Audio, one could use a enum(whatever...) like
> enum {
>      SINK = (1 << 0),
>      SRC = (1 << 1),
>      AUDIO = (1 << 2),
>      VIDEO = (1 << 3),
>      PARSER = (1 << 4),
>      ...
> };
> 

The problem with all those flags is that they tend to tie a lot of
semantics to the core (in
header files somewhere). If you want to add something completely new
(like 3D objects)
you'll end up having to add another flag in the enum..

> By OR-ing these values together the type of the element is easy to test,
> and since we use numeric values - not much space is wasted and
> spelling-errors are much easier to detect.
> 
> It would be easy to determine if a given element was a soundcard by
> if ((gst_element_factory_get_type() & (SINK | AUDIO)) == (SINK | AUDIO))
>    ...
> 
> 
> If we use an int, we have like 32 different kinds of filters, which should
> be enough for everyone(pun intended :)
> 
> If this isn't enough, one can move onto 64bit and so on... The best approach
> is to create a
> typedef element_type_t guint32;
> 
> It is easy to change this into guint64 and then it only takes a recompile of
> all sources for it to work as aspected.
> 
> 
> Since an application can test each element-factory present on the system one
> can cope with name-changes, "3rd-party"-plugins and so on... 

So can it when we clearly define the hierarchy...

Wim

> 
> /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
> 
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>