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 
<<>> 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

Reply via email to