x265 HEVC Encoder

[benwaggoner]

Originally Posted by TomV

When I was tuning x265's presets, I tried all of these options that go beyond placebo, to see what should be included in placebo. You and anyone else are welcome to try them again, but I found it was easy to massively increase encode times, but impossible to get any meaningful improvement in efficiency.

Indeed. “—me full —cu-lossless” will tank speed unbelievably without even trivial quality improvements for typical content and use cases.

I have seen visible and measurable value from ref 6, bframes 16, and tskip at <150 Kbps. Of course, using a lot of MIPS/pixel isn’t nearly so painful at low frame sizes and bitrates.

[RainyDog]

Originally Posted by benwaggoner

Yeah, subme does have some impact on rate control, but --rd is where the action is at.

From x265.readthedocs.io

Well yeah, that's why I asked. As --subme in the x265 docs doesn't specifically mention RDO.

But in x264 it's :-

subme

Default: 6

Set the subpixel estimation complexity. Higher numbers are better. Levels 1-5 simply control the subpixel refinement strength. Level 6 enables RDO for mode decision, and level 8 enables RDO for motion vectors and intra prediction modes. RDO levels are significantly slower than the previous levels.

QPel SAD 1 iteration
QPel SATD 2 iterations
HPel on MB then QPel
Always QPel
Multi QPel + bime
RD on I/P frames
RD on all frames
RD refinement on I/P frames
RD refinement on all frames
QP-RD (requires --trellis=2, --aq-mode > 0)

So it seems to me that --subme in x265 is as per --subme 1-5 in x264.

And the RD stuff of x264 --subme 6-11 is branched off into it's own thing in x265 with selectable RDO levels, rd-refine as a separate option etc.

[LigH]

x265 2.9+4-471726d3a046

fixes: rowStat computation in const-vbv; memory reset size in dynamic-refine; linking issue on non x86 platform

[Dclose]

Originally Posted by benwaggoner

Say, does anyone have any data showing potential benefits of using some of the "beyond placebo" settings?

For example[LIST=1][*]--subme 6 or 7 instead of 5

I don't know what data you're looking for besides "yes, it looks better." I wrote the following some months back in this thread:

1) imo, if you care about things that move, (and picture quality in general), you have to use sub-motion pixel subme 7. 5 is good, and is as low as I ever set that even on files I'm trying to finish fast, but 5 is easily visually inferior to 7 imo. 7 of course takes longer to encode though.

I'm usually around CRF 22-23 (with nearly all quality settings turned on). It probably has lesser effect at CRF 18.

[RainyDog]

For 2-pass encodes, I normally use a custom faster 1st pass command line which is the same as my slow 2nd pass just with RDO level and subme turned down to level 2, --me dia, --early-skip and --fast-intra.

But I've been testing using identical command lines for both passes and using --multi-pass-opt-analysis instead which speeds up the 2nd pass considerably to the point where a complete 2-pass encode is almost the same speed as my usual approach.

Which should technically yield the higher quality final result? Is there any potential harm to using --multi-pass-opt-analysis?

[Majorlag]

Originally Posted by RainyDog

Which should technically yield the higher quality final result? Is there any potential harm to using --multi-pass-opt-analysis?

Don't forget to also include --multi-pass-opt-rps --multi-pass-opt-distortion to your command line as well.
I understand that if your NOT turning down --RDO, --me and other settings then it should produce better results since it will spend more time on those settings in first pass. The --mulit-pass options are great in reusing the values obtained in the first pass to increase the speed of the second pass.

[atrin]

Hi,

I have some sample tabels for lamda2 and I generated a table of lambda based on it. This is the address of my sample https://mailman.videolan.org/piperma...ch/010936.html
The second table is not related with its formula (lambda2 = 0.038 * pow(0.234, QP))

is there any document or information that explains lambda and lambda2 tables and relations?

Many thanks

[Jamaika]

Problems with metric VMAF.

After many hours, I managed to adjust the items VMAF. The new addition even recalculates something.

Read input model (libsvm) at ./vmaf_rb_v0.6.2/vmaf_rb_v0.6.2.pkl.model ...
…
Initialize storage arrays...
Extract atom features...
frame: 0, adm: 0.986, adm_num: 792.386, adm_den: 803.249, adm_num_scale0: 102.293, adm_den_scale0: 105.547, adm_num_scale1: 148.311, adm_den_scale1: 151.745, adm_num_scale2: 230.474, adm_den_scale2: 232.816, adm_num_scale3: 311.307, adm_den_scale3: 313.141, motion: 0.000, motion2: 0.000, vif_num_scale0: 3201540.000, vif_den_scale0: 4265149.500, vif_num_scale1: 915769.438, vif_den_scale1: 973015.313, vif_num_scale2: 237178.438, vif_den_scale2: 244942.781, vif_num_scale3: 62793.887, vif_den_scale3: 64002.453, vif: 0.796,
Generate final features (including derived atom features)...
Normalize features, SVM regression, denormalize score, clip...
frame: 0, adm2: 0.986477, adm_scale0: 0.969174, adm_scale1: 0.977376, adm_scale2: 0.989942, adm_scale3: 0.994142, motion: 0.000000, vif_scale0: 0.750628, vif_scale1: 0.941167, vif_scale2: 0.968301, vif_scale3: 0.981117, vif: 0.796321, motion2: 0.000000,
Exec FPS: 2.742952
VMAF score (mean) = 100.000000
x265 [info]: frame I: 1, Avg QP:23.64 kb/s: 5696.20
x265 [info]: frame P: 2, Avg QP:29.09 kb/s: 874.10
x265 [info]: frame B: 7, Avg QP:35.33 kb/s: 204.03
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 33.3% 0.0% 0.0% 33.3% 33.3% 0.0% 0.0% 0.0% 0.0%

However, how to use it? So many ads on the forum.

static const x265_vmaf_commondata vcd_yuv420p[] = { { (char *)"yuv420p", (char *)"./vmaf_rb_v0.6.2/vmaf_rb_v0.6.2.pkl", (char *)"vmaf_yuv%04d.json", (char *)"json", 0, 1, 1, 0, 0, 0, 0, (char *)"mean", 0, 3, 1 } };

The first two items are obvious. They concern the color of subsampling and the version VMAF. Due to the fact that I chose version 0.6.2, the last item 'enable_conf_interval' must be included.
Then, the recording items metric VMAF in the files json or xml. These are the next two positions from the left. Here are the problems. First of all, I don't know why the program doesn't save all parameters in one file. Secondly, I can't force a program to save json/xml files one after another to the number of processed frames. (vmaf_yuv%04d)
{
"version":"1.3.7",
"params":{
"model":"",
"scaledWidth":1920,
"scaledHeight":1080,
"subsample":3
},
"metrics":[
"adm2",
"bagging",
"ci95_high",
"ci95_low",
"motion2",
"stddev",
"vif_scale0",
"vif_scale1",
"vif_scale2",
"vif_scale3",
"vmaf"
],
"frames":[
{
"frameNum":0,
"metrics":{
"adm2":0.98648,
"bagging":99.62585,
"ci95_high":100.0,
"ci95_low":98.12069,
"motion2":0.0,
"stddev":0.7394500000000001,
"vif_scale0":0.75063,
"vif_scale1":0.94117,
"vif_scale2":0.9683,
"vif_scale3":0.98112,
"vmaf":100.0
}
}
]
}
Next, what is the items 'disable_clip' and 'enable_transform' for?
The next four items phone_model, psnr, ssim, ms_ssim should be turned off.
Choice of data processing method
Choosing the number of cores. In my case, zero.
Problem with the color n_subsample parameter. For BPG, once there are three for YUV, once there should be one for the alpha color. The instruction is five.

Ok, I created x265 files with VMAF and without:
- The X265 VMAF codec doesn't work with FFmpeg.
av_interleaved_write_frame(): Broken pipe
No more output streams to write to, finishing.
Error writing trailer of pipe:: Broken pipe

ffmpeg.exe -loglevel verbose -i Untitled.mp4 -an -f yuv4mpegpipe -vf scale=1920:1080:in_color_matrix=bt709:in_range=limited:out_color_matrix=bt709:out_range=limited,format=yuv420p -strict -1 - | 
x265_081012bit_hdr_vmaf.exe --y4m --input-csp i420 --input-depth 8 --output-depth 8 --preset veryslow --crf 28 --fps 25.000 --keyint 50 --info --no-open-gop 
--colormatrix bt709 --colorprim bt709 --transfer bt709 --limit-ref 0 --range limited --recon 111.yuv --output 111.h265 -

- I don't know what is the 'recon' function for VMAF for?
In the description:
-r/--recon <filename> Reconstructed raw image YUV or Y4M output file name

- Strange, the x265 vmaf itself works, but it isn't known whether the codec should have an output file or not?
Assuming he has. This file does not differ in content from the recon file. In addition, these files don't differ from x265 files without VMAF. I don't have a concept for what it is and what is the recon file for?

[LigH]

The "recon" feature writes a YUV or Y4M raw video file that contains the reconstructed video which has been decoded right after encoding it, so you can compare the compression results with the original source (assuming it was a YUV or Y4M file too) without calling an additional decoder. It is available independently of VMAF functions linked into x265 – which may still be possible only under Linux, I believe; are you sure your Windows build contains any VMAF comparison code? The build script source\CMakeLists.txt contains the check clearly in a "if(UNIX)" block.

[Jamaika]

Originally Posted by LigH

... which may still be possible only under Linux, I believe; are you sure your Windows build contains any VMAF comparison code? The build script source\CMakeLists.txt contains the check clearly in a "if(UNIX)" block.

I created a version for Windows 2.9+8. I almost doesn't change anything. Codec hasn't only 'threads' for VMAF as I wrote earlier.
https://www.sendspace.com/file/r90y0d
Probably it can also be created in MSVC.

[Barough]

x265 v2.9+8-27d8424c799d (32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/stable

[Ma]

Originally Posted by Wolfberry

(64-bit GCC 8.2.0 8+10+12bit multilib / ICC 19.0 8/10/12 cli+shared)

ICC binaries not working in my Win10 (missing dll's).

[Natty]

hi, i would like to know how qcomp works in simple language, and it's impact on bitrate when its lowered or increased from its default value

[LigH]

--qcomp <float>

qComp sets the quantizer curve compression factor. It weights the frame quantizer based on the complexity of residual (measured by lookahead). It’s value must be between 0.5 and 1.0. Default value is 0.6. Increasing it to 1.0 will effectively generate CQP.

The default value 0.6 is a balance between a constant quantizer (regardless of the video content) and the complexity of the video content (degree of details and amount of motion) providing chances to spare bitrate by increasing the quantizer slightly in scenes where it may be sufficient to preserve enough quality with little noticeable loss.

IIRC, if you could decrease it to 0.0, the encoder would try its best to keep a constant bitrate (CBR), which would cause a very varying amount of quality loss (I might be wrong here, for x265, though). Increasing it to 1.0 instead would cause a constant quantization which would not take advantage of the possible ways to spare bitrate in scenes where convenient quality preservation could already be achieved with less bitrate, at a coarser quantization than the target.

You may increase this value a little (e.g. towards 0.8) when you notice that there is too much loss of precision in areas with very little detail, e.g. darkness and smooth ramps, especially in cases when your target bitrate is rather low. On the other hand, there may be other (psycho-visual) options to let the encoder not spare too much bitrate.

[Ma]

Originally Posted by Wolfberry

@Ma Test version available. If any of these works, some benchmarks will be appreciated.

x265_MT.exe works, thanks! I will make some test with '--no-asm' option to compare only C++ compilers.

[Ma]

Test platform: Win10 64-bit home, i7 8700 + be quiet pure rock, 16 GB RAM DDR4 @ 3866
Command line (only 8-bit encoding):
x265 --no-asm --crf 20 ../Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m w.hevc

Results in fps (encoding speed, mean value from 2 runs):
8.98 fps -- ICC AVX2
8.41 fps -- GCC 9.0 AVX2 ucrt
7.36 fps -- GCC 8.2 AVX2
7.34 fps -- GCC 8.2 AVX2 ucrt
7.12 fps -- GCC 7.3 AVX2 ucrt
7.11 fps -- GCC 6.5 AVX2 ucrt
6.30 fps -- GCC 5.5 AVX2 ucrt
5.93 fps -- GCC 8.2 generic Barough build
5.57 fps -- GCC 4.9.4 AVX2 ucrt
5.06 fps -- VS 2017 AVX2
4.89 fps -- VS 2015 AVX2
4.72 fps -- GCC 4.8.5 AVX2 ucrt

ucrt means Universal CRT (it is replacement for msvcrt.dll)
Results with asm was 29 up to 30 fps for all contenders (full results in screen.txt).

ICC 19 is clear winner, GCC 9 in second place. VS 2017/2015 without asm are really slow (but with asm are good/the best).

[poisondeathray]

Thanks Ma for those tests. Wow, that's a large % variation in speed

[FranceBB]

Originally Posted by Ma

Test platform: Win10 64-bit home, i7 8700 + be quiet pure rock, 16 GB RAM DDR4 @ 3866
Command line (only 8-bit encoding):
x265 --no-asm --crf 20 ../Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m w.hevc

Results in fps (encoding speed, mean value from 2 runs):
8.98 fps -- ICC AVX2
8.41 fps -- GCC 9.0 AVX2 ucrt
7.36 fps -- GCC 8.2 AVX2
7.34 fps -- GCC 8.2 AVX2 ucrt
7.12 fps -- GCC 7.3 AVX2 ucrt
7.11 fps -- GCC 6.5 AVX2 ucrt
6.30 fps -- GCC 5.5 AVX2 ucrt
5.93 fps -- GCC 8.2 generic Barough build
5.57 fps -- GCC 4.9.4 AVX2 ucrt
5.06 fps -- VS 2017 AVX2
4.89 fps -- VS 2015 AVX2
4.72 fps -- GCC 4.8.5 AVX2 ucrt
.

Very interesting.
I knew that Intel Parallel Studio (and its compiler) was good, but what surprises me is that GCC has become better and better.
Visual Studio used to be good for AVX2, while GCC used to be better for SSE2/SSSE3/SSE4.1, but perhaps things have changed and GCC now totally outperforms Visual Studio.

[nevcairiel]

Do keep in mind that these tests are absolutely disjunct from reality. Noone is going to run something like x265 without ASM, so for any real-world use these numbers are meaningless.

[FranceBB]

Originally Posted by nevcairiel

Do keep in mind that these tests are absolutely disjunct from reality. Noone is going to run something like x265 without ASM, so for any real-world use these numbers are meaningless.

Well, of course.
Still, in an ideal world, compilers would be able to produce optimized assembly code as fast as manually-written intrinsics, so there's no need to manually write them.

Unfortunately, that's still an utopia.

Anyway, for 10/12bit x265 on x86 32bit systems (for which there aren't manually written intrinsics available and builds rely on compiler optimization only), compilers "speed tests" are kinda useful. ^_^