[MPlayer-dev-eng] [PATCH] internal dvdnav
Reimar.Doeffinger at stud.uni-karlsruhe.de
Thu Jan 8 16:15:44 CET 2009
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.)
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.
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.
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
this day it is a major effort to get it to even build - though DVDs are
popular enough that it won't be quite as bad.
In contrast, what is the advantage of not including them? Due to the
special case here, maintenance effort IMO is purely theoretical, and
below what any of libav*, libmpeg2, tremor or vidix need.
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.
More information about the MPlayer-dev-eng