x265 HEVC Encoder

[MonoS]

Originally Posted by benwaggoner

I think the older discs were mainly Profile 5, where the enhancement layer includes both quarter-scale video and metadata. x265 doesn't support that. Newer discs would be Profile 5, where the enhancement layer is just RPU metadata. But that requires a properly "shaped" base layer specific to the source and metadata, which is Y'CtCp and dynamically adjusts to the currently-used subset of the PQ curve for greater precision.

I think that what i'm talking about it's BDs with DoVi 7.6 (as per this document https://www.dolby.com/us/en/technolo...les-levels.pdf ) so standard 4k video content and additional enhancement layer

[Ma]

I've made a test with --merange 12/26/40/57/74/92 for --ctu 64 --qg-size 64 vs. --ctu 32 --qg-size 32

Command line:
for %m in (12 26 40 57 74 92) do (
x265 -p7 --bitrate 500 -f3333 --psnr --ssim --qg-size 64 --merange %m ../big_buck_bunny_1080p24.y4m w64-%m.hevc
x265 -p7 --bitrate 500 -f3333 --psnr --ssim --ctu 32 --merange %m ../big_buck_bunny_1080p24.y4m w32-%m.hevc
)

Results (in ctu block: speed (fps), PSNR, SSIM (dB)):

					ctu		
merange	|		64		|		32	
12	|	6.93	39.980	12.996	|	6.44	39.565	12.742
26	|	6.69	40.303	13.599	|	6.21	39.903	13.345
40	|	6.46	40.393	13.746	|	6.07	39.999	13.499
57	|	6.13	40.404	13.757	|	5.90	40.019	13.512
74	|	5.85	40.409	13.757	|	5.67	40.024	13.515
92	|	5.58	40.413	13.760	|	5.47	40.026	13.514

When --merange grows, the quality increases regardless of the size of --ctu (it may depend on the source movie).

For CPU with only 12 logical cores (6 physical) --ctu 64 is just better in preset slower for 1080p encoding.

[Motenai Yoda]

@Ma can you make results about --ctu 64 --qg-size 32 and --ctu 32 --qg-size 16 too?
maybe just for --merange 40 only

[jlpsvk]

why the hell was default aq-mode changed to 2 from 1???? my all encodes are bad now.

[nevcairiel]

If you rely on a specific setting that strongly, you should not rely on it being the default, and just specify it. Or as an alternative, not blindly update your encode pipeline without verifying that it still produces expected results.
For the record, the default was changed from 1 to 2, not the other way around.

[Boulder]

Originally Posted by nevcairiel

If you rely on a specific setting that strongly, you should not rely on it being the default, and just specify it. Or as an alternative, not blindly update your encode pipeline without verifying that it still produces expected results.
For the record, the default was changed from 1 to 2, not the other way around.

That's the reason why I have a long string of options in the command line even if most of them are the defaults of a specific preset.

[nevcairiel]

Personally I like the second option. Not blindly update, but validate new versions first.

[Selur]

Still waiting for them to update the documentation https://x265.readthedocs.io/en/latest/presets.html,..
Opened an issue entry for it (https://bitbucket.org/multicoreware/...-documentation) at the end of last year.
I get it that they change the defaults(/presets/tune) from time to time, but not updating the documentation do represent such fundamental changes is really annoying,...

[Boulder]

And a funny thing is that --no-rskip is supposed to be a default in --preset veryslow (and also --slower) but it's not according to the code. I reported the issue a long time ago but no one fixed it Doesn't matter to me though, I use --rskip all the time anyway.

[Selur]

@Boulder: yeah, looking at https://bitbucket.org/multicoreware/...cpp?at=default rskip is only disabled in placebo,
but the documentation:
- https://x265.readthedocs.io/en/latest/presets.html reports that is is disabled starting with slower.
- https://x265.readthedocs.io/en/default/presets.html reports that is is disabled starting with very slow.
-> wrong documentation is even worse than missing documentation
(same for https://bitbucket.org/multicoreware/....cpp?at=latest)

[jlpsvk]

ok... can you tell me why aq mode 2 is better? i noticed rapid lower bitrate with aq-mode 2... any impact on picture quality and fine detail retention? i am encoding with crf18

[Boulder]

Originally Posted by jlpsvk

ok... can you tell me why aq mode 2 is better? i noticed rapid lower bitrate with aq-mode 2... any impact on picture quality and fine detail retention? i am encoding with crf18

I didn't find mode 2 better than 1 in my test cases (reported earlier here in this thread) so I'm still using mode 1 with the default strength.

I think you need to find a new sweet spot for CRF since the bitrate demand is indeed quite different compared to mode 1, and I also think it depends heavily on the content.

[Ma]

Originally Posted by Motenai Yoda

@Ma can you make results about --ctu 64 --qg-size 32 and --ctu 32 --qg-size 16 too?
maybe just for --merange 40 only

Results in attachment -- it is a bit faster encoding but quality is worse (at the same bitrate).

[excellentswordfight]

Originally Posted by Ma

I've made a test with --merange 12/26/40/57/74/92 for --ctu 64 --qg-size 64 vs. --ctu 32 --qg-size 32

Command line:
for %m in (12 26 40 57 74 92) do (
x265 -p7 --bitrate 500 -f3333 --psnr --ssim --qg-size 64 --merange %m ../big_buck_bunny_1080p24.y4m w64-%m.hevc
x265 -p7 --bitrate 500 -f3333 --psnr --ssim --ctu 32 --merange %m ../big_buck_bunny_1080p24.y4m w32-%m.hevc
)

Results (in ctu block: speed (fps), PSNR, SSIM (dB)):

					ctu		
merange	|		64		|		32	
12	|	6.93	39.980	12.996	|	6.44	39.565	12.742
26	|	6.69	40.303	13.599	|	6.21	39.903	13.345
40	|	6.46	40.393	13.746	|	6.07	39.999	13.499
57	|	6.13	40.404	13.757	|	5.90	40.019	13.512
74	|	5.85	40.409	13.757	|	5.67	40.024	13.515
92	|	5.58	40.413	13.760	|	5.47	40.026	13.514

When --merange grows, the quality increases regardless of the size of --ctu (it may depend on the source movie).

For CPU with only 12 logical cores (6 physical) --ctu 64 is just better in preset slower for 1080p encoding.

I see, thanks for sharing.

I think you are correct, since the biggest benefit of reducing it only appears when going above arround 8C/16T (I was testing with 12/24 and went from 7fps to 11fps cause of the less thread utilization at CTU 64, and I would say that it was definitely was worth the trade off), it does makes since to keep it as an manual setting.

I would say though that it might be worth consideration to lower the merange for those fastets presets, since it doesnt seem to benefit quality that much.

[LigH]

Originally Posted by benwaggoner

I like DoVi as the short way to type it.

That might sound stupid to a German (Doofi ~ retarded kid)

Originally Posted by benwaggoner

a couple decades later!

I am old!
_

Some on-topic:

Support for Dolby Vision is announced, and immediately people believe that applications for decoding, possibly even encoding, for consumer PCs are available too ... which is doubtful. I wonder how "homeopathic" its additional features will be in a generic furnished living room, where average people can hardly tell the difference between DD AC3 and dts on a DVD Video, not to mention HD Audio formats.

To me, it seems that supporting such data is mainly for professional content producers. Might be a field where hobbyists can't help the developers much.

[sneaker_ger]

Originally Posted by LigH

Support for Dolby Vision is announced, and immediately people believe that applications for decoding, possibly even encoding, for consumer PCs are available too ... which is doubtful. I wonder how "homeopathic" its additional features will be in a generic furnished living room, where average people can hardly tell the difference between DD AC3 and dts on a DVD Video, not to mention HD Audio formats.

Oh, I'm sure the difference will be noticable to consumers. Simply because authors will make it so, not because it's superior. Just like in the past authors used different mixes for AC3 and DTS tracks on the same DVD. It's all about marketing.

[jd17]

Originally Posted by sneaker_ger

Oh, I'm sure the difference will be noticable to consumers. Simply because authors will make it so, not because it's superior.

That.

[Lucius Snow]

Hello all,

There's still no GPU support to speed up the encoding?

Thanks.

[LigH]

No. I believe because GPU features would not speed x265 up. At least not without risking a loss of quality or losing the independence from hardware and software platforms (portability).

GPU features are not magical general speed-ups for every case of use, sometimes they just don't match the requirements.

[jlpsvk]

Ok. Did a test. 3840x2160 res., same x265 settings. One with aq-mode 1 crf18 and second aq-mode 2 (which is now new default) with crf16. aq-mode 2 with crf16 still gives lower bitrate. which one "should" be better in terms of detail retention?

whole CLI (HDR parameters are added automatically by RipBot264):

-preset slow --profile main10 --level-idc 5.1 --output-depth 10 --ctu 32 --aq-mode 1 --amp --no-rskip --qg-size 8 --vbv-bufsize 160000 --vbv-maxrate 160000 --bframes 8
--rc-lookahead 48 --gop-lookahead 30 --hdr --hdr-opt --repeat-headers --no-info --no-deblock --no-sao --allow-non-conformance --no-strong-intra-smoothing --high-tier --asm avx512 --crf 18

-preset slow --profile main10 --level-idc 5.1 --output-depth 10 --ctu 32 --aq-mode 2 --amp --no-rskip --qg-size 8 --vbv-bufsize 160000 --vbv-maxrate 160000 --bframes 8
--rc-lookahead 48 --gop-lookahead 30 --hdr --hdr-opt --repeat-headers --no-info --no-deblock --no-sao --allow-non-conformance --no-strong-intra-smoothing --high-tier --asm avx512 --crf 16