Comparison of HEVC codecs from MSU. How to improve results
In October 2015, another codec comparison report was released at Moscow State University’s VMiK, this time it included several HEVC codecs.
The starting point for the study was that we noticed a difference in presets in tests for AVC and HEVC - for AVC, an unmodified fast profile with one GOP was used, and for HEVC, a modified one with several GOPs was used. At the same time, for the only “Apple Tree” file described in the open report, the x264 encoder turned out to be better than x265 when it was quickly transcoded on the graphs of the dependence of SSIM on bitrate without taking into account the encoding speed. The question immediately arose: maybe these options or some other obvious ones can change this picture.
The report compares presets, but does not provide recommendations for correcting them. In this article, we made a similar comparison and made recommendations for modifying the x265 encoder presets. For a video sequence similar to that studied in the free version of the report, the proposed changes to the encoding parameters can improve compression efficiency, while they rehabilitate the x265 encoder when plotting the report.
The modified presets do not claim universality, testing on a large number of video sequences is beyond the scope of this study. However, they can be recommended as a starting point when looking for ways to increase the coding efficiency of x265.
The task of video encoding in multimedia processing, whether it is transmission, editing or editing, storage, arises constantly both when developing applications and services, and when setting them up at the time of use. Due to the large number of popular video codecs, even often of the same type, it is not easy to choose the optimal one from them and then set the correct settings. Probably, guided by such considerations, in the laboratory of computer graphics and multimedia at the faculty of computational mathematics and cybernetics (VMiK) of the Moscow State University since the 2000s, work has been ongoing on a project to compare video codecs.
In October 2015, a codec comparison report was published that included some codecs in the HEVC format, as well as several others that are currently under active development. As the "reference" adopted compressor x264. One of the interesting in the report is the x265 compressor, and we will study it.
As a tool for analysis, we will use SolveigMM Zond 265, the file analyzer HEVC / H.265 and AVC / H.264.
We describe the technique. Comparison in the report is carried out according to the criteria bitrate-quality (SSIM, PSNR) -speed. The procedure described in the report for comparing the ratio of bitrate / quality metric (paragraph C.4) is as follows.
We select several bitrate values (for example, 7 values: 1, 2, 4, 6, 8, 10 and 12 Mbps), for them we consider the necessary quality metrics for each codec.
We mark the obtained values on the graph: quality metric (abscissa axis) - bit rate (ordinate axis).
For the reference, select x265 with the preset selected in the report (table 1). The report does not use the latest version of the compressor, it can be found here: x265 1.5 + 460-ac85c775620f . However, when using the latest version, nothing fundamentally changes.
The compressor presets used are shown in table 1 (for the desktop platform).
Table 1. Settings for the x265 compressor of the “MSU HEVC Video Codec Comparison” report.
To get recommendations for modifying presets, we test all the settings that they consist of - what contribution each component makes to quality and speed. The plan here is as follows.
We restrict ourselves to the parameters of presets for universal coding and for “ripping” (Table 2), revealing the parameters “-p medium” and “-p ultrafast”. Add to them two more missing in the report: “--keyint -1 --tune ssim”. We will supplement the listed parameters with presets for quick and universal transcoding, respectively.
Table 2. Candidate parameters for modifying the presets of the MSU HEVC Video Codec Comparison report
The download link for the Apple Tree test sequence (Fig. 1), used in the free version of the report, is not specified. We will choose a similar one, using its key feature - close-up, a large number of small details. For example, “ big_buck_bunny_1080p_h264.mov ”, an interval of 338 frames from 24 seconds:
ffmpeg -i big_buck_bunny_1080p_h264.mov -ss 00:00:24 -frames: v 338 -c: v rawvideo -pix_fmt yuv420p sample.yuv
Figure 1. Characteristics of the sequence Apple Tree ”
In order to not spend a lot of time writing out the necessary numbers from the Zond 265 interface when implementing the three steps of the plan indicated above, it is convenient to use its ability to work on the command line (table 3):
zond265_x64% COMPRESSED_FILE% -iref% REFERENCE_420P_FILE% -nowait -report t = quality, statstream qm = SSIM o =% TARGET_CSV_FILE%
A list of all parameters, as well as their detailed description, can be found on the Zond 265 documentation page .
Table 3. Zond 265 command line parameters necessary for compiling a script
Here are two scripts for Python 2.7: one for encoding 266 files (20 settings for the first, 18 settings for the second preset, for 7 bitrates: 1, 2, 4, 6, 8, 10, 12 Mbps), the second for compiling a report in CSV format (file - the ratio of FPS encoding to the reference configuration - the ratio of the SSIM metric to the reference configuration).
As can be seen from the report tables for the file fragment " big_buck_bunny_1080p_h264.mov " (tables 5 and 6), you can modify the configuration, for example, as shown in table 4. Recall to improve efficiencythe Quality Measure value should be less than one, and the Relative coding time value should be more than one.
The test was performed on a computer with the following configuration: Intel Core i7-2600@3.4 GHz, 16 GB RAM. The greatest improvement in quality is provided by the “--min-cu-size 8” parameter for fast coding configurations, for universal coding - the “--rdoq-level 2” parameter (but it also slows down the coding most of all).
Table 4. Modification of MSU HEVC Video Codec Comparison report presets to increase coding efficiency at the same coding rate
The correct choice of options is easy to verify by running the encoding script with the modified presets (table 7).
Table 7. Coding efficiency using modified presets relative to the “MSU HEVC Video Codec Comparison” report presets
Let's try to take a look at what the change in options affected - open the file encoded in the Zond 265 with the modified preset for fast transcoding for the 8 Mbps bitrate and compare it with the file, encoded unchanged preset. The size of the maximum coding unit remains the same, and is 32x32 (area “--ctu 32”). But the size of the minimum block decreased from 16 to 8 (the area “--min-cu-size 8”), it was this parameter that gave the greatest increase in quality. The number of B-frames increased from 3 to 4 (area “--bframes 4”), but the maximum number of “reference” frames increased (area “--ref 4”). The SSIM area shows the maximum SSIM / PSNR graphs for three components: brightness (Luma) and two color components (Cb, Cr). They increased from 0.9623-0.9966 to 0.9771-0.9991. The remaining additional parameters (--rc-lookahead 20 --early-skip --cutree) affect the encoding algorithm, and not the type of the resulting video, this is mainly reflected in the encoding speed (see Table 5). Need to mark,
Figure 2. Screenshot of the Zond 265 file encoded using the corrected quick encoding configuration.
Similarly, you can check the parameters of the encoded file with the modified and unchanged universal encoding preset (Figure 3). The size of the minimal TU partitions did not change and remained equal to 4x4 (area “--tu-intra-depth 3”), the number of B-frames remained unchanged and equal to 3 (area “--bframes 3”). SSIM increased from 0.9789-0.9994 to 0.9811-0.9992. Compared to the fast transcoding configuration, the maximum block size increased, became equal to 64x64 (area “--ctu 64”), a SAO filter (area “--sao”) was added.
Figure 3. Screenshot of the Zond 265 file encoded using the corrected universal encoding configuration.
Thus, based on the testing, a list of options is proposed to improve the encoding efficiency (improving the SSIM metric with the same bitrate and encoding speed) for fast and universal encoding configurations. Using the proposed changes for a file with a lot of small details, the value of the integral “quality measure” of the “MSU HEVC Video Codec Comparison” report improved by 31% for quick transfer, and 15% when universal, the coding rate did not change significantly. Because Since testing was carried out for each option separately, in practice, you can select and use only some convenient options, and not the entire proposed list.
The starting point for the study was that we noticed a difference in presets in tests for AVC and HEVC - for AVC, an unmodified fast profile with one GOP was used, and for HEVC, a modified one with several GOPs was used. At the same time, for the only “Apple Tree” file described in the open report, the x264 encoder turned out to be better than x265 when it was quickly transcoded on the graphs of the dependence of SSIM on bitrate without taking into account the encoding speed. The question immediately arose: maybe these options or some other obvious ones can change this picture.
The report compares presets, but does not provide recommendations for correcting them. In this article, we made a similar comparison and made recommendations for modifying the x265 encoder presets. For a video sequence similar to that studied in the free version of the report, the proposed changes to the encoding parameters can improve compression efficiency, while they rehabilitate the x265 encoder when plotting the report.
The modified presets do not claim universality, testing on a large number of video sequences is beyond the scope of this study. However, they can be recommended as a starting point when looking for ways to increase the coding efficiency of x265.
about the project
The task of video encoding in multimedia processing, whether it is transmission, editing or editing, storage, arises constantly both when developing applications and services, and when setting them up at the time of use. Due to the large number of popular video codecs, even often of the same type, it is not easy to choose the optimal one from them and then set the correct settings. Probably, guided by such considerations, in the laboratory of computer graphics and multimedia at the faculty of computational mathematics and cybernetics (VMiK) of the Moscow State University since the 2000s, work has been ongoing on a project to compare video codecs.
In October 2015, a codec comparison report was published that included some codecs in the HEVC format, as well as several others that are currently under active development. As the "reference" adopted compressor x264. One of the interesting in the report is the x265 compressor, and we will study it.
As a tool for analysis, we will use SolveigMM Zond 265, the file analyzer HEVC / H.265 and AVC / H.264.
Methods for comparing codecs and selecting parameters
We describe the technique. Comparison in the report is carried out according to the criteria bitrate-quality (SSIM, PSNR) -speed. The procedure described in the report for comparing the ratio of bitrate / quality metric (paragraph C.4) is as follows.
We select several bitrate values (for example, 7 values: 1, 2, 4, 6, 8, 10 and 12 Mbps), for them we consider the necessary quality metrics for each codec.
We mark the obtained values on the graph: quality metric (abscissa axis) - bit rate (ordinate axis).
- Interpolate linearly.
- We select the widest range on which all graphs are defined, and find the area under all graphs on it.
- As a measure of the quality of a particular codec (or preset), we take the ratio of its area to area for the reference codec. The lower the number, the more efficient the codec.
For the reference, select x265 with the preset selected in the report (table 1). The report does not use the latest version of the compressor, it can be found here: x265 1.5 + 460-ac85c775620f . However, when using the latest version, nothing fundamentally changes.
The compressor presets used are shown in table 1 (for the desktop platform).
| Ripping | x265 -p veryslow --bitrate% BITRATE_KBPS%% SOURCE_FILE% -o% TARGET_FILE% --input-res% WIDTH% x% HEIGHT% --fps% FPS% |
| Universal coding | x265 -p medium --bitrate% BITRATE_KBPS%% SOURCE_FILE% -o% TARGET_FILE% --input-res% WIDTH% x% HEIGHT% --fps% FPS% |
| Fast recoding | x265 -p ultrafast --ref 3 --bitrate% BITRATE_KBPS%% SOURCE_FILE% -o% TARGET_FILE% --input-res% WIDTH% x% HEIGHT% --fps% FPS% |
To get recommendations for modifying presets, we test all the settings that they consist of - what contribution each component makes to quality and speed. The plan here is as follows.
- We encode the file, changing each parameter of the preset: from fast transcoding to universal, from universal to “ripping”. At the same time, we save the encoding time.
- We calculate the quality measure (as the area indicated above) and the relative encoding time (the minimum FPS encoding value for the “preset-modified parameter” file relative to all selected bitrate values).
- From the table consisting of a variable parameter, quality measure, minimum FPS, we select the parameters that can be used to improve presets.
We restrict ourselves to the parameters of presets for universal coding and for “ripping” (Table 2), revealing the parameters “-p medium” and “-p ultrafast”. Add to them two more missing in the report: “--keyint -1 --tune ssim”. We will supplement the listed parameters with presets for quick and universal transcoding, respectively.
| Universal coding | --rc-lookahead 20 --scenecut 40 --ctu 64 --min-cu-size 8 --bframes 4 --b-adapt 2 --subme 1 --me hex --early-skip --sao - signhide --weightp --rd 3 --aq-strength 1.0 --aq-mode 1 --cutree --no-fast-intra |
| Ripping | --weightb --amp --rect --rc-lookahead 40 --bframes 8 --tu-inter-depth 3 --tu-intra-depth 3 --rd 6 --rdoq 2 --psy-rdoq 1.0 - -subme 4 --max-merge 4 --me star --ref 5 --b-intra --lookahead-slices 0 |
Testing
The download link for the Apple Tree test sequence (Fig. 1), used in the free version of the report, is not specified. We will choose a similar one, using its key feature - close-up, a large number of small details. For example, “ big_buck_bunny_1080p_h264.mov ”, an interval of 338 frames from 24 seconds:
ffmpeg -i big_buck_bunny_1080p_h264.mov -ss 00:00:24 -frames: v 338 -c: v rawvideo -pix_fmt yuv420p sample.yuv
Figure 1. Characteristics of the sequence Apple Tree ”
In order to not spend a lot of time writing out the necessary numbers from the Zond 265 interface when implementing the three steps of the plan indicated above, it is convenient to use its ability to work on the command line (table 3):
zond265_x64% COMPRESSED_FILE% -iref% REFERENCE_420P_FILE% -nowait -report t = quality, statstream qm = SSIM o =% TARGET_CSV_FILE%
A list of all parameters, as well as their detailed description, can be found on the Zond 265 documentation page .
| Parameter | Description |
| -iref | Setting the reference YUV file |
| -report | Specifying the Zond 265 operating mode on the command line |
| t = quality, statstream | Here, the generation of two reports is selected: quality and statistics on video stream |
| qm = SSIM | Quality metric for calculation |
| o | Path to CSV report file |
| -nowait | Without pauses, the Zond 265 should switch from file to file without delay |
Here are two scripts for Python 2.7: one for encoding 266 files (20 settings for the first, 18 settings for the second preset, for 7 bitrates: 1, 2, 4, 6, 8, 10, 12 Mbps), the second for compiling a report in CSV format (file - the ratio of FPS encoding to the reference configuration - the ratio of the SSIM metric to the reference configuration).
As can be seen from the report tables for the file fragment " big_buck_bunny_1080p_h264.mov " (tables 5 and 6), you can modify the configuration, for example, as shown in table 4. Recall to improve efficiencythe Quality Measure value should be less than one, and the Relative coding time value should be more than one.
The test was performed on a computer with the following configuration: Intel Core i7-2600@3.4 GHz, 16 GB RAM. The greatest improvement in quality is provided by the “--min-cu-size 8” parameter for fast coding configurations, for universal coding - the “--rdoq-level 2” parameter (but it also slows down the coding most of all).
| Fast recoding | x265 -p ultrafast --ref 3 --rc-lookahead 20 --min-cu-size 8 --bframes 4 --early-skip --cutree --tune ssim --bitrate% BITRATE_KBPS%% SOURCE_FILE% -o% TARGET_FILE% --input-res% WIDTH% x% HEIGHT% --fps% FPS% |
| Universal coding | x265 -p medium --weightb --bframes 8 --tu-intra-depth 3 --psy-rdoq 1.0 --b-intra --lookahead-slices 0 --tune ssim --bitrate% BITRATE_KBPS%% SOURCE_FILE% - o% TARGET_FILE% --input-res% WIDTH% x% HEIGHT% --fps% FPS% |
Table 5. Report on modification of the quick recoding preset
Table 5. Report on modification of the quick recoding preset
Table 5. Report on modification of the quick recoding preset
Table 6. Report on modification of the universal coding preset
Table 6. Report on modification of the universal coding preset
Table 6. Report on modification of the universal coding preset
The correct choice of options is easy to verify by running the encoding script with the modified presets (table 7).
| Configuration | Quality measure | Relative coding time |
| Fast transcoding (reference) | 1 | 1 |
| Fast transcoding, modified | 0.69 | 0.97 |
| Universal Transcoding (reference) | 1 | 1 |
| Universal Transcoding, Modified | 0.85 | 0.94 |
Let's try to take a look at what the change in options affected - open the file encoded in the Zond 265 with the modified preset for fast transcoding for the 8 Mbps bitrate and compare it with the file, encoded unchanged preset. The size of the maximum coding unit remains the same, and is 32x32 (area “--ctu 32”). But the size of the minimum block decreased from 16 to 8 (the area “--min-cu-size 8”), it was this parameter that gave the greatest increase in quality. The number of B-frames increased from 3 to 4 (area “--bframes 4”), but the maximum number of “reference” frames increased (area “--ref 4”). The SSIM area shows the maximum SSIM / PSNR graphs for three components: brightness (Luma) and two color components (Cb, Cr). They increased from 0.9623-0.9966 to 0.9771-0.9991. The remaining additional parameters (--rc-lookahead 20 --early-skip --cutree) affect the encoding algorithm, and not the type of the resulting video, this is mainly reflected in the encoding speed (see Table 5). Need to mark,
Figure 2. Screenshot of the Zond 265 file encoded using the corrected quick encoding configuration.
Similarly, you can check the parameters of the encoded file with the modified and unchanged universal encoding preset (Figure 3). The size of the minimal TU partitions did not change and remained equal to 4x4 (area “--tu-intra-depth 3”), the number of B-frames remained unchanged and equal to 3 (area “--bframes 3”). SSIM increased from 0.9789-0.9994 to 0.9811-0.9992. Compared to the fast transcoding configuration, the maximum block size increased, became equal to 64x64 (area “--ctu 64”), a SAO filter (area “--sao”) was added.
Figure 3. Screenshot of the Zond 265 file encoded using the corrected universal encoding configuration.
Thus, based on the testing, a list of options is proposed to improve the encoding efficiency (improving the SSIM metric with the same bitrate and encoding speed) for fast and universal encoding configurations. Using the proposed changes for a file with a lot of small details, the value of the integral “quality measure” of the “MSU HEVC Video Codec Comparison” report improved by 31% for quick transfer, and 15% when universal, the coding rate did not change significantly. Because Since testing was carried out for each option separately, in practice, you can select and use only some convenient options, and not the entire proposed list.