Legends and myths of modern implementations of x265 / HEVC or x264 vs x265 in comparison of screenshots

Surprisingly, but a fact - the video compression standard High Efficiency Video Coding (HEVC) is over three years old. There are not only software, but also hardware coding solutions and even home media players that support this format. The Internet is littered with praiseworthy, enthusiastic advertising reviews and reviews, and observers, depending on the audacity of ignorance of gullibility, promise an improvement in compression by 30-50% compared to h.264 with the same picture quality. Theoretically, it probably is, and I have absolutely nothing against the standard itself, all this higher mathematics, the multiplicity of profiles, and the objective assessment of the subjective perception of psycho-physiological parameters using PSNR. The driving motive for writing this unscientific article was pure distrust, the desire to independently feel the currently available free implementations of video encoders in this format (x265) and compare the results with the good old x264.

To understand the scale of the problem and the degree of my distrust, I note that I don’t believe in hardware coding in h.264 / AVC (or rather I’m sure that pure software x264.exe can work with the same speed and better quality) I use video coding with CUDA and DXVA and consider all implementations of such "encoders" pure quackery and do not believe in magic two-button programs that can "encode quickly and well." I also do not believe in democracy, antiviruses and modern higher education, but these are purely my problems not related to video encoding :)
Now, having charged with a fair amount of skepticism, we take one of the compiled versions of the free x265 encoder , or rather, the eight-bit GCC assembly 1.7 + 286 and all further actions will be performed with it.
At this point, by the way, my incredulity again bucked and had to spend about 6 hours to compare 11 different assemblies from different sites to calm her down. It turned out that the coding results with similar parameters were identical to the degree of mixing, and the coding time differed by no more than 5-6 percent.
To begin with, we take as the source the above-mentioned excerpt from Avatar splash-tree-fog and to exclude decoder brakes, save 100 frames and from it as an uncompressed YUV4MPEG2 file, which will be encoded later. In x265, the default CRF compression method with constant quality is used, so we encode it in x264 also in CRF mode with a quality score of 17.2. The figure is not taken from the ceiling, but empirically found that any increase in this figure leads to a decrease in both the bitrate and image quality at the output, and a decrease only increases the bitrate without any noticeable increase in quality. Of course, the remaining encoding parameters were also at the maximum and as a result we got a compressed file with a bitrate of 17.6 Mb / s (which is almost 2 times lower than the original 31 Mb / s on a BD disk). Encoding time 100 frames - 40 seconds . The picture quality turned out to be almost identical in comparison with the source code and you should not even lay out a comparison. In the following, we will compare the 12th B-frame of the x264-17.2.mkv file with different encoding options in the HEVC.

x265 pleases us with many ready-made presets , but of course we will be interested in the latest one - the placebo. In fact, even placebo does not provide maximum settings, but more on that later. By default, x265 encodes with a quality score of 28 (perhaps this is a deep meaning, but I did not catch it). With such settings, the output file bitrate is less than 2 Mb / s (for 1080p) and instead of a picture on the output is such a soap that it is impossible to look and it makes no sense to compare. Therefore, for the first time, we tighten the conditions quite a bit and use the shortest possible command line.

"E:\Video\x265\x265_64-8.exe" "E:\Video\avatar\raw.y4m" --crf 23 --preset placebo --output "E:\Video\avatar\x265-test1.mkv" 

As a result, we get a file with a bitrate of 5.4 Mb / s. Coding time just under 7 minutes. The quality is not bad in principle, but so far it's far from x264. The link is a comparison of screenshots with a total weight of about 6 MB on the website screenshotcomparison.com (to blame, but I do not know of another convenient way to compare screenshots)

We will work to increase the rate by lowering the quality indicator and watch the results.

Attempt # 2, crf 20, bitrate 9050 kb / s - better, but still not

')
And here it is time to remember that the placebo preset uses far from the maximum possible parameters . The most important ones here are - me star (at the maximum value of full) and - subme 5 (at the maximum 7). Let's try to tighten the conditions and manually say

 "E:\Video\x265\x265_64-8.exe" "E:\Video\avatar\raw.y4m" --preset placebo --me full --subme 7 --psy-rd 0.5 --psy-rdoq 0.5 --output "E:\Video\avatar\x265-test1.mkv" 

Immediately it becomes clear why the developers did not dare to insert the maximum values ​​of the parameters into the "maximum" profile. Coding time increased more than 10 times

And was the result of these sacrifices worth? not sure…
So try # 3, crf 20, -me full - subme 7, bitrate 9045 kb / s - 77 minutes of coding


And here is a comparison of the results of the placebo preset with the manually set -me full --subme 7


We throw out manually set me, subme and we creep further.
Attempt # 4, crf 18, bit rate 12922 kb / s - almost good, but x264 is better


Now let's see what happens if we encode in x265 with the same bitrate as x264 and with maximum parameters.
The same bit rate was achieved when the value of crf 16.2. This time the encoding took 90 minutes.
File link

The results are very close, but still x264 retained a bit more detail and added a little less soap.
Conclusion: Current x265 implementations are losing in x264 quality at high bit rates.

Here we come to the main message of the whole article. Formats of video compression along with the rest of the world are rolling towards simplifying and dulling the population. No one is interested in having a consumer who looks at screenshots of comparisons, fights for every extra pixel of distortion, reads in coding parameters, etc. Everything is sharpened on the fastest and funniest encoding profiles with minimal bitrates. Surely at low bitrates x265 will have a significant advantage over x264. Although there and there will be a lot of distortion and soap, but x264 will be more. Check it out.
Attempt # 5, x265 5371 kb / s, x264 5374 kb / s


But they didn’t guess :) Even in the native x265 bitrate, the x264 looks more decent.

Draw your own conclusions, while I hopefully await objective criticism :)