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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]