By Praveen Kumar Karadugattu and Kalyan Goswami
In the x265 Encoder ver 3.0, the default parameters for “veryslow” and “slower” presets are changed. In this blog we will discuss this modification in detail.
The all new ‘veryslow’ Preset
The “veryslow” preset is one of the most preferred presets by the offline encoding vendors, where the video quality is paramount. Hence, the quality of encoded bitstream is the key feature for this preset than the encoding speed. Hence, this preset targets at improving the quality of the encoded video at a given bitrate while performing extensive computations. This preset can be enabled by specifying the CLI option “–preset veryslow” or “–preset 8” with x265. After performing a bunch of evaluations and finally come up with the following changes in the default settings of the four key parameters in x265 ver 3.0 under the “veryslow” preset.
The significance of these modified params is described below.
- “–limit-refs” implies that x265 will limit references for a PU at a given CU-depth by using information from its higher depth and/or other PU modes at the same depth. Previously, the default value for this preset was set as “1”, which restrict analysis at the current depth, based on references used to code four sub-blocks at the next depth. For example, a 16×16 CU will only use the references used to code its four 8×8 CUs. In version 3.0 of x265, the restriction for limiting the references is relaxed.
- “–limit-modes” restricts the mode analysis for each CU using cost metrics from the 4 sub-CUs. When multiple inter-modes, such as “–rect” and/or “–amp” are enabled, this feature uses motion cost heuristics from the 4 sub-CUs to bypass modes that are unlikely to be the best choice. It significantly improves the encoding performance, when “–rect” and/or “–amp” are enabled bit with a minimal loss of compression efficiency. In x265 version 3.0, this restriction on mode analysis is relaxed.
- During motion estimation, the encoder merges the motion of neighbouring blocks to predict the motion of the current block. The CLI option “–max-merge” defines a maximum number of such neighbour candidate blocks (spatial and temporal) that the encoder may consider for merging motion predictions. If a merge candidate results in no residual, it is immediately coded as a “skip”. Otherwise, the merge candidates are tested when searching for the least cost inter-mode option.
- “–limit-tu” enables an early exit from TU depth recursion, for inter coded blocks. Previously, the “–limit-tu” was 4, which means the 1st sub-TU depth is taken as the limiting depth for the other sub-TUs. In x265 version 3.0, this feature is disabled under the “veryslow” preset.
All the above-mentioned features have a direct impact on the visual quality (both subjective and objective) of the encoded bitstream, but with the penalty of slightly increased encoding time. We have performed a series of experiments to evaluate the speed vs quality trade-off with the new “veryslow” preset against the previous version.
The all-new ‘slower’ Preset
Since most of our OTT clients use “veryslow” preset, the burden of longer encoding times might hamper their application. In order to address this issue, we have redefined the new “slower” preset to match the quality of the previous “veryslow” preset. Hence, the “slower” preset of x265 version 3.0 should provide the same visual quality as the older versions’ “veryslow” preset while maintaining the same encoding speed (fps) as before.
Experimental Results
The sequences that we have chosen for our experiments are listed in Table 1. We have used 4 different resolutions with different source FPS (not to be confused with the encoding fps) and bit-depth. All the experiments are carried out on a Dual-Xeon Linux-based server with 56 cores and 112 threads in a a sequential order.
Table 1: Test Sequences used
In Table 2 the improvements in quality under the “slower” and “veryslow” presets in version 3.0 over version 2.9 are shown. We have computed the BD-PSNR and BD-SSIM metrics to represent the improvement in encoding efficiency in the x65 version 3.0 by making the version 2.9 as the anchor. The positive values of BD-PSNR and BD-SSIM imply the improvement of encoding efficiency (quality). The values in each row of this table indicate the average value of all the test samples under a particular resolution. From this table, it is quite clear that the new version of x265 has significant improvement in quality compared to the older one for these presets.
Table 2: Quality improvement with “slower” and “veryslow” presets in the x265 ver 3.0 over ver 2.9
We can clearly see that there is a significant improvement in the visual quality of the “veryslow” preset of x265 ver 3.0 over the “veryslow” preset of x265 ver 2.9.
As pointed out in the previous section, the improvement in encoding efficiency is expected to slow down the performance (encoding fps). Hence, it is important to gauge the effect of the newer presets on performance. Table 3 shows the performance results of x265 version 3.0 in comparison with those of version 2.9 under the “slower” and “veryslow” presets. These are the encoding FPS values averaged under each resolution.
Table 3: Performance decrement for “slower’ and ‘veryslow” presets in the x265 ver 3.0 over ver 2.9
From Table 3 it is evident that the new “veryslow” and “slower” presets are significantly slower than the older version. However, the performance drop with the new “slower” from the older “veryslow” (represented under the column “ΔFPS% (slower_3.0 vs veryslow_2.9)”) is quite negligible. Hence, for the customers who need maintain the same performance as the “veryslow” preset of x265 version 2.9, are recommended to use the new “slower” preset of x265 version 3.0.
Conclusion
The new “veryslow” preset of x265 ver 3.0 gives much higher compression efficiency compared to the old “veryslow” of ver 2.9, however, it comes with a significant drop in the performance (encoding fps). Hence, we have moved the old “veryslow” to the new “slower” in ver 3.0 which retains a similar compression efficiency as the old “veryslow” (of ver 2.9) without sacrificing much of the performance (encoding speed in fps).
P.S:
Both the versions of x265 can be downloaded from here.
The CLIs we ran to perform these tests are:
x265 –psnr –ssim –input <input.yuv> –input-res <width>x<height> –fps <fps> –bitrate <target bitrate in kbps> –preset slower –output “out_slower.hevc”
x265 –psnr –ssim –input <input.yuv> –input-res <width>x<height> –fps <fps> –bitrate <target bitrate in kbps> –preset veryslow –output “out_veryslow.hevc”
