[FFmpeg-devel] Droping old scaler
Fri Sep 5 06:10:05 CEST 2008
On Fri, Sep 05, 2008 at 02:02:26AM +0200, Michael Niedermayer wrote:
> On Thu, Sep 04, 2008 at 04:33:38PM -0700, Baptiste Coudurier wrote:
> > Hi Michael,
> > Michael Niedermayer wrote:
> > > Hi
> > >
> > > I will remove the old scaler as soon as the regression tests pass with
> > > swscale. We have had 2 scalers for long enough and it caused enough problems
> > > with noone working on fixing anything. Keeping 2 scalers causes time to be
> > > wasted on maintaining both ...
> > I agree with this.
> > > If the GPL parts bother you then now is your last chance to do something
> > > about it, i will not delay the old scaler removal due that nor due to minor
> > > regressions. If a minor regression bothers you, send a patch.
> > I hope you don't consider jpeg colorspace problem minor.
> no, are there any other issues that are not minor?
Is it possible to transform imgconvert into swscale instead?
What are architectural drawbacks of it anyway?
> > Im clearly not happy with the GPL state of libswscale, and I'd like
> > corresponding part of the code to be isolated so it can be easier to
> > reimplement them, I might have a look at it.
> see yuv2rgb.c or better do not look and just look at the tables it generates
> but note the parts of this file are written by me and these parts of that file
> can be used under LGPL.
> And the asm is under #ifdef HAVE_MMX and such so it can be easily disabled.
> > IIRC SIMD is GPL, the old scaler does not have SIMD anyway, can we
> > emphasize which part is GPL exactly ? This code is old...
> > If nobody wants to isolate GPL parts exactly, well I will vote for
> > _removing_ GPL parts.
> I vote for keeping the asm optimzations.
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> Let us carefully observe those good qualities wherein our enemies excel us
> and endeavor to excel them, by avoiding what is faulty, and imitating what
> is excellent in them. -- Plutarch
More information about the ffmpeg-devel