[gst-devel] plugin directory/hierarchy

[David I. Lehn]

* Wim Taymans <wim.taymans at chello.be> [20010307 16:18]:
> Face it, the plugins/ directory hierarchy is crap. We want to propose a
> better layout for it now. Some things to consider:
> 
>  - Elements have a klass member in the factory that is used to
>    denote the functional type of the element. For example, the
>    mp3 encoder has a klass of Filter/Encoder/Audio
> 
>  - The plugins can be grouped together by the media type they
>    operate on or by the way they work (decoder/encoder)
> 
> 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. At first sight the source/filter/
> sink distinction is quite useless because most of the plugins
> will go into the filters category anyway.
> 
> We don't want to make the hierarchy too deep, yet provide a
> clean way to ask for a mp3 decoder element..
> 

For runtime classification would it be possible to create an
"autoclassifier"?  Based on I/O caps add element to a number of
categories.  Top level "All" would have all the plugins.  If a plugin
only has audio input and no outputs throw it in All, Audio, Sinks, and
Audio/Sinks.  If it has same type for audio-only input and audio-only
output throw it in All, Audio, Filters, and Audio/Filters (or Effects?).
Different types on input and output and throw it in a Codecs category
too (or Encoder, Decoder... not sure how you could tell).  Maybe this
would be a big mess vs something useful. ;)

-dave
-- 
David I. Lehn <dlehn at vt.edu>  | http://www.lehn.org/~dlehn/
Computer Engineering Graduate @ Virginia Tech in sunny Blacksburg, VA