[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.
Rune
More information about the ffmpeg-devel
mailing list