On Tue, Feb 7, 2017 at 10:54 AM, Ronald S. Bultje <rsbul...@gmail.com> wrote: > Hi, > > On Tue, Feb 7, 2017 at 12:04 PM, <u-9...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel