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

[Michel Bardiaux]

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.

> I think that if
> some code from imgresample.c or imgrescale.c is better (or faster) than
> the non-SIMD libswscale code we can find a way to integrate it in
> libswscale.
> So, I think you will not see any degradation in the performance nor in
> the functionalities of the LGPLed version of ffmpeg.
> On the other hand, I hope you will see some improvements :)
> 
> 
> 				Luca


-- 
Michel Bardiaux
R&D Director
T +32 [0] 2 790 29 41
F +32 [0] 2 790 29 02
E mailto:mbardiaux at mediaxim.be

Mediaxim NV/SA
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
http://www.mediaxim.com/