> 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

Reply via email to