[gst-devel] a modest proposal

[David I. Lehn]

* Andy Wingo <apwingo at eos.ncsu.edu> [20011018 00:30]:
> On Wed, 17 Oct 2001, David I. Lehn wrote:
> 
> > > wrt 1, how about the following:
> > > 
> > > * audio: audio-only stuff.
> > > * video: video, including a52dec. ac3dec must die.
> > > * 'system': http*. icecast? rtp*. gnomevfs.
> > > 
> > 
> > Categorization is going to be impossible IMHO.  See previous threads on
> > the topic for more complete and verbose proposals.
...
> what is wrong with that categorization per se, autotools issues aside?
> 

It's like freshmeat or sf, there are multiple categories for a project.
Same with plugins.  Take a volume scaler plugin.  Could file it under
"Filter" or "Audio".  How about a52dec: "Filter" (it does 'filter' in
some sense), "Decoder", "Audio", "Video" (your suggestion), or even
"DVD".  So what tarball or dir would you put it in?  Which is why I
hesitate to create somewhat arbitrary classifications of a plugin.
People looking for it will likely guess the wrong category or otherwise
not look in the right spot.


Here's an aside:

Caps matching could be applied to element selection too.  The available
element database could be populated with caps info.  Instead of
requesting "osssink" or "alsasink" you could just ask for all elements
that have caps category=audio, category=sink, channels=5.1, etc.  Do
caps negotiation on the element database or whatever until you find an
element that supports 5.1 channel audio sink and create it.  Cooler than
preferences imho. ;)  Auto negotiate and create the best possible audio
output for a dvd player.

anyway...

My point is that it is easier to keep the source file layout simple and
put the cool classification stuff in the code and runtime system where
it can be really flexable.


> > > wrt 2, it seems there will need to be an autogen.sh that will search the tree
> > > for files of a well-known name to make the configure.ac script. It has to be
> > > done this way because AC_OUTPUT has to output all .in's, not just for the
> > > plugins that can be built.
> > > 
> > 
> > Have you seen OMS code?  Please don't head down this path.  You end up
> > with a system that is split up poorly and difficult to understand.
> > 
> > fwiw: oms had configure.incl in dirs that needed special configure
> > support.  It >>ed them all together at top level.  This is a mess
> > because you have dependencies issues in some cases which ends up as
> > multiple files checking for similar features.  Admittedly in our case it
> > is probably a bit more clear cut for most plugins, but it's still a
> > mess.  And a scan for all Makefile.am's sucks if you want to exclude
> > some of them or whatever.  Blah.
> 
> what plugin depends on what other plugin? I don't get it. and if it is the case
> that no plugin depends on any other (where 'plugin' == .so, not the individual
> sinks/sources), why would this be difficult?
> 

Ok, I was just rambling. ;)  It's more like difficulty keeping the auto
generated auto* stuff sane.  Just cating together configure.ac fragments
is hard if you want them to also be independent.  Like if two plugins
require a header foo.h, you have to put the check in both places.  So
you could in theory drop compiling either plugin and it would work.  But
using both will check for the header twice.  Header checks are easy, but
some stuff like GTK checks just add bloat.  It was an OMS problem and it
sucked.  Maybe it wouldn't be so bad in gst.


> > A GST_PLUGIN_PATH would be nice.
> 
> indeed. but I hate having to have env. vars set for progs to work. what about
> gst-register keeping track of which dirs are registered and not in its confdir?
> perhaps in addition to your sol'n.
> 

You could do something like have default paths which are used if
GST_PLUGIN_PATH is not set.  If it is set then defeaults are ignored.
Like PATH and LD_LIBRARY_PATH behavior.  Have a tool that can print
defaults so users could do:

export GST_PLUGIN_PATH=\
  `gstreamer-config --default-plugin-path`:~/my-gst-plugins/


> > We should not split up the plugins into their own modules.
> > 
> > Well.. perhaps an acceptable split is moving -all- plugins into a
> > separate gstreamer-plugins module and leaving gstreamer mod as core +
> > docs + tools.
> 
> if we don't split them in a modular fashion, what's the point?
> 

I don't know.  Perhaps none.  Maybe someone will find a use for libgst
that doesn't require and of our plugins...  ok ok, it's a strech ;)


> > Right now everything is nicely contained. 
> > Yeah, it's a big container
> > with warts.  I think if we improved the current system we would be
> > better off:
> > 
> > a) flatten plugin dir.
> >    one subdir per plugin.  no subsubdirs.  that just gets messy.  much
> >    easier to find plugin code this way.  categorization will fail on
> >    some level if we try.
> 
> at least allow subdirs that are relevant, ie vorbis/vorbis[enc/dec]/. finding
> the code is a good point. how does this categorization fail, again?
> 

We don't even split those up now!  vorbisenc/dec are combined into one
plugin lib: libgstvorbis.

A better example is to look at all the mpeg2 related elements.
mpeg2parse, mpeg2dec, mpeg2enc, mpeg2types, subtitles, video... lots of
em.  Putting them under mpeg2 sounds good but what about mpeg2dec?  It
can decode mpeg1 too... so which dir would it go under?

I suppose it would be a plugin dir explosion to not have subdirs.  It
gets back to classification problems.

Perhaps some dirs can even be eliminated.  Rather than 1 dir per element
take the multi approach (like gst/elements) and combine.  Like
mpeg2parse and mpegtypes.  There are a whole lot of dirs with just
foo/{gstfoo.h,gstfoo.c}.  Could maybe toss alot of that into single
dirs.  I dunno...


> > b) move core plugins from gst/ subdirs to plugins/
> >    uniform, consistent, obvious.  leaves gst/ as just core libgst.
> 
> then you can't even *test* gst without the plugins installed
> 

This was assuming core+plugins in same package I guess.  It's not like
the gst/elements/ elements have much value alone either.  Except of
course for a dd(1) replacement. <g>


> >    2) take advantage of am 1.5 creatures like target specific _CFLAGS.
> 
> what's this about?
> 

You don't read the info docs? ;)  Theory is something about we shouldn't
be using CFLAGS proper in the Makefile.ams.  We should now use AM_CFLAGS
for all targets, or foo_CFLAGS = myflags... $(AM_CFLAGS) to add target
specific flags.  This is so, as i understand it, users can use CFLAGS on
the command line.  Right now we override that all over so cmd line usage
would never work.  Wouldn't it be nice to do "CFLAGS=-Werror make"?


> >    3) top level optimization/arch flags (in concert with #2 i think)
> 
> i don't understand what you're going for here
> 

We have no way to pass global optimizations to subdirs.  Would be nice
to set -march=atari800 at the top level.  This does require all subdirs
to actually pay attention and add $(GST_ARCH_CFLAGS) to AM_CFLAGS.  In
any case, I'm lobbying for the GST_ARCH_CFLAGS to exist.


> >    6) perhaps adopt a simple linux kernel like config util to select
> >       features and plugins you want.  this would just output a script
> >       with appropriate flags for configure.  #4 would provide a fairly
> >       uniform way to enable/disable and scan for available plugins.
> 
> this is intriguing, and could solve my concerns about categorization. I just
> don't want to have to go through hoops to disable all video plugins, and this
> could do it for us. Still, another program to maintain, but hey. Sounds pretty
> cool to me. This might even solve the splitting-modules-out problem. I really
> don't want to have to recompile all plugins when something really minor in core
> changes though.
> 

Who says -we- have to maintain it?  Someone should look into the 2.5
kbuild tools.  They might be adaptable to our tree.


> > Issues:
> > * Composite elements: plugins with elements depending on other elements.
...
> do these exist?
> 

wtay was working on it at one point.  Part of the reason for the
RealPad/GhostPad stuff I think.

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