Re: mplayer 1.0pre7

[Mario Fux <foxman@lugo.ch>]

Am Dienstag, 26. April 2005 01.29 schrieb Jeroen van Wolffelaar:

Morning

Thanks for your explanations and don't take my mail as rant, it's just a 
question.

> On Mon, Apr 25, 2005 at 04:34:41PM +0200, A Mennucc wrote:
> > mplayer 1.0pre7 is ready and packaged at
> > http://tonelli.sns.it/pub/mplayer/sarge
> >
> > a.
> >
> > ps: still no news from ftpmasters... hope they at least will try to read
> >   http://people.debian.org/~mjr/mplayer.html

[snip]

> - Patents: The big issue with mplayer a.t.m. I'm myself not very
> following the patent stuff, but as far as I understood, certain
> patents hold by the MPEG organisation, esp. those w.r.t. encoding of
> MPEG data streams, are actively being enforced, (again afaik) in the
> United States in particular. See [1] for more information of what I
> believe is relevant here. Unfortunately, links there mostly either
> shine in unavailability (404 etc) or utter vagueness and
> non-information (I couldn't find any bit of useful patenting
> information at [2], for example). The FFII had more useful information
> at [3].
>
> All this seems to concentrate on MPEG-related *encoding* though, and
> not to decoding. Moreover, Debian contains plenty of MPEG-related
> decoding software, and the FTP-master policy at least w.r.t. audio
> MPEG decoding has always been to not let supposed patents in this area
> stand in the way of distributing this software, on the basis that it
> seems to be an unenforceable patent, or at least, it isn't enforced
> (and giving in to any patent would mean Debian could not distribute
> anything). I see no reason why MPEG videa decoding would be different in
> this respect, again, to the best of my knowledge.
>
> So, adding these two tentative[4] conclusions together, it seems
> likely that if mplayer were demonstrated with reasonable certainty to be
> free of MPEG-encoding code, it would be acceptable for inclusion in
> main as far as the FTP-masters are concerned (note: We're not (yet?)
> saying it's *required* to strip MPEG encoding stuff, but in my personal
> opinion, it seems likely that this is what it'll turn out to be. Don't
> take my words on too much value though, maybe stripping this won't be
> required after all, but in any case, if it isn't there, we don't need to
> think/discuss about it -- reinclusion of the encoding stuff can then
> later separately be discussed).

But what is the difference of mplayers encoding capabilities to ffmpegs 
encoding capabilities (from it's description: "encoding formats (MPEG, DivX, 
MPEG4, AC3, DV, ...).") which is in unstable and testing?

[snip]

thx for all your work
Mario