x265 and preset influence with CRF ?

[benwaggoner]

Originally Posted by excellentswordfight

CRF with maxrate and bufsize constrains would imo only make sense for big streaming services, the use of CRF there would not be to increase quality but to lower filesize (i.e. storage cost) without much of an quality loss for low complexity material.

maxrate and bufsize are important to anyone who is trying to limit worst-case bitrate or decoder complexity. x265 sets them by default for the specified or assigned Profile @ Level. But reducing them further can yield a smoother bitrate and also make things easier for software decoders. Also, some applications like UHD Blu-ray will require lower values than Profile @ Level define.

And agree, I dont see a good reason for 2pass CRF even if it's possible.

I could see a 2-pass with CRF useful if there is a max file size target that also needs to be hit. A first pass would be enough if the file size was small enough. If it's too big, do a second pass with --bitrate set.

[benwaggoner]

Originally Posted by Nico8583

I let it to auto and x265 detects 4, 8 or 16 threads.
I read more threads can hurt quality with x264 but I didn't know with x265, so it's the same, thank you. Do you know a document about that ( threads number vs quality) ?

It can be complicated, and isn't nearly as big an issue as originally. Quality hit mainly comes from increased --frame-threads, which used to sometimes cause some rate control issues. It's at least a lot improved now.

[Nico8583]

Thanks for the advices benwaggoner
About maxrate and bufsize, how can we determine the values to use ?
About 2pass CRF, is it possible to do a second pass without "prepare" it (so without using stats or other parameter) ?
Thank you !

[Nico8583]

Any suggestion about maxrate and bufsize ?

[benwaggoner]

Originally Posted by Nico8583

Any suggestion about maxrate and bufsize ?

Setting bufsize to maxrate * max GOP duration isn't a bad starting point, as long as the result is less than the max allowed for profile@level. That would be for file-based playback.