Re: MPlayer reloaded
Nathanael Nerode writes:
> Diego Biurrun wrote:
> > Branden Robinson writes:
> > > On Tue, Mar 16, 2004 at 05:03:09AM +0100, Diego Biurrun wrote:
> > > > I am Diego Biurrun, the MPlayer documentation maintainer, not to be
> > > > confused with Gabucino, who has made a few appearances on this list
> > > > before. I am not here to start a(nother) flame war.
> > >
> > > Thanks for your careful and comprehensive approach to resolving these
> > > issues. A codebase with source from many contributors using many
> > > different licenses is seldom trivial to cope with.
> > >
> > > At least, that's how I feel having wrestled with XFree86. :)
> > Amen.
> Your work looks good to me as well; I don't see any copyright license issues
> remaining. There are still the usual issues of programs covered by
> actively enforced patents. :-P
The MPlayer package maintainer is free to enable or disable
functionality as needed. What exactly is problematic apart from css?
If no problems remain, what are the next steps? Can Andrea Menucci
propose MPlayer packages for inclusion into unstable now?
> > No, seriously, the tarball supports being compiled into a .deb package
> > and supports many features (css, etc) that will most probably not make
> > it into Debian, even if MPlayer should.
> * Is it possible to arrange for dynamic runtime use of the libdvdcss2
> library if, and only if, it's available? This is what most Debian move
> players do.
libdvdcss support has been removed since it is obsolete and had
security problems IIRC. You can compile MPlayer with dynamic runtime
support for libdvdread, though, which should work much better:
enables libdvdread unconditionally or
disables our own libmpdvdkit, libdvdread should be detected
> * Is it possible to do similar things with some of the other "external"
> included packages? That would resolve a lot of related issues, I believe.
Yes, have a look at
almost all functionality available in MPlayer can be disabled or
enabled as needed.