[FFmpeg-devel] Droping old scaler

Robert Swain robert.swain
Fri Sep 5 14:53:28 CEST 2008

2008/9/5 Benjamin Larsson <banan at ludd.ltu.se>:
> 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.

I would consider it acceptable as long as swscale is functional (for
common cases) without the GPL parts (after the parts Michael wrote are
relicensed to LGPL). Actually, I would consider it acceptable even
without as it provides incentive to reimplement those sections.


More information about the ffmpeg-devel mailing list