[LoRd_MuldeR]

Originally Posted by Grojm

This is very confusing. Then the metric used by CRF to determine quality must be very fragile and contra intuitive. I'd expected that it will optimize for some visual model to offer such and such quality level. But I understand your point.

That is not how CRF mode works. There is no "elaborate" quality metric.

If we ignore MB-Tree for now, it is pretty much just a "complexity" measure based on the expected frame size (in bits) in conjunction with the qComp ("quantizer curve compression") algorithm and a fixed (used-defined) scaling factor.

Read here for some basic information on how the different RC modes work:
https://code.videolan.org/videolan/x...atecontrol.txt

Originally Posted by Loren Merritt

x264's ratecontrol [and thus x265's] is based on libavcodec's, and is mostly empirical. But I can retroactively propose the following theoretical points which underlie most of the algorithms:

• You want the movie to be somewhere approaching constant quality. However, constant quality does not mean constant PSNR nor constant QP. Details are less noticeable in high-complexity or high-motion scenes, so you can get away with somewhat higher QP for the same perceived quality.
• On the other hand, you get more quality per bit if you spend those bits in scenes where motion compensation works well: A given artifact may stick around several seconds in a low-motion scene, and you only have to fix it in one frame to improve the quality of the whole scene.
• Both of the above are correlated with the number of bits it takes to encode a frame at a given QP.

[...]

2pass:
Given some data about each frame of a 1st pass (e.g. generated by 1pass ABR, below), we try to choose QPs to maximize quality while matching a specified total size. This is separated into 3 parts:

1. Before starting the 2nd pass, select the relative number of bits to allocate between frames. This pays no attention to the total size of the encode. The default formula, empirically selected to balance between the 1st 2 theoretical points, is "complexity ** 0.6", where complexity is defined to be the bit size of the frame at a constant QP (estimated from the 1st pass).
2. Scale the results of (1) to fill the requested total size. Optional: Impose VBV limitations. Due to nonlinearities in the frame size predictor and in VBV, this is an iterative process.

[...]

1pass, ABR:
The goal is the same as in 2pass, but here we don't have the benefit of a previous encode, so all ratecontrol must be done during the encode.

1. This is the same as in 2pass, except that instead of estimating complexity from a previous encode, we run a fast motion estimation algo over a half-resolution version of the frame, and use the SATD residuals (these are also used in the decision between P- and B-frames). Also, we don't know the size or complexity of the following GOP, so I-frame bonus is based on the past.
2. We don't know the complexities of future frames, so we can only scale based on the past. The scaling factor is chosen to be the one that would have resulted in the desired bitrate if it had been applied to all frames so far.

[...]

1pass, CFR:

1. Same as ABR.
2. The scaling factor is a constant based on the --crf argument.

[...]

On the subject of presets and CRF mode:

In general, a "slower" preset improves the "quality per bit" ratio (better quality at same file size), at the cost of slower encoding speed. Conversely, a "faster" preset improves encoding speed at the cost of a worse "quality per bit" ratio (worse quality at same file size). But: When it comes to CRF mode, the is no guarantee (and I think there never was) that a specific CRF value still results in the same absolute file size (average bitrate) after switching to another preset!

Therefore, it is quite possible that, after switching to a "slower" preset, you end up with better quality and a larger file – at the same CRF value. That alone doesn't say anything! However, if you carefully adjusted your CRF value, in order to find the highest CRF value that still gives satisfactory quality, and if you did this separately for each preset, then you would probably find that, in the end, the "slower" preset can get away with a smaller file than the "faster" one.

Originally Posted by NikosD

It's late September of 2019.

I think it's time to declare project x265 dead.

It can't get any other AVX2/AVX512 optimizations and it can't improve quality in the same size any more.

Time to move on to H.265 hardware encoding and other codecs (AV1)

BTW: x265 version 3.2 has just been released:
https://bitbucket.org/multicoreware/...20d244bd49ef17

Also, the longer an encoder has already been under development, the more effort will be required to get an additional improvement. So, it is kind of "natural" that things improve fast at the beginning and slow down after a while...