[FFmpeg-devel] Droping old scaler

[Michael Niedermayer]

On Fri, Sep 05, 2008 at 07:10:05AM +0300, Kostya wrote:
> 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?

no


> What are architectural drawbacks of it anyway?

imgconvert has no architectur it just is a bunch of convert a to b
functions.
imgconvert does not scale the image, imgresample supports only yuv420
imgconvert has no SIMD optimzations
imgconvert upscales chroma when needed with nearest neighbor scaling only

swscale allows any linear rescaling function to be used, bilinear, bicubic
lanczos, spline, windowed sinc, ...
can apply a user specified convolutional filter
(sharpen/blur/shift/contrast/...)
many conversion pathes especially the common ones are highly optimized.

imgconvert supports only 2 yuv colorpspaces, swscale supports all in
case of yuv->rgb but sadly only 1 in the yuv->yuv & rgb->yuv cases.
Though swscale has the API in place to support all in all convertion
since ages, it just lacks the implementation.
(this is the jpeg colorspace bug above)

The biggest issue with swscale after the jpeg colorspace is that it
expects the internal colorspace to have chroma horizontally subsampled
by half. This leads to slightly lower quality when both source and
destination have more chroma, though one has to keep in mind that
imgresample even requires yuv420 so this isnt worse except when no
scaling is done.

Fixing imgresample/convert is equivalent to a complete rewrite, fixing swscale
just needs a yuv444 internal path, the jpeg colorspace and the regression
tests to be fixed, where the first is IMHO not really blocking the switch
because the current system isnt really better.

swscale also is in need of simple code factorization, spliting in files
a nicer internal API for SIMD, ... patches here are welcome.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080905/0fe2cce4/attachment.pgp>