the big modules changes

Samuel Hocevar sam at
Wed Jul 31 19:22:56 CEST 2002

   I am about to commit quite a few changes in the way modules work, and
as usual most module files will need to be changed. People currently
working on a module will 1.) hate me, and 2.) need to resolve a few

   There are two important changes in the way modules work:

    * a module now only has one capability, which is a string, allowing
      arbitrary capabilities vlc isn't even aware of.

      Example: vlc shouldn't have to worry about ac3_adec's downmix, only
      the ac3_adec plugin knows how to request a downmix module.

    * a module can have submodules, which lets have several capabilities
      in a single module, like before.

      Example: the sdl plugin has "video output" and "audio output"

   In the process I would also like to clean the mess in the plugins/
directory, which is becoming hard to follow. I will tune the Makefile
so that it can build modules deeper in the tree, and I suggest the
following layout:

   modules +-> audio +-> output -> dsp alsa arts ...
           |         +-> mixer -> ...
           |         `-> filter -> ...
           +-> video +-> output -> x11, ggi, glide, ...
           |         +-> chroma -> i420_rgb, i420_yuy2, ...
           |         `-> filter -> transform, deinterlace, ...
           +-> access +-> file, network, ...
           |          +-> vcd
                      `-> dvd -> dvd, dvdread, dvdplay, ...
           +-> demux -> mpeg, mp4, ...
           +-> codec +-> mpeg +-> audio -> adec, mad
           |         |        `-> video -> vdec
           |         +-> a52 -> a52dec 
           |         `-> ffmpeg
           +-> interface -> qt, gtk, kde, ...
           `-> arch -> macosx, qnx, beos, win32, ...

   One annoying issue: since CVS sucks raw eggs through a very thin
straw when moving or renaming files (don't you even dare mentioning
directories!), this will make it hard to access a file's previous

   Well, my opinion is that we don't really care, VLC is becoming better
and better, there are few situations where old code is really important,
and if someone really needs a previous version, he should have the
skills to get it from its previous location in the tree. I'd be all for
using a more modern tool such as SVN, but it's still a bit early.

   Comments anyone?


This is the vlc-devel mailing-list, see
To unsubscribe, please read
If you are in trouble, please contact <postmaster at>

More information about the vlc-devel mailing list