x265 HEVC Encoder

[Barough]

x265 v3.5+8-57e817329 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/master

[benwaggoner]

And the 3.5 release notes are in github. With some minor formatting fixes:


Version 3.5
===========

Release date - 16th March, 2021.

New feature
-----------
1. Real-time VBV for ABR (Average BitRate) encodes in --pass 2 using option '--vbv-live-multi-pass': Improves VBV compliance with no significant impact on coding efficiency.

Enhancements to existing features
---------------------------------
1. Improved hist-based scene cut algorithm: Reduces false positives by leveraging motion and scene transition info.
2. Support for RADL pictures at IDR scene cuts: Improves coding efficiency with no significant impact on performance.
3. Bidirectional scene cut aware Frame Quantizer Selection: Saves bits than forward masking with no noticeable perceptual quality difference.

API changes
-----------
1. Additions to x265_param structure to support the newly added features and encoder enhancements.
2. New x265_param options option '--min-vbv-fullness' and option '--max-vbv-fullness' to control min and max VBV fullness.

Bug fixes
---------
1. Incorrect VBV lookahead in option '--analysis-load' option '--scale-factor'.
2. Encoder hang when VBV is used with slices.
3. QP spikes in the row-level VBV rate-control when WPP enabled.
4. Encoder crash in option '--abr-ladder'.

[benwaggoner]

I'm curious about "2. Support for RADL pictures at IDR scene cuts: Improves coding efficiency with no significant impact on performance."

Has anyone tested with this? I found some value in --radl with fixed-GOP CBR encoding some years back, but haven't played with it much since. The description doesn't sound any different than what it was originally released in 2.7.

Although I see in ReadtheDocs that its use in variable GOP encoding has been added.

--radl <integer>
Number of RADL pictures allowed infront of IDR. Requires closed gop interval. If enabled for fixed keyframe interval, inserts RADL at every IDR. If enabled for closed gop interval, in case of --hist-scenecut inserts RADL at every hard scenecut whereas for the --scenecut, inserts RADL at every scenecut. Recommended value is 2-3. Default 0 (disabled).

**Range of values: Between 0 and –bframes

I had not theorized that RADL would be of general benefit at hard scene cuts before. Anyone have any experience/data on this front?


P.S. MultiCoreWare, remember to update the Release Notes on ReadTheDocs! It looks like all the new parameters have already been added.

[vpupkind]

Originally Posted by ghostshadow

Hello, I have a problem with my settings since version 3.4 + 26 of x265 (I am currently in 3.5_RC2, windows 10 64bit, PC Ryzen 3900x).
My concern is in increasing my Avg QP, I am almost always above 24, whereas before with version 3.4 + 20 I managed to have my Avg QP below 20.
here are the parameters used for the3.5_RC2 : --scenecut-aware-qp 3 --masking-strength 500,2,0,200,-1,-1 **** I also tested: --scenecut-aware-qp 1 --masking-strength 300,2,2 *** --scenecut-aware-qp 3 --masking-strength 500,5,6.5,100,-1,-1
for the rest of the parameters : --rd 6 --rskip 2 --deblock -3:-3 --cutree --ctu 64 --min-cu-size 8 --bframes 4 --b-adapt 2 --rc-lookahead 60 --ref 4 --limit-refs 2 --merange 57 --subme 7 --aq-mode 4 --aq-strength 0.70 --me 3 --psy-rd 2.10 --psy-rdoq 1.35 --gop-lookahead 54
I tested by increasing my --bframes and reducing my --gop-lookahead, it is a little better but nothing more.
In 3.4 + 20 I had this in parameters: --scenecut-aware-qp --scenecut-window 500 --qp-delta-ref 6 --qp-delta-nonref 7 and my QP was impeccable
Thank you for your help

Have you tried using just --scenecut-aware-qp 3 --masking-strength 500,-1,-1 ?

Also, what happens to quality?

[ghostshadow]

Originally Posted by vpupkind

Have you tried using just --scenecut-aware-qp 3 --masking-strength 500,-1,-1 ?

Also, what happens to quality?

The quality is very good on my zidoo. But also before.
I don't think I tested the --scenecut-aware-qp 3 with only fwdWindow, fwdRefQPDelta and fwdNonRefQPDelta.
Because in this case the much to be in --scenecut-aware-qp 1? No ?

[LigH]

New upload: x265 3.5+8-57e817329

Bugs not yet fixed:

• NASM 2.15.05 multi-line macro warnings (reported August 2020)

[filler56789]

Originally Posted by LigH

New upload: x265 3.5+8-57e817329

Bugs not yet fixed:

• NASM 2.15.05 multi-line macro warnings (reported August 2020)

Can't you somehow force MABS to use an older version of nasm?

[LigH]

I see no reason to downgrade. Despite 9 MB of warnings scrolling through, it still works correctly. MABS wants to keep MSYS2 up-to-date, that's sensible. A fix similar to the one in x264 has been proposed to the x265 team but got denied. As a workaround, I wonder if there is an easy way to disable legacy warnings for NASM by adding the CLI parameter mentioned in the warning.

[tormento]

Originally Posted by LigH

x265 3.5+8-57e817329

The number after "+", i.e. +8, is the number of applied patches?

[Boulder]

Originally Posted by tormento

The number after "+", i.e. +8, is the number of applied patches?

I think it's the number of commits in that particular release branch since the initial release.

[LigH]

What Boulder said.

IIRC, a specific commit gets the tag "version 3.5" assigned, which may happen "belated" (does not need to be the tip of the branch while assigning).

[ShortKatz]

Originally Posted by LigH

Bugs not yet fixed:

• NASM 2.15.05 multi-line macro warnings (reported August 2020)

Yes, this is a bit annoying. I submitted a patch for this. But they didn't like, even though it was exactly the same which was done for x264.

[Barough]

x265 v3.5+9-bf91444e0 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/master

[tormento]

Originally Posted by LigH

Is it even measurable when the core routines are all assembler optimized already?

In the spare time, I did some tests.

HEVC encoder version 3.5+20-4c4aee0bc [DJATOM's Mod] - SandyBridge build: 4.15 fps

HEVC encoder version 3.5+20-4c4aee0bc [DJATOM's Mod] - generic build: 3.51 fps

HEVC encoder version 3.5+9+14-6c69ed37d [Mod by Patman] - generic build: 3.76 fps

As you can see, there is some gain.

------------------------- System Environment -------------------------

StaxRip : 2.3.0
Windows : Windows 10 Enterprise 2009
Language : Italian (Italy)
CPU : Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz
GPU : NVIDIA GeForce GTX 1060 3GB, Intel(R) HD Graphics 3000

------------------------- Source Script Info -------------------------

Width : 1440
Height : 1080
Frames : 6984
Time : 04:51.291
Framerate : 23.976023 (24000/1001)
Format : YUV420P8

--------------------------- Video encoding ---------------------------

D:\Eseguibili\Media\StaxRip\Apps\Encoders\x265\x265.exe --crf 22 --preset slow --output-depth 10 --colorprim bt709 --colormatrix bt709 --transfer bt709 --range limited --input-depth 16 --dither --output "F:\In\4_02 Zack Snyder's Justice League\Justice_0_temp\Justice_0_out.hevc" "F:\In\4_02 Zack Snyder's Justice League\Justice_0_temp\Justice_0.avs"

[LeXXuz]

Originally Posted by tormento

In the spare time, I did some tests.

HEVC encoder version 3.5+20-4c4aee0bc [DJATOM's Mod] - SandyBridge build: 4.15 fps

HEVC encoder version 3.5+20-4c4aee0bc [DJATOM's Mod] - generic build: 3.51 fps

HEVC encoder version 3.5+9+14-6c69ed37d [Mod by Patman] - generic build: 3.76 fps

Btw. are there any Zen+/Zen2 optimized builds, if any at all?

[DJATOM]

Yes, I'm also using zen2 build.

[benwaggoner]

Originally Posted by DJATOM

Yes, I'm also using zen2 build.

Someone who is good at such things could do us all a big favor by having a page of x265 binaries optimized for common cpu architectures.

That big a perf gain as reported above is surprising. And suggests that profile guided optimization may also yield some further perf benefits.

[LeXXuz]

Originally Posted by benwaggoner

Someone who is good at such things could do us all a big favor by having a page of x265 binaries optimized for common cpu architectures.

That big a perf gain as reported above is surprising. And suggests that profile guided optimization may also yield some further perf benefits.

Second that. Even a small percentage in performance increase would be great and really pay off for bigger projects.

I'm a complete noob when it comes to compiling and would love to have an optimized build for my 39x0 Ryzen machines.

[DJATOM]

You can grab those optimized builds from my repo: https://github.com/DJATOM/x265-aMod/...s/tag/3.5%2B20
They are all in the 7z archive, since it's easier to upload stuff to github with single file.
Zen3 flags aren't present in gcc10 (but that available with gcc11), so no such build for now. I'll consider doing it when will buy 5950x.

PS: cpu-specific builds are 10-bits only, while generic is multilib.

[tormento]

Originally Posted by DJATOM

You can grab those optimized builds from my repo

Thanks for your work, that I appreciate with x264 too.

I am always wondering why, on modern computers, you and others builders keep on crunching x265.exe with upx