[MPlayer-dev-eng] win32 loader

Rich Felker dalias at aerifal.cx
Wed Aug 30 01:29:59 CEST 2006


On Tue, Aug 29, 2006 at 11:54:21PM +0200, Gianluigi Tiesi wrote:
> > > There will always be new closed codecs without support.  At least a 
> > > binary codec interface closes the gap until a free implementation can be 
> > > created.
> > 
> > And this is exactly why it takes so long for a free implementation to
> > be created.... Also it only closes the gap for x86 users, and
> > encourages people to use the non-free codec when encoding (they say
> > "Linux users should just use the dll loader blah blah blah...").
> > 
> hey my I really don't want my email become a flame :P
> I don't see the point for ffmpeg to support binary codecs,
> it's the "native" implementations of prior binary  only codecs
> let's talk about fraps, with the support for the binary dll
> the "native" implementation was made very fast.
> Mplayer binary codec support is usefull imho but the code
> is unmaintenable.
> My goal is also to use directly e.g. vst plugins (without
> the server wrapped by wine), binary only plugins to be adapted
> to opensource code.
> I'm not promoting closed source stuff, but there are a lot of closed
> source stuff without a free software alternative, or better
> software that needs support that free software cannot offer.
> All of my code is gpl'ed but this doesn't mean that I don't look around
> 
> Other code is also not easly portable e.g. avisynth with a multitude
> of plugins (all opensource)
> 
> and finally at this point, why don't remove at all win32 loader from mplayer
> so equivalent codecs will be developed faster? true?
> I'm really not able to make a decoder without even having a
> working reference decoder.

I agree that having the binary loader is useful for reverse
engineering and such. However there are very nasty legal and moral
issues with linking GPL code (some of which we wrote so we can do
whatever we like with it, but some of which we're using under the
license granted by other authors) to non-free dlls even dynamically.

My view is that there should be a very limited debugging-oriented
player without all the frills and performance of MPlayer, to be used
exclusively for playing videos with non-free dlls and reverse
engineering those dlls. The code for this player could be all-LGPL
(mostly libavformat based), avoiding all the issues of linking GPL
code to the dlls and making them usable but _inconvenient_ so there's
a motivation to replace them by something done right.

I'm not presently campaigning for the removal of the binary loaders
from MPlayer, but I'm certainly opposed to them becoming even more
widespread and convenient to use.

Rich




More information about the MPlayer-dev-eng mailing list