[FFmpeg-devel] Droping old scaler

[Michael Niedermayer]

On Fri, Sep 05, 2008 at 01:47:11PM +0100, Robert Swain wrote:
> 2008/9/5 Michael Niedermayer <michaelni at gmx.at>:
> > On Fri, Sep 05, 2008 at 07:10:05AM +0300, Kostya wrote:
> >> 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.
> 
> Why does it have this behaviour? 

because it originally started just as a yuv420->rgb scaler for mplayer when
no hardware scaler was available.


> I would assume it can be 'fixed'.

of course, again API is already in
place since ages (SWS_FULL_CHR_H_INT/SWS_FULL_CHR_H_INP) but implementation
is largely missing.
I had hoped that this years SOC would fix this ...


> 
> > 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.
> 
> There is also 64-bit accurate rounding that is broken. See issue222.

I totally forgot that one ...


> 
> > swscale also is in need of simple code factorization, spliting in files
> > a nicer internal API for SIMD, ... patches here are welcome.
> 
> The public API seems somewhat prone to errors as well and could
> probably be better/more clearly documented. Simple, isolated example
> code for use cases such as resizing, converting colour space and
> cropping would be welcome. Disseminating such from ffplay.c and
> ffmpeg.c isn't the nicest thing in the world to do. :)

patches welcome

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- 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/5b1052f0/attachment.pgp>