Dear Shevach, We are currently working on algorithmic improvements to make the code run faster without massive quality loss. For the time being, you may want to use “quality=10” or even “quality=0” to make the code run faster. You may also use tile-based multi-threading using -p “mt-mode=1 tiles=x,y nb-workers=N,0”.
This should make the code run significantly faster. Please note that the standard limits the number of tiles to 10 by 11. As a rule of thumb, you should set N, the number of workers, in the range [(x*y)/2, (x*y)-1]. You could set it to a higher value, but you would have many idle threads. I really hope this helps you out for the moment. Do not hesitate to reach out to us if there is anything else. Any feedback is appreciated. Best regards, François Caron On Jul 8, 2014, at 3:55 AM, Shevach <shev...@beamr.com<mailto:shev...@beamr.com>> wrote: Dear f265 developers I am evaluating f265 performance. I installed nasm 2.10 version (as recommended) and compiled f265 (linux). I applied f265 encoder on fives 3840x1744 frames as follows: time ../f265/build/f265cli -v -w 3840x1744 -p "quality=25 rc=abr bitrate=30000000 fps=24,1 cb-range=4,6" -c 5 ./file1/a.yuv test.h265 Encoded : 5/5 (100.0%) @ 0fps ETA 0.00sec real 2m30.114s user 2m29.500s sys 0m0.308s So, the performance of f265 is ~30 sec. per frame, better than HM (~80 sec. per frame) and much worse than x265 (3 sec. per frame). Is there any way to improve the performance of f265 encoder. Best Regards Shevach Riabtsev
