x265 HEVC Encoder

[LigH]

CRF means: Constant Rate Factor. It keeps an internal distortion metric in the encoding workflow (called "rate factor") below a threshold. But many details are part of the RF calculation, and not all represent your personal subjective quality impression perfectly. Yet, it is a much better one than PSNR and allows an easy adjustment of the quantization with some respect to the encoding complexity. But a few seemingly paradox results may happen. Heavier efforts do not always result in more efficient video stream code or visually more convenient pictures, exceptions from a general rule aren't impossible.

[jlpsvk]

welcome back LigH. Missing new builds from you. Haven't seen you for a longer time here active.

[katzenjoghurt]

Originally Posted by StvG

Hey. A week ago or so I tested VS2019 builds and I had no problems when using zones. GCC builds were crashing when using zones.

Oh man. You put my hopes so high...
Tried out RC1+3 (built with VS2019) but... no luck - it still crashes for me.

Video encoding [...] failed with exit code: -1073740940 (0xC0000374)

The exit code might be a system error code: Ein Heap wurde beschädigt.

[...]
x265 [info]: HEVC encoder version 3.1_RC1+3-3bdf06e3c628
[...]

*sigh*

[benwaggoner]

So, I am trying to do a lossless HDR encoding test.

x265.exe - --y4m --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --hdr --hdr-opt -o 4K_LOSSLESS.hevc

And I get this error, which sounds like hdr-opt is getting deactivated because it is confused about the metadata?

Output #0, yuv4mpegpipe, to 'pipe:':
Metadata:
encoder : Lavf58.27.103
Stream #0:0: Video: wrapped_avframe, yuv420p10le, 3840x2160, q=2-31, 200 kb/s, 24 fps, 24 tbn, 24 tbc
Metadata:
encoder : Lavc58.53.100 wrapped_avframe
y4m [info]: 3840x2160 fps 24/1 i420p10 unknown frame count
raw [info]: output file: D:\Octarine\foo_4k_HDR.hevc
x265 [info]: HEVC encoder version 3.1_RC1+3-3bdf06e3c628
x265 [info]: build info [Windows][MSVC 1921][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [error]: Recommended Settings for HDR: colour primaries should be BT.2020,
transfer characteristics should be SMPTE ST.2084,
matrix coeffs should be BT.2020,
the input video should be 10 bit 4:2:0
Disabling offset tuning for HDR videos
x265 [warning]: Turning on repeat-headers for HDR compatibility

Everything seems set up just fine. Any thoughts about what might be going on here?

[LigH]

Originally Posted by jlpsvk

welcome back LigH. Missing new builds from you.

Ah, well ... had some issues with other projects compiled in MABS, and more work thus less spare time. And there are so many competitors now. But a "merge with stable" is a reason to publish another one.

[Blue_MiSfit]

@benwaggoner I'd suggest patching out the feature that disables hdr-opt in certain conditions. You certainly know what you're doing and it's a one-line fix

[benwaggoner]

Originally Posted by Blue_MiSfit

@benwaggoner I'd suggest patching out the feature that disables hdr-opt in certain conditions. You certainly know what you're doing and it's a one-line fix

First off, I want to know what the conditions are. I don't dismiss the possibility that I don't know what I'm doing in some aspect .

[Barough]

x265 v3.1+2-b36c03e4e771 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.1.0)

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

[Blue_MiSfit]

@benwaggoner

https://bitbucket.org/multicoreware/...cpp#lines-3316

if (p->internalCsp != X265_CSP_I420 || p->internalBitDepth != 10 || p->vui.colorPrimaries != 9 ||
            p->vui.transferCharacteristics != 16 || p->vui.matrixCoeffs != 9)

So, if any of the following are NOT true x265 will disable hdr-opt

4:2:0
10 bit
color primaries = 9 (bt2020)
transfer characteristics = 16 (smpte2084)
matrix coefficients = 9 (bt2020nc)

It does look like you're set up correctly, so no idea why this is happening.

I've found hdr-opt to be helpful for Dolby Vision Profile 5 encoding, which is incompatible with the required VUI to enable it, so I just patched out the above code block

[StvG]

Originally Posted by katzenjoghurt

Oh man. You put my hopes so high...
Tried out RC1+3 (built with VS2019) but... no luck - it still crashes for me.

Video encoding [...] failed with exit code: -1073740940 (0xC0000374)

The exit code might be a system error code: Ein Heap wurde beschädigt.

[...]
x265 [info]: HEVC encoder version 3.1_RC1+3-3bdf06e3c628
[...]

*sigh*

gcc:

avs2yuv_x64 -depth 10 1.avs -o - | x265-10b.exe --y4m - --level-idc 5.1 --high-tier --ref 6 --bframes 12 --rd 4 --me 3 --subme 5 --merange 57 --ipratio 1.2 --pbratio 1.1 --aq-mode 3 --aq-strength 0.95 --qcomp 0.70 --psy-rd 1.35 --psy-rdoq 1.20 --ctu 32 --rc-lookahead 60 --deblock -3:-3 --cbqpoffs 0 --crqpoffs 0 --qg-size 8 --no-rskip --no-rect --no-amp --no-sao --no-open-gop --no-early-skip --no-cutree --tu-intra-depth 4 --tu-inter-depth 4 --range limited --aud --repeat-headers --hrd --hdr-opt --colorprim bt2020 --colormatrix bt2020nc --transfer smpte2084 --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,20)" --max-cll=0,0 --input-depth 10 --chromaloc 2 --preset slower -o gcc.mkv --asm avx512 --zones 2100,3000,b=1.22/9000,10500,b=1.3/13000,13500,b=1.1/22000,22320,b=1.11/25000,25300,b=1.15 --crf 17 > gcc.txt 2>&1

y4m  [info]: 1920x1080 fps 24000/1001 i420p10 unknown frame count
raw  [info]: output file: gcc.mkv
x265 [info]: HEVC encoder version 3.1_RC1+3-3bdf06e3c628
x265 [info]: build info [Windows][GCC 9.1.1][64 bit] 10bit
...
30194 frames: 5.47 fps, 20856.40 kb/s  
30198 frames: 5.47 fps, 20855.46 kb/s  
30201 frames: 5.47 fps, 20854.86 kb/s  
30206 frames: 5.47 fps, 20853.95 kb/s  
30210 frames: 5.47 fps, 20852.97 kb/s

vs2019:

avs2yuv_x64 -depth 10 1.avs -o - | x265-10bvs.exe --y4m - --level-idc 5.1 --high-tier --ref 6 --bframes 12 --rd 4 --me 3 --subme 5 --merange 57 --ipratio 1.2 --pbratio 1.1 --aq-mode 3 --aq-strength 0.95 --qcomp 0.70 --psy-rd 1.35 --psy-rdoq 1.20 --ctu 32 --rc-lookahead 60 --deblock -3:-3 --cbqpoffs 0 --crqpoffs 0 --qg-size 8 --no-rskip --no-rect --no-amp --no-sao --no-open-gop --no-early-skip --no-cutree --tu-intra-depth 4 --tu-inter-depth 4 --range limited --aud --repeat-headers --hrd --hdr-opt --colorprim bt2020 --colormatrix bt2020nc --transfer smpte2084 --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,20)" --max-cll=0,0 --input-depth 10 --chromaloc 2 --preset slower -o vs.mkv --asm avx512 --zones 2100,3000,b=1.22/9000,10500,b=1.3/13000,13500,b=1.1/22000,22320,b=1.11/25000,25300,b=1.15 --crf 17 > vs.txt 2>&1

y4m  [info]: 1920x1080 fps 24000/1001 i420p10 unknown frame count
raw  [info]: output file: vs.mkv
x265 [info]: HEVC encoder version 3.1_RC1+3-3bdf06e3c628
x265 [info]: build info [Windows][MSVC 1921][64 bit] 10bit
...
30194 frames: 5.32 fps, 20856.40 kb/s  
30197 frames: 5.32 fps, 20855.68 kb/s  
30199 frames: 5.32 fps, 20855.23 kb/s  
30201 frames: 5.32 fps, 20854.86 kb/s  
30205 frames: 5.32 fps, 20854.18 kb/s  
30207 frames: 5.33 fps, 20853.70 kb/s  
30210 frames: 5.33 fps, 20852.97 kb/s  
                                                                                
x265 [info]: frame I:    204, Avg QP:14.97  kb/s: 33917.45
x265 [info]: frame P:   3896, Avg QP:16.17  kb/s: 26657.95
x265 [info]: frame B:  26112, Avg QP:17.10  kb/s: 20900.09
x265 [info]: Weighted P-Frames: Y:2.8% UV:0.6%
x265 [info]: Weighted B-Frames: Y:5.6% UV:0.2%
x265 [info]: consecutive B-frames: 13.6% 1.0% 2.4% 9.0% 3.2% 7.3% 3.9% 24.4% 5.8% 4.8% 4.0% 14.9% 5.6% 

encoded 30212 frames in 5669.34s (5.33 fps), 21730.49 kb/s, Avg QP:16.97

GCC build didn't output the last lines with the statistics but the last encoded frame is identical to the vs last frame. Also GCC as always is a bit faster than VS at least for me.

Edit: GCC MediaInfo and VS MediaInfo. Both has zone-count=5

[MeteorRain]

Had anyone actually done any benchmark on x265 on GCC 8.3 and 9.1?
From past records 9preview was slower than 8 but how about now?

[StvG]

Couple days ago I tested x265 compiled with gcc-7/8/9-branch and all three builds gave me the same fps (<=1%).

[benwaggoner]

Originally Posted by benwaggoner

First off, I want to know what the conditions are. I don't dismiss the possibility that I don't know what I'm doing in some aspect .

It appears that the --lossless flag blocks --hdr-opt. Which makes total sense in retrospect, as lossless is QP 4.

So, right behavior, wrong error message.

[katzenjoghurt]

Originally Posted by katzenjoghurt

Oh man. I THINK I finally found a solution for my neverending problem with red areas getting blurred and/or blocky.

People already gave me a hint to use 10bit encoding or playing around with the crqpoffs parameter. Both didn't really help.

This changed drastically now after I converted the source to YV24 colorspace and encoded it with Main 444 10.

Suddenly the crqpoffs parameter started to work wonders and setting it to -1 already brought back most of the details.


How to do it in StaxRip 1.7.0.6:
1) Click on the "AVS Filter" label. Click "Profiles".
2) Find the [Misc] section and add this line to the bottom: ConvertToYV24 = ConvertToYV24()
3) Add the Filter now via right-click -> Misc -> ConvertToYV24
4) Go into the x265 encoder settings
5) In "Basic" chose the Main 444 10 profile.
6) In "Rate Control 1" set CR QB Offset to -1.

Meh.

And now I reallize that with Main 10 444...
a) ... the contrast is too high in VLC
b) ... the video won't play at all in Windows Media Player
c) ... while it works well in Kodi and Zoom Player.

[LigH]

x265 3.1+2-b36c03e4e771 (MSYS2, GCC 9.1.0)

New options / changes:

   --[no-]field                  Enable or disable field coding. Default disabled
   --[no-]early-skip             Enable early SKIP detection. Default enabled
   --max-merge <1..5>            Maximum number of merge candidates. Default 3
   --limit-refs <0|1|2|3>        Limit references per depth (1) or CU (2) or both (3). Default 1
   --[no-]b-intra                Enable intra in B frames in veryslow presets. Default enabled
   --[no-]fades                  Enable detection and handling of fade-in regions. Default disabled
   --max-cll <string>            Specify content light level info SEI as "cll,fall" (HDR).
   --[no-]cll                    Emit content light level info SEI. Default enabled

[Natty]

Originally Posted by MeteorRain

Had anyone actually done any benchmark on x265 on GCC 8.3 and 9.1?
From past records 9preview was slower than 8 but how about now?

it looks like the bug of hidden encoding settings is still there in x265-Yuuki-3.1_RC1+4-gf48f4d038+23.7z build

[MeteorRain]

Well I observed some performance regression so I'm keeping my GCC 8.3 for now. 1-3% slower with GCC 9.1 than 8.3 on my workstation.
It could be measurement error though.

@Natty Yea 3.1 RC1+4 was not properly compiled. Will remove it soon. I've properly revised the mod branch and that should be fixed in 3.1 GA.

[katzenjoghurt]

Originally Posted by StvG

[...]

I updated to the GCC build LigH posted a bit above (thx!) and it seems zones now aren't crashing for me as well any more. Hooray!!!!!

Can't explain why it worked for you but not for me before that.

[poisondeathray]

Originally Posted by LigH

New options / changes:

--[no-]fades Enable detection and handling of fade-in regions. Default disabled

Thanks for the build;

Any more info or discussion on this somewhere?

Is it sort of like the --fade-compensate patch from x264 ?

Is there anyway to modulate the strength ?


1) The setting is not currently reflected in the encoder settings (as read by mediainfo)

2) on a quick test, it seems to correctly detect and increase the bitrate in the fade area... But there seems to be a slight abrupt transition as it exits out of the fade, almost like "keyframe popping", when compared to without --fades . There is an I frame placed on the --fades encode, where it was a B on the without .

Just one observation, one test, so I'll take do some other tests before before making any preliminary conclusions...

[LigH]

Originally Posted by katzenjoghurt

I updated to the GCC build LigH posted a bit above (thx!) and it seems zones now aren't crashing for me as well any more. Hooray!!!!!

Can't explain why it worked for you but not for me before that.

Probably depending on details, due to the nature of the problem:

Fix double free in zones