VLC Roadmap

Jean-Paul Saman saman at natlab.research.philips.com
Mon Feb 25 10:45:52 CET 2002

>>We have yet another decision to take. VLC uses more and more external 
>>libraries, and I expect this to increase in the future. We can 
>>currently optionally use libmad, liba52, and libdvdread, but they are 
>>not activated by default. We'll probably need another library for DVD 
>>menus. Since those libraries provide better performance, better 
>>reliability and better features, I think we should drop support for 
>>the built-in replacements (dvd, ac3_adec and mpeg_adec plug-ins). 
>>When ? It isn't as easy as it seems. We need to provide easy access 
>>to the libraries in some way (putting packages on the web site ?). 

>>But more important, we need to ensure that these libraries compile 
>>and run on all platforms we support, and port them is necessary. This 
>>is quite a big job, and I don't know if we get enough feedback to do 
>>so. We'd probably need a responsive « port maintainer » for all 
How responsive do you want a port maintainer to be? If you think I am 
responsive enough,
then I'd like to volunteer for testing vlc on iPaq platform.
> What the xine people do is to put the whole libraries into the cvs tree.
> I think it should be worth considering, if only because it makes life easier 
> when you want to compile the prog. One trick not to fall into in this case is 
> starting to fork the orginal library, even though it can be handy to modify 
> our cvs version temporarily for example to allow it to compile on a non 
> supported platform (until the fixes are integrated into the original library).
> Or maybe we could just provide a big external_libraries.tar.gz including the 
> specific versions of the libraries we use? I think the important point is to 
> make it easy for anyone to compile a full-featured vlc.
Last time this was discussed, the reasoning was not to put the libraries 
  in the CVS-tree. I think that was a good decission. It gives the 
problem what to do then with all those library dependencies. Personally 
I favor to provide them at the website in easy packages for the tested 
and supported platforms. In this way everyone can easily find those 
third- "party" libraries. It also avoid possible conflicts with already 
installed libraries.

Kind greetings,

Jean-Paul Saman

e-mail (work): saman at natlab.research.philips.com
phone  (work): 040 27 42909
Ordina TA,
Science Park Eindhoven 5602, Postbus 293, 5600 AG Eindhoven
e-mail : jean-paul.saman at ordina.nl
phone  : 040 2601200
fax    : 040 2601199

This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://www.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>

More information about the vlc-devel mailing list