[Ffmpeg-devel] moving non-SIMD parts of libswscale to LGPL
Luca Abeni
lucabe72
Wed Nov 15 16:10:00 CET 2006
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 ! ! !
More information about the ffmpeg-devel
mailing list