VLC Roadmap

[Gildas Bazin]

On Friday 22 February 2002 21:55, Christophe Massiot wrote:
> Dear friends,
> 
> Maybe we should consider discussing our (non-existant) roadmap. The 
> first issue we have to tackle is the version numbering. I don't think 
> next version should be 0.2.93, since there has been major 
> improvements since 0.2.92. We can then consider several choices, such 
> as 0.2.95, 0.2.99, 0.9, which depend on what we want to do next.
> 
> A big question is : when the hell are we releasing 1.0 ? VLC has been 
> out there for long now, and I don't think it still deserves a < 0.3 
> number. I'd say the major feature we lack to get an excellent media 
> player is DVD menus (plus many bug fixes, of course). As a 
> consequence, I think we should jump to 1.0 when we have DVD menus.
> 

I agree with this, 1.0 for a version supporting full DVD menus sounds nice. 
But it's likely it won't happen before some time though.

> What do we do before then ? We can say that current CVS is almost-0.3 
> release, and call the next version 0.2.99 or 0.2.95, in prevision of 
> an early 0.3 release. We can say that current CVS will soon lead to 
> 1.0 and start 0.9.x preleases. What do you think ?
> 

I would be in favor of starting a long 0.9.x serie but starting with the 
coming release because as you just said a lot of improvements have gone (or 
shortly will) into vlc since the last one. So what should we call the coming 
prereleases... 0.9.0-pre?
(As a side note, I always found the current numbering scheme quite confusing)

> Another problem is that for the moment, no one is willing to work on 
> DVD menus :-(. And don't ask me, I do not even have a DVD drive :-).
> 

Not a problem, I can send you vob and ifo files if you want ;-)

Seriously though, I think our first big step towards DVD menu support should 
be to get a clean API for OSD (on screen display) support. Once we've got 
this done and we adapt the video output modules, we should be able to use 
external libraries like dvdnav to provide DVD menus.

> 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 
> platforms.
> 

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.

Cheers,

--
Gildas

-- 
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>