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

[Luca Abeni]

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).

Michel, I suspect you are over-reacting to something... 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
-- 
_____________________________________________________________________________
Copy this in your signature, if you think it is important:
                               N O    W A R ! ! !