> The SIMD won't be accepted if it's intrinsics. The codeword encoding is not > SIMD, is it? So that may be worth upstreaming.
All optimizations we’ve done are SIMD so it does not apply. Basically what we do for codewords is to process the shifting/masking for eight codewords at a time. The put_bits calls are of course executed sequentially as before. > When you say "no significant PSNR or file size differences", though, it > sounds like the output changed? Did it? Can you explain why? For the tractor sequence we get the following results. time ./ffmpeg -y -i ~/Downloads/tractor_1080p25.y4m -codec:v prores_aw -an -profile:v 2 /tmp/video.mov ffmpeg-master: frame= 690 fps= 22 q=-0.0 Lsize= 611897kB time=00:00:27.56 bitrate=181881.2kbits/s speed=0.876x video:611891kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000996% real 0m31.491s user 2m3.452s sys 0m1.168s [Parsed_psnr_0 @ 0x3ab6da0] PSNR y:49.596357 u:54.113644 v:54.561940 average:51.331354 min:49.684050 max:53.658792 AVX2 optimizations: frame= 690 fps= 32 q=-0.0 Lsize= 611896kB time=00:00:27.56 bitrate=181881.0kbits/s speed=1.27x video:611890kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000996% real 0m23.396s user 1m25.092s sys 0m1.252s [Parsed_psnr_0 @ 0x2838da0] PSNR y:49.595523 u:54.114016 v:54.562335 average:51.330827 min:49.683836 max:53.658654 As you can see, there is 1kb size difference in the output file and some minor variations in psnr. I believe the difference might be due to rounding since we are using float point math and round towards zero, while ffmpeg master uses fixed points for dct. If we pursue to clean up the code and send it upstream we might also look into improving this so we get identical results. Best, Håvard _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel