[MPlayer-dev-eng] [PATCH] internal dvdnav

[Uoti Urpala]

On Thu, 2009-01-08 at 16:15 +0100, Reimar Döffinger wrote:
> On Fri, Jan 02, 2009 at 06:41:11PM +0200, Uoti Urpala wrote:
> > On Wed, 2008-12-31 at 11:22 +0100, Nico Sabbi wrote:
> > > I agree completely with the inclusion of both externals and with your
> > > patch, but using different names is the only sane way to proceed: it
> > > eliminates any ambiguity. 
> > 
> > Is there any reason this should be built as an integral part of the
> > MPlayer build process, hardcoding its filenames in MPlayer Makefile? Why
> > could it not be built separately? I'd rather favor dropping such
> > imported (whether directly as code or as external) libraries from the
> > MPlayer tree if they can be built separately. If the issue is making it
> > easy for technically unskilled users to build MPlayer with all features
> > then that is IMO better solved with a separate script that downloads
> > extra libraries.
> 
> Nobody will write and maintain such a script (not to mention making it
> work for all the broken shells around like Solaris, MinGW etc.)

But would maintain hacks like including the sources of the libraries in
the MPlayer tree and even hardcoding the library filenames in the
MPlayer build system? I don't think it would need any complicated shell
functionality (if the configure script can run then so should should
such a script as it would be a _lot_ simpler). And it is not even
necessary for the automatic script to work on every broken platform.

> More importantly, not including it will mean that the installed
> libraries will be used, which means
> 1) loads of issues due to outdated, badly patched versions, versions
> without dvdcss etc.

MPlayer can make any version checks it wants and refuse to work with old
libraries. Hardcoding everything in your own program to work around
broken systems is not the right way to do things. Windows may be so
broken that it is unavoidable, but on other platforms you should do
better. You can provide ways to do it for people who absolutely have to,
but it must not be the default.

> 2) Using SVN means those libs must be installed, overriding the
> distribution libraries, possibly breaking other installed programs
> 
> 2) means I will not be using dvdnav/dvdread SVN nor fixing bugs even
> though I have commit access to them.

You don't have to do a system-wide install. Things built as static
libraries can be installed under the build tree and shared libraries
wherever the final MPlayer would get them from anyway.

> And as an historical sample point, this "should be built as external
> lib" theory has very effectively killed the VESA vo, I suspect that to

I can't really evaluate that claim beyond noting that I have no idea why
anyone would want to use such a VO...

> In contrast, what is the advantage of not including them?

Keeping the MPlayer tree clean of outside code and using the system
versions if they work. MPlayer should not default to adding extra code
for the sake of broken systems.

>  Due to the
> special case here, maintenance effort IMO is purely theoretical, and
> below what any of libav*, libmpeg2, tremor or vidix need.

I'm in favor of dropping those too in the long term. FFmpeg requires
some work because MPlayer uses non-installed parts. Libmpeg2 is a forked
version with some extra functionality not present in upstream and Vidix
is not really the same as the independent library. libdvdnav has no such
excuse to be included internally. I think tremor could probably be
dropped soon without many problems.

> Better testing of the libdvd* build systems might be a plus point of not
> including it, but so far my impression is that people simply don't build
> it on MinGW instead of reporting bugs, also this is offset by far more
> people at least testing the libdvd* SVN code.

There are not even any visible instructions on exactly how to build with
libdvdnav on MinGW. You can go a lot further in making things easy to
build without needing to include the libraries in the MPlayer tree.

One way to set up an easy MinGW build could be to make a separate
repository which includes MPlayer itself as an external subrepository
along with other needed libraries and possibly contains some extra
scripts.