headers
Reimar Döffinger | 1 Jul 2007 01:07
Picon
Picon

Re: GPL version matter

Hello,
On Sat, Jun 30, 2007 at 10:37:10PM +0100, M?ns Rullg?rd wrote:
> Uoti Urpala <uoti.urpala <at> pp1.inet.fi> writes:
> > On Sat, 2007-06-30 at 22:19 +0200, Christophe GISQUET wrote:
> >> Indeed I missed it, thinking 2.1 was a matter of phraseology. I
> >> generally don't make my choices on absolute confidence in a sunny
> >> future, or more tersely, that I will like any GPL versions coming out
> >> any day.
> >> 
> >> > so even without the "(at your option) any later version."
> >> > anyone can take your LGPL 2.1 code and change it to GPL 12.3.4
> >> 
> >> Then let my obvious question after that obvious correction be:
> >> Are contributions under the strictly version 2 GPL accepted?
> >
> > Given that GPL 3 has already been released and is no longer an unknown
> > "any GPL version coming out any day", do you explicitly want to forbid
> > use under it?
> 
> There are parts of the new GPL3 that I'm not really comfortable with.
> That said, I'm not usually the one to let philosophical/political
> matters get in the way of things.

Well, actually is the discussion about GPL or LGPL now anyway? It first
was LGPL 2.1 or later, then LGPL 2.1 only, to which Michael replied it
would allow relicensing to GPL y.x, so is it now _only_ GPL, _not_ LPGL
_and_ only v2? (and do we want our users to deal with that kind of
mess?)

Greetings,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Niedermayer | 1 Jul 2007 01:22
Picon
Picon

Re: GPL version matter

Hi

On Sun, Jul 01, 2007 at 12:48:43AM +0200, Reimar Döffinger wrote:
> Hello,
> On Sat, Jun 30, 2007 at 10:53:20PM +0200, Michael Niedermayer wrote:
> > On Sat, Jun 30, 2007 at 10:19:12PM +0200, Christophe GISQUET wrote:
> > > Michael Niedermayer a écrit :
> > > > theres something you miss here, and that is the following part of the LGPL
> > > > 2.1:
> > > 
> > > Indeed I missed it, thinking 2.1 was a matter of phraseology. I
> > > generally don't make my choices on absolute confidence in a sunny
> > > future, or more tersely, that I will like any GPL versions coming out
> > > any day.
> > > 
> > > > so even without the "(at your option) any later version."
> > > > anyone can take your LGPL 2.1 code and change it to GPL 12.3.4
> > > 
> > > Then let my obvious question after that obvious correction be:
> > > Are contributions under the strictly version 2 GPL accepted?
> > 
> > yes, as long as its in seperate new file(s), under proper CONFIG_GPL2 and
> > you first submit some patch to configure which does actually contain
> > the needed CONFIG_GPL* setup code and this patch does get accepted by
> > mans or diego
> > (note, the changes to configure must be under LGPL of course)
> 
> I am not at all happy about fracturing ffmpeg even further down into
> different license versions. With that there are then already 4 different
> ffmpeg variants from a license standpoint... At least some arguments why
(Continue reading)

Permalink | Reply | 33 comments |
headers
Måns Rullgård | 1 Jul 2007 01:33

Re: swscale in vhooks

"Víctor Paesa" <wzrlpy <at> arsystel.com> writes:

> Hi,
>
>>> Revision 8013 added -lswscale unconditionally to Cygwin VHOOKSHFLAGS.
>>> Is that still needed? It works fine without that flag in MinGW.
>>> Also, setting that unconditionally and not giving out errors on
>>> configure when the swscaler is not enabled causes linking problems.
>>
>> I'll give it a try tomorrow, it's a bit late here by now.
>
> Thanks for noticing, indeed it may be removed, as Cygwin builds OK
> with or without --enable-swscale after undoing r8013.
>
> Måns, Diego, OK to commit the attached patch?

If it builds and works, sure.

--

-- 
Måns Rullgård
mans <at> mansr.com
Permalink | Reply | 7 comments |
headers
Ronald S. Bultje | 1 Jul 2007 02:16
Picon

Re: GPL version matter

Hi,

On 6/30/07, Michael Niedermayer <michaelni <at> gmx.at> wrote:
>
> could you elaborate on what "down to earth" disadvantages the license
> fracturing has?

It's confusing for users of the ffmpeg (i.e. lav[ufc]) library. At the very
least, plain LGPL should be strongly recommended, though if I were to have
any say in it, I'd argue you should reject any non-LGPL (i.e.
non-LGPL-compatible) contributions. Maybe that's why I have no say in it.
:-).

The risk here is that in the future, new submissions will _themselves_ (e.g.
see libswscale) become GPL, and the problem there is that projects using
ffmpeg will not have the same featureset as others, which will reflect badly
on ffmpeg itself from both the end-user side as well as the developer side.
This GPL'ification of parts of ffmpeg would ideally be prevented at any
possible cost, even if it means feature regression or refusion to include
new features.

Ronald
Permalink | Reply | 0 comments |
headers
Zuxy Meng | 1 Jul 2007 07:04
Picon

Re: MMX accelerated DSP functions for VC1/WMV3 decoders

Hi,

2007/7/1, Christophe GISQUET <christophe.gisquet <at> free.fr>:
> Hi,
>
> Michael Niedermayer a écrit :
> >> +#if defined(CONFIG_VC1_DECODER) || defined(CONFIG_WMV3_DECODER)
> >> +extern void ff_vc1dsp_init_mmx(DSPContext* dsp, AVCodecContext *avctx);
> >> +#endif
> >> +
> >
> > the #if is unneeded
>
> Indeed, even if defined, the symbol won't be used when those conditions
> are not met.
>
> > [...]
> >> +     "psllw     $1, %%mm1               \n\t"                   \
> >> +     "psllw     $1, %%mm2               \n\t"                   \
> >
> > paddw
>
> Is that always faster?

According to Intel & AMD's manuals, same latency on P6/Pentium 4/Core
2/K7/K8/K10, more throughput on Core 2. So paddw is good.

> > duplicating each filter 4 times with macros is unacceptable
> > the overhead for 2 calls is not that big
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Reimar Döffinger | 1 Jul 2007 10:32
Picon
Picon

Re: GPL version matter

Hello,
On Sun, Jul 01, 2007 at 01:22:48AM +0200, Michael Niedermayer wrote:
> On Sun, Jul 01, 2007 at 12:48:43AM +0200, Reimar Döffinger wrote:
> > On Sat, Jun 30, 2007 at 10:53:20PM +0200, Michael Niedermayer wrote:
> > > On Sat, Jun 30, 2007 at 10:19:12PM +0200, Christophe GISQUET wrote:
> > > > Michael Niedermayer a écrit :
> > > > > theres something you miss here, and that is the following part of the LGPL
> > > > > 2.1:
> > > > 
> > > > Indeed I missed it, thinking 2.1 was a matter of phraseology. I
> > > > generally don't make my choices on absolute confidence in a sunny
> > > > future, or more tersely, that I will like any GPL versions coming out
> > > > any day.
> > > > 
> > > > > so even without the "(at your option) any later version."
> > > > > anyone can take your LGPL 2.1 code and change it to GPL 12.3.4
> > > > 
> > > > Then let my obvious question after that obvious correction be:
> > > > Are contributions under the strictly version 2 GPL accepted?
> > > 
> > > yes, as long as its in seperate new file(s), under proper CONFIG_GPL2 and
> > > you first submit some patch to configure which does actually contain
> > > the needed CONFIG_GPL* setup code and this patch does get accepted by
> > > mans or diego
> > > (note, the changes to configure must be under LGPL of course)
> > 
> > I am not at all happy about fracturing ffmpeg even further down into
> > different license versions. With that there are then already 4 different
> > ffmpeg variants from a license standpoint... At least some arguments why
> > this is important enough to start down this messy road might be
(Continue reading)

Permalink | Reply | 19 comments |
headers
Víctor Paesa | 1 Jul 2007 11:09

Re: swscale in vhooks

Hi,

Måns Rullgård dijo:
> "Víctor Paesa" writes:
>
>> Hi,
>>
>>>> Revision 8013 added -lswscale unconditionally to Cygwin
>>>> VHOOKSHFLAGS. Is that still needed? It works fine without that flag
>>>> in MinGW. Also, setting that unconditionally and not giving out
>>>> errors on configure when the swscaler is not enabled causes linking
>>>> problems.
>>>
>>> I'll give it a try tomorrow, it's a bit late here by now.
>>
>> Thanks for noticing, indeed it may be removed, as Cygwin builds OK
>> with or without --enable-swscale after undoing r8013.
>>
>> Måns, Diego, OK to commit the attached patch?
>
> If it builds and works, sure.

I must apologize: this morning I built again
(--disable-static --enable-shared --enable-gpl --enable-swscaler)
and it failed. Maybe I had some leftover from previous compiles?

Builds with "--disable-static --enable-shared --enable-gpl" or
"--disable-static --enable-shared" were OK this morning too.

So I propose now another patch, instead of the previous one:
(Continue reading)

Permalink | Reply | 6 comments |
headers
Måns Rullgård | 1 Jul 2007 11:12

Re: swscale in vhooks

"Víctor Paesa" <wzrlpy <at> arsystel.com> writes:

> Hi,
>
> Måns Rullgård dijo:
>> "Víctor Paesa" writes:
>>
>>> Hi,
>>>
>>>>> Revision 8013 added -lswscale unconditionally to Cygwin
>>>>> VHOOKSHFLAGS. Is that still needed? It works fine without that flag
>>>>> in MinGW. Also, setting that unconditionally and not giving out
>>>>> errors on configure when the swscaler is not enabled causes linking
>>>>> problems.
>>>>
>>>> I'll give it a try tomorrow, it's a bit late here by now.
>>>
>>> Thanks for noticing, indeed it may be removed, as Cygwin builds OK
>>> with or without --enable-swscale after undoing r8013.
>>>
>>> Måns, Diego, OK to commit the attached patch?
>>
>> If it builds and works, sure.
>
> I must apologize: this morning I built again
> (--disable-static --enable-shared --enable-gpl --enable-swscaler)
> and it failed. Maybe I had some leftover from previous compiles?
>
> Builds with "--disable-static --enable-shared --enable-gpl" or
> "--disable-static --enable-shared" were OK this morning too.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Christophe GISQUET | 1 Jul 2007 11:53
Picon
Favicon

Re: MMX accelerated DSP functions for VC1/WMV3 decoders

Hello,

Zuxy Meng a écrit :
>>>> +     "psllw     $1, %%mm1               \n\t"                   \
>>>> +     "psllw     $1, %%mm2               \n\t"                   \
>>> paddw
>> Is that always faster?
> 
> According to Intel & AMD's manuals, same latency on P6/Pentium 4/Core
> 2/K7/K8/K10, more throughput on Core 2. So paddw is good.

Thanks for the information!

I managed to get on an Athlon 1200. Indeed the execution time is the
same there, 10.7s for the 1 billion iterations. So this may not be a
pairing issue but more a matter of throughput.

> a codec expert). Of course as the author who really understands what
> you're doing you can do better than that. So would u mind providing an
> SSE2 optimization at the very beginning?

I think I prefer to wait for the plain-MMX version to be accepted: I'm
maybe far from anything acceptable by Michael, so much time could be
wasted before that. When the pure code issues are fixed, then I may
provide a patch to add SSE2 code inside of vc1dsp_mmx.c

Best regards,
Christophe GISQUET
Permalink | Reply | 0 comments |
headers
Christophe GISQUET | 1 Jul 2007 12:00
Picon
Favicon

Re: GPL version matter

Hello,

Michael Niedermayer a écrit :
> and last, IMHO the "or later" clauses are somewhat concerning so its not
> unreasonable if someone refuses to put his code under them

Precisely. For the sake of ffmpeg, I can contribute under LGPL, but this
one provision in both of their (at least) 2.1 version really puts me off.

Christophe GISQUET
Permalink | Reply | 11 comments |

Gmane