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

u-9iep at aetey.se u-9iep at aetey.se
Wed Feb 8 10:57:39 EET 2017

On Tue, Feb 07, 2017 at 09:07:02PM -0700, Daniel Verkamp wrote:
> 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.

Thanks Daniel.

Yes, the patch does accurate rounding, no dithering.


More information about the ffmpeg-devel mailing list