[FFmpeg-devel] [PATCH] Efficiently support several output pixel formats in Cinepak decoder

[Daniel Verkamp]

On Tue, Feb 7, 2017 at 10:54 AM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> Hi,
>
> On Tue, Feb 7, 2017 at 12:04 PM, <u-9iep at aetey.se> wrote:
>
>> cinepak, rgb24            19.7     (via the fast bilinear swscaler)
>> cinepak, internal rgb565   6.0
>
>
> The reason that your decoder-integrated colorspace convertor is so much
> faster than swscale is because swscale is converting internally to yuv420p
> using a scaling filter, and then back to rgb565 using another scaling
> filter. This is "easily" solved by adding a direct (possibly
> x86-simd-accelerated) rgb24-to-rgb565 converter into
> libswscale/swscale_unscaled.c, which would likely have nearly identical
> performance to what you're seeing here. Possibly even faster, because
> you're allowing for simd optimizations.

There is already a rgb24-to-rgb565 path, but it does not get used by
default because of the needsDither check in ff_get_unscaled_swscale().
If the scaling algorithm is set to fast_bilinear, needsDither is
ignored and the RGB24 to RGB16 converter is used. (In either case, no
actual scaling is performed, so the scaling algorithm is irrelevant
aside from selecting dithering.) Looking at the mplayer docs, this is
probably equivalent to '-sws 0'.

e.g.
  ffmpeg -i <sample> -f null -c rawvideo -pix_fmt rgb565le -sws_flags
fast_bilinear /dev/null

Using matrixbench_mpeg2.mpg (720x567) encoded with ffmpeg into Cinepak
using default settings, decoding on an i5 3570K, 3.4 GHz:

bicubic (default):          ~24x realtime
fast_bilinear:              ~65x realtime
patch w/rgb565 override:    ~154x realtime

As far as I can tell, this patch doesn't do any dithering for RGB565,
so the fast_bilinear (non-dithering) swscale converter is a fair
comparison.

-- Daniel