[Ffmpeg-devel] moving non-SIMD parts of libswscale to LGPL

[Ulrich von Zadow]

Michel Bardiaux schrieb:
> Luca Abeni wrote:
>> Hi all,
>>
>> On Wed, 2006-11-15 at 11:46 +0100, Michel Bardiaux wrote:
>> [...]
>>>>>> >From the first day there was talk of swscale, I was afraid it 
>>>>>> would end
>>>>>>> like this. With the removal of img_resample and that licensing, 
>>>>>>> the LGPL version becomes a second-class implementation.
>>>>>> It does not change the current situation at all, so I don't see a 
>>>>>> reason
>>>>>> to be much annoyed over it.
>>>>> Only if the pure-C swscale is faster than img_resample with the MMX 
>>>>> optimisations.
>> [...]
>>>> what f* SIMD code are you talking about anyway
>>>> there are ~2 pages of mmx code in libavcodec/imgresample.c from which
>>>> one is under if(0)
>>>> and the code is crap, most mmx insructions work with one single sample
>>> Apparently there is a lot of code in ffmpeg that is crap, but nowhere 
>>> documented so. You only reveal the fact when you need it to flame 
>>> some patch or other post you dont agree with.
>> [...]
>>
>> Since I am the one who started this "swscale in ffmpeg" thing, and did
>> most of the work for using libswscale in ffmpeg, I think I have to say
>> something here...
>>
>> Everything I did (or I tried to do) has been inteded to improve ffmpeg,
>> not to create problems to some users, to create licensing issues, or to
>> start flames.
>> Everyone I heard about agrees that libswscale quality is better than the
>> quality of the routines currently used by ffmpeg for image rescaling and
>> pixel format conversion. So, I think that having ffmpeg able to use
>> libswscale would be an improvemnt. Ok, the non-SIMD code is slower than
>> the SIMD-optimized one... But is it slower than the code currently used
>> by ffmpeg? I do not know, I never benchmarked them. I am putting this
>> benchmark task in my todo list (with a low priority).
> 
> Its on mine, too, but at least as far as on yours :-) But its going to 
> be hard to do (1) if the img_resample code is removed and the API 
> evolves in such a way that it becomes difficult to keep img_resample as 
> private code (2) because of the if-0 which does not explain much.
> 
>>
>> Michel, I suspect you are over-reacting to something... 
> 
> You have to realize that if ffmpeg goes GPL (and by that I mean a 
> forking where most of the gurus follow the GPL branch and the LGPL 
> branch is left to wither and die) then for professional users, the 
> decision to use ffmpeg instead of some propretary codec software 
> becomes, retroactively, a very bad decision. If there is a risk of that, 
> I need to know ASAP, so I can prepare a fallback solution.

It would also cause a real problem for all open source LGPL projects 
that link to libavcodec/libavformat.

Regards,

   Uli