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

Surprisingly, the fact is that the High Efficiency Video Coding (HEVC) video compression standard has been around for more than three years. There are not only software, but also hardware encoding solutions and even household media players that support this format. The Internet is littered with advertising, laudatory enthusiastic reviews and reviews, moreover, observers, depending on the impudence of illiteracygullibility, promise an improvement in compression by 30-50% compared to h.264 with the same picture quality. Theoretically, it certainly is and I have absolutely nothing against the standard itself, all this higher mathematics, a plurality of profiles and an objective assessment of the subjective perception of psychophysiological parameters using PSNR. The motivation for writing this anti-scientific article was pure incredulity, a 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 incredulity, I note that I do not believe in hardware encoding in h.264 / AVC(or rather I’m sure that a purely software x264.exe can work at the same speed and with better quality), I don’t believe in video encoding with CUDA and DXVA and I consider all implementations of such “encoders” pure quackery and I don’t believe in two-button magic programs that can "code fast and well." I also do not believe in democracy, antiviruses and modern higher education, but these are purely my problems that are not related to video coding :)
And now, having charged with a fair amount of skepticism, let's take one of the compiled versions of the free x265 encoder , or rather the eight-bit GCC build 1.7+ 286 and all further actions will be performed with her.
At this point, by the way, my incredulity bucked again and had to spend about 6 hours comparing 11 different builds from different sites to calm her down. It turned out that the coding results with similar parameters were identical to the degree of confusion, and the coding time differed by no more than 5-6 percent.
To get started, take as a source the above passage from the Avatar splatter-tree-fogand to exclude the brakes of the decoder, save 100 frames from it as an uncompressed YUV4MPEG2 file, which will be encoded in the future. In x265, the CRF compression method with constant quality is used by default, therefore we also encode in x264 in CRF mode with a quality score of 17.2. The figure was not taken from the ceiling, but it was experimentally found that any increase in this figure leads to a decrease in both the bitrate and quality of the output image, and a decrease only increases the bitrate without any noticeable increase in quality. Of course, the other 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 quality of the picture turned out to be almost identical compared to the source and it is not even worth laying out the comparison. In the future, we will compare the 12th B-frame of the x264-17.2.mkv file with different encoding options in HEVC.

x265 pleases us with many ready-made presets , but of course we will be interested in the very latest - placebo. In fact, even placebo does not provide maximum installation, but more on that later.By default, x265 encodes with a quality score of 28 (maybe this has a deep meaning, but I did not catch it). With such settings, the bitrate of the output file is less than 2 Mb / s (for 1080p) and instead of a picture on the output, there is such a soap that it is impossible to watch and it makes no sense to compare. Therefore, for the first time we will tighten the conditions quite a bit and use the shortest 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. The coding time is a little less than 7 minutes. The quality is not bad in principle, but so far it is far from x264. The link compares screenshots with a total weight of about 6 MB on screenshotcomparison.com (to blame, but I don’t know any other convenient way to compare screenshots) We will work to increase the birate by lowering the quality index and see the results. Trying # 2, crf 20, a bitrate of 9050 kb / s is better, but not the same anyway. But now it's time to remember that the placebo preset does not use the most possible parameters . The most important here are --me star (with a maximum value of full) and --subme 5 (with a maximum value of 7). Let's try to tighten the terms 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"

It immediately becomes clear why the developers did not dare to insert the maximum parameter values ​​into the "maximum" profile. Coding time increased by more than 10 times.

And was the result of these sacrifices worth it? not sure ...
So try # 3, crf 20, -me full --subme 7, bitrate 9045 kb / s - 77 minutes of encoding And then compare the results of the placebo preset with manually set -me full --subme 7 Throw out manually set me, subme and crawl on. Trying # 4, crf 18, bit rate 12922 kb / s is almost good, but x264 is better so far. Now let's see what happens if you encode into x265 with the same bitrate as x264 and with maximum parameters. We managed to achieve the same bitrate with a crf value of 16.2. This time, encoding took 90 minutes.











Link to the file The results are very close, but still x264 retained a little more detail and added a little less soap. Conclusion: Current x265 implementations lose in x264 quality at high bitrates. So we come to the main message of the whole article. Video compression formats, along with the rest of the world, are moving towards simplification and dulling of the population. No one is interested in having a consumer who looks at screenshots of comparisons, fights for every extra pixel of distortion, reads into the encoding parameters, etc. Everything is sharpened on the fastest and funniest coding profiles with minimal bitrates. Surely at low bit rates, x265 will have a significant advantage over x264. Although both there and there will be a lot of distortion and soap, but x264 will have more. Check it out.





Attempt # 5, x265 5371 kb / s, x264 5374 kb / s But they didn’t guess :) Even at x265 native x264 bitrate looks more decent. Draw your own conclusions, and I am looking forward to objective criticism :)