[FFmpeg-devel] Droping old scaler

[Benjamin Larsson]

Michael Niedermayer wrote:
> 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.
>   

I am for the the drop of imgconvert if the GPL parts of the code are 
clearly marked. We tried to keep both for a transition period where 
nothing happened.

MvH
Benjamin Larsson