x265 HEVC Encoder

[Barough]

Is there an updated x265 with aq-mode 5, beside the Patman ones?

Not by MulticoreWare. Only available in DJATOM's or Patman's compiles to my knowledge.

[tormento]

Only available in DJATOM's or Patman's compiles to my knowledge.
Unfortunately both have little or no time at the moment.

[PoeBear]

What are the best settings to tweak for better edge detection between elements? Eg. I've got a 1080p mixed AR source (16:9 and 4:3) and anytime there's a colorful part of the image that hits the black border, there's a 1px column that gets sapped of color. It also happens to a lesser effect for colorful objects against darker backgrounds

Here is a cropped example of the specific areas featuring both:
https://thumbs4.imagebam.com/02/ea/1e/MEDM6PN_t.PNG (https://www.imagebam.com/view/MEDM6PN) https://thumbs4.imagebam.com/4f/02/37/MEDM6PM_t.PNG (https://www.imagebam.com/view/MEDM6PM)
You'll notice the obvious colorless 1px line across the side, and on the curtain's edge you can see the color start to fade where it converges with the dimly lit room it's in:

I've compared various psy-rd/psy-rdoq levels, never higher than psy-rdoq 10, against the veryslow preset with a static bitrate of 30,000 for testing. None of those adjustments seem to make a dent in getting the color back, so I thought there might be a less obvious setting I should be tweaking

[LigH]

The reason is probably the YUV 4:2:0 chroma subsampling and the placement of the border at an odd numbered pixel column.

[benwaggoner]

The reason is probably the YUV 4:2:0 chroma subsampling and the placement of the border at an odd numbered pixel column.
That's a very sound theory. And if so, not much can be done about it.

That said, this sort of artifact should be extremely hard to detect visually, especially while playing and at a full-screen visible viewing distance.

[PoeBear]

The reason is probably the YUV 4:2:0 chroma subsampling and the placement of the border at an odd numbered pixel column.

Should that not show up on the source side as well then? It's a 10-bit 4:2:0 image out of the frameserver (which is what my screenshot is from). The non-border part of the image is mod8, as well as the border part

And you can also see it's affecting the cloth's edge, to a lesser degree, that's still within the main part of the image

That said, this sort of artifact should be extremely hard to detect visually, especially while playing and at a full-screen visible viewing distance.

I don't disagree, but some of my projects require static transparency (generally for future encoding use), plus solutions are always good to have in the pocket, you never know where else you can use them

[benwaggoner]

Should that not show up on the source side as well then? It's a 10-bit 4:2:0 image out of the frameserver (which is what my screenshot is from). The non-border part of the image is mod8, as well as the border part

And you can also see it's affecting the cloth's edge, to a lesser degree, that's still within the main part of the image

I don't disagree, but some of my projects require static transparency (generally for future encoding use), plus solutions are always good to have in the pocket, you never know where else you can use them
Ah, if it is from a 4:2:0 source, there are things that might be done.

If it is an issue from chroma compression, try reducing chroma QP.
--cbqpoffs -3 --crqpoffs -3

Those values are generally too strong for most real-world use, and may well make the video look worse overall as it takes bits out of luma. But if they fix your chroma issue, that suggests it is an encoding issue. If nothing else, find the closest-to-zero values for the above that fixes your issue.

Can you share your command line? I'd want to use nothing faster than --preset slow as that is the fastest that includes --rd 3+ and--subme 3+, which are the lowest levels where chroma is included.

Also, if you specify a --chromaloc that doesn't match the source, that could potentially make horizontal chroma a little off.

[Boulder]

Ah, if it is from a 4:2:0 source, there are things that might be done.

If it is an issue from chroma compression, try reducing chroma QP.
--cbqpoffs -3 --crqpoffs -3

Those values are generally too strong for most real-world use, and may well make the video look worse overall as it takes bits out of luma. But if they fix your chroma issue, that suggests it is an encoding issue. If nothing else, find the closest-to-zero values for the above that fixes your issue.


It's worth mentioning that the bitrate issue is not valid for CRF mode, it just compresses a bit less. I myself use -3 and -6 respectively (with non-HDR sources) but the reds are destroyed by the encoder no matter what offsets are used. Maybe this artifact is related to that.

I think x264 uses -3 and -3 internally.

[PoeBear]

Also, if you specify a --chromaloc that doesn't match the source, that could potentially make horizontal chroma a little off.

I think this might be it. Although in theory my chromaloc 2 matches my source, according to its MediaInfo: 4:2:0 (Type 2)

But if I throw a propSet("_ChromaLocation",2) at the very end of my script, the preview looks an awful lot like my encode output, with the colorless line now appearing. I'm guessing somehow after all of my plugins and scaling, the frame properties are being stripped/changed. When I set x265 to chromaloc 0 the line is back to near full color

After a bit of searching mid-post, it seems the culprit is somehow... the AddBorders (https://forum.doom9.org/showthread.php?t=176867) I was using to pad/match the 16:9 footage!? Who would have thought? But if I put AddBorders at the very end of my preview script, after it tonemaps with Cube, it no longer produces the faded line. Somehow AddBorders is changing the chromaloc, or something

Now to figure out how to change it back, or find an alternative border solution, so I can have my output/encode chromaloc match my input/source. If I use ConvertToYUV444 before AddBorders, and then ConvertToYUV420 right after, it lessens the color sapping by a significant amount, and looks about how the x265/chromaloc 0 setting looks, but still not "perfect". A z_ConvertFormat(chromaloc_op="bottom=>top_left") before the AddBorders also looks relatively similar to 444, but does shift the chroma in the rest of the image as well...

But I'm also thinking maybe the non-16:9 footage wasn't handled correctly in the source to begin with, because the ConverFormat call seems to look more natural, ie the color goes to the edges on the curtains on my previous source screen, and it doesn't seem to make anything else worse skipping through

I've got a lot to unpack/test :( Suggestions are welcome, but now it's drifting outside of this thread's focus

[benwaggoner]

I think this might be it. Although in theory my chromaloc 2 matches my source, according to its MediaInfo: 4:2:0 (Type 2)

But if I throw a propSet("_ChromaLocation",2) at the very end of my script, the preview looks an awful lot like my encode output, with the colorless line now appearing. I'm guessing somehow after all of my plugins and scaling, the frame properties are being stripped/changed. When I set x265 to chromaloc 0 the line is back to near full color
Ha! I thought it was likely that. I think any theoretical value in having different chromaloc is probably swamped by the difficulty in getting end-to-end chromaloc-accurate processing.

Now to figure out how to change it back, or find an alternative border solution, so I can have my output/encode chromaloc match my input/source. If I use ConvertToYUV444 before AddBorders, and then ConvertToYUV420 right after, it lessens the color sapping by a significant amount, and looks about how the x265/chromaloc 0 setting looks, but still not "perfect". A z_ConvertFormat(chromaloc_op="bottom=>top_left") before the AddBorders also looks relatively similar to 444, but does shift the chroma in the rest of the image as well...
Yeah, your the best bet is to probably to do everything in RGB or Y'CbCr 4:4:4, and then only convert to the final 4:2:0 as the very last step before encoding with a known-good conversion tool.

Also, some decoders/rendering pipelines used to ignore chromaloc, and do everything as if it was chromaloc 0. More than once I've realized something worked only because source processing and decoding both ignored chromaloc, and so reversed the other. I've not tested that recently.

Launching HDR in 2015 was...interesting!

[A1]

When looking at the discussion on the forum, I often see these two parameters. I have read its documentation many times, but I can't understand the causal relationship between its skipping mechanism and the improvement of image quality?

The moderators say that --tskip and --tskip-fast can improve the quality of animations. Besides animations, what types of images will the effects of --tskip affect?
Are there any inappropriate types?

It is known that the file size is smaller when only --tskip is used, and the encoding speed is faster when both --tskip and --tskip-fast are used.

So what is the difference in the effect of these two combinations on improving the picture quality?

Regardless of the compression ratio, which option will improve the picture quality better?

[rwill]

Also, if you specify a --chromaloc that doesn't match the source, that could potentially make horizontal chroma a little off.

This is somewhat unlikely. Chroma Loc 0,2,4 are left and Chroma Loc 1,3,5 are center on the horizontal axis.

The only Choma Locations that make sense in the current environment are 0 and 2, both left aligned. To find Chroma Loc 1,3,4 and 5 in the wild is no accident but almost borders on sabotage.

[rwill]

The moderators say that --tskip and --tskip-fast can improve the quality of animations. Besides animations, what types of images will the effects of --tskip affect?
Are there any inappropriate types?


Porn


It is known that the file size is smaller when only --tskip is used, and the encoding speed is faster when both --tskip and --tskip-fast are used.

So what is the difference in the effect of these two combinations on improving the picture quality?

Regardless of the compression ratio, which option will improve the picture quality better?

The option with the highest compression ratio will improve picture quality the most, in theory anyway.

[A1]

The same type will have different characteristics, and different types will also have the same characteristics. So what I want to ask is the specific shape characteristics, rather than the noun used in commodity classification.



The option with the highest compression ratio will improve picture quality the most, in theory anyway.

Your theory is more applicable to X264, but X265 has a lot more subjective compression options than X264, and these options can't be summarized in a simple set of theories. Psycho -Visual Options is one example, and --tskip and --tskip-fast are another similar example.

[benwaggoner]

This is somewhat unlikely. Chroma Loc 0,2,4 are left and Chroma Loc 1,3,5 are center on the horizontal axis.

The only Choma Locations that make sense in the current environment are 0 and 2, both left aligned. To find Chroma Loc 1,3,4 and 5 in the wild is no accident but almost borders on sabotage.
Sorry, yes. I meant vertical.

[benwaggoner]

Your theory is more applicable to X264, but X265 has a lot more subjective compression options than X264, and these options can't be summarized in a simple set of theories. Psycho -Visual Options is one example, and --tskip and --tskip-fast are another similar example.
That said, I'm not aware of any cases where using --tskip causes quality regressions. Have you seen some?

[microchip8]

That said, I'm not aware of any cases where using --tskip causes quality regressions. Have you seen some?

I've done almost a 100 encodes with --tskip enabled (--tskip 1) and honestly I can't see a difference nor are there any issues in all of the encodes.

I do have --tskip-fast disabled (--tskip-fast 0) so can't talk about that

[kedautinh12]

Source was 4K, downsampled to 1080p. These are the basic parameters that I've set:
--input-depth 16
--dither
--profile main10
--min-keyint 5
--keyint 480
--merange 44
--splitrd-skip
--preset veryslow
--rc-lookahead 60
--deblock -2:-2
--no-strong-intra-smoothing
--no-sao
--qcomp 0.8
--aq-mode 3
--aq-strength 0.8
--ctu 64
--max-tu-size 32
--rdpenalty 1
--qg-size 16
--tu-inter-depth 4
--tu-intra-depth 4
--limit-tu 4
--limit-refs 3
--max-merge 2
--rd-refine
--ref 6
--bframes 10
--crf 19
I've then also tested ctu 32 with max-tu-size 32 or 16.

In the 1080p encode, the bitrate is as follows:

CTU 64 / TU 32 - 15078 kbps
CTU 32 / TU 32 - 14608 kbps
CTU 32 / TU 16 - 14472 kbps

Of these, CTU 32 / TU 32 resembles the original the most. It's interesting that setting TU 16 also causes distortion in the same areas as CTU 64 / TU 32. I checked areas like eyes, hair etc. which have easily some sort of distortion because there are many fine lines and things that can be compared quite easily.

I've just started testing what CRF value is visually enough for 1080p so the final bitrate will probably be lower than what I got from my tests. I'd estimate CRF 20-21 would be the final value.

You still use those settings now??

[kedautinh12]

When i used settings about. The filesize of output file same as x264 or maybe larger than x264

[benwaggoner]

I've done almost a 100 encodes with --tskip enabled (--tskip 1) and honestly I can't see a difference nor are there any issues in all of the encodes.

I do have --tskip-fast disabled (--tskip-fast 0) so can't talk about that
For most content, tskip doesn't do much at all. It's only with really sharp, typically synthetic content where we see improvements. In a typical movie, I would only expect tskip to kick in for the opening and end credits, which are computer-rendered without any noise.

tskip might also help with burned-in subtitles, but I've not tested that deeply.

[Stereodude]

Do the latest builds that I see posted in the thread support opening a .avs directly or do they require piping?

Edit: I see they require piping. Where can I get a recent build that doesn't require piping? I think Wolfberry was posting them.

[jpsdr]

I've seen some new version posted here, but nothing related commited on the git : https://bitbucket.org/multicoreware/x265_git.git
Is it the proper git i'm using ?

[quietvoid]

I've seen some new version posted here, but nothing related commited on the git : https://bitbucket.org/multicoreware/x265_git.git
Is it the proper git i'm using ?

That's the correct official repo.
There are other forks with native frameserver support (AVS and VS).

[benwaggoner]

When i used settings about. The filesize of output file same as x264 or maybe larger than x264
Does the quality compare?

If you really want to understand quality @ bitrate, you'll need to compare 2-pass ABR encodes. There's certainly a high enough bitrate than x264 and x265 will converge on transparent quality.

Your settings have a lot of very specific stuff in them, and may not be an optimal combination of features. Starting with a preset and iterating from there is a simpler way to start where parameters have been extensively tested in that combination.

I've not seen anyone use --rdpenalty in at least five years. And --no-strong-intra-smoothing hasn't been demonstrated to actually improve anything, and can reduce detail if the reduced inefficiency pushed up QPs.

[A1]

That said, I'm not aware of any cases where using --tskip causes quality regressions. Have you seen some?

I read the documentation and learned that --tskip bypass DCT processing, but I am not an expert in related fields, so I want to ask the approximate principle between bypass DCT and improving image quality, otherwise --tskip is too mysterious.

I understand --tskip and psycho visual options as the same category, the reason is not --tskip causes quality regressions,
The reason is that they all give up a part of the mathematically optimal compression, both of which will increase kbs, and I guess DCT is part of the mathematically optimal compression.

So there are two choices here, a lower crf with --no-tskip, or a higher crf with --tskip, assuming they are the same bitrate.

Not sure about the principle of -tskip, it's really hard to choose.

[rwill]

I understand --tskip and psycho visual options as the same category, the reason is not --tskip causes quality regressions,
The reason is that they all give up a part of the mathematically optimal compression, both of which will increase kbs, and I guess DCT is part of the mathematically optimal compression.


The Transform Skip Tool is more or less for compression efficiency enhancement. It does not relate to psycho visual options. If enabled the ability to skip the transform or not for a transform unit will become available under certain conditions and an encoder might check if it is beneficial for compression. If a transform unit is then better coded with transform skipped than with the frequency transform the encoder will/should code the transform unit as such. There is a slight overhead associated with signalling transform skip but for most use cases the option for an encoder to skip the transform rarely becomes available anyway, making overhead a non issue.

[A1]

The Transform Skip Tool is more or less for compression efficiency enhancement.

Even though the original intention of designing the Transform Skip Tool is to reduce the time required for compression, the actual discussion and use are related to improving the subjective visual quality. DCT may have some adverse effects on subjective visual quality.
What exactly is the impact, it's not clear?


If a transform unit is then better coded with transform skipped than with the frequency transform the encoder will/should code the transform unit as such.

What is a better coding transform unit, and what criteria are used to judge it?

[rwill]

Even though the original intention of designing the Transform Skip Tool is to reduce the time required for compression
Actually it increases the time required for compression as more options for encoding become available by adding an encoding tool.

the actual discussion and use are related to improving the subjective visual quality.
I personally don't understand why though.

DCT may have some adverse effects on subjective visual quality.
What exactly is the impact, it's not clear?

Well, I suggest to stop worrying and just set a --preset, a --tune and --no-sao.

What is a better coding transform unit, and what criteria are used to judge it?
Rate/Distortion.

[benwaggoner]

Transform skip is described briefly in this post from the invaluable thread to understand how HEVC works under the hood: https://forum.doom9.org/showthread.php?p=1614299&highlight=transform+skip#post1614299

Yes, DCT is broadly optimal for natural image content. It converts from the pixel values to frequency values, which are much better tuned to the human visual system, which is very focused on seeing edges.

However, it is not optimal for coding sharp differences between adjacent pixels, which essentially have a infinite frequency. Hence transform skip, which can more efficiently code things like aliasing artifacts, alternating black/white checkerboard pixels, sharp edges of text, etcetera.

x265 will only pick tskip when it is more efficient than a DCT option. I'm not aware of it ever having any visual quality regression, but for live-action content, it rarely offers any benefit either. But digitally rendered scrolling end credits might save significant bits.

[Barough]

x265 v3.5+41-0b75c44
Built on October 05, 2022, GCC 12.2.0

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


32-bit
x265 [info]: HEVC encoder version 3.5+41-c02eb2842
x265 [info]: build info [Windows][GCC 12.2.0][32 bit] 8bit+10bit+12bit

64-bit
x265 [info]: HEVC encoder version 3.5+41-4be2fd080
x265 [info]: build info [Windows][GCC 12.2.0][64 bit] 8bit+10bit+12bit



NOTE:

The commit value is wrong due to something upstream at MulticoreWare.

Correct commit number for this release is
0b75c44



DL :
https://www.mediafire.com/file/tye1v6btgm4j9s1/

[ShortKatz]

Here is HEVC encoder version 3.5+40-0b75c44c1 precompiled for macOS. It is a fat binary that includes architectures x86_64; arm64; arm64e.
Build on October 16, 2022.
x265 [info]: HEVC encoder version 3.5+40-0b75c44c1
x265 [info]: build info [macOS][clang 14.0.0][64 bit][noasm] 8bit+10bit+12bit

https://polysom.verilite.de/tmp/x265_macOS.tar.gz
SHA256: 68498485a84089ce376ff6362123e3381e32ce1c5262092b66699872b9c3c6f6

[Ritsuka]

Why is compiled without asm? That's going to be slow.

[rwill]

Why is compiled without asm? That's going to be slow.

I was told by Apple fans that applications running on Apple devices are always fast enough regardless of their optimizations. So they are never slow.

[ShortKatz]

Why is compiled without asm? That's going to be slow.

I don't know why it does say noasm. It is build with ENABLE_ASSEMBLY=1. But as rwill said, it will be fast enough.

[Jamaika]

New upload: x265 3.5+37-0d865ebe2 (https://www.mediafire.com/file/znuc3jsmtsnx7jc/x265_3.5+37-0d865ebe2.7z/file)

[Windows][GCC 12.1.0][32/32XP/64 bit] 8bit+10bit+12bit

Bugs not yet fixed:

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

https://github.com/netwide-assembler/nasm/releases/tag/nasm-2.16rc1

[LigH]

Boy, these are warnings; it still works correctly. Just don't read the console while compiling. The only issue is that their output slows down the compilation process. But better that than a slow video encoding.
_

Oh, sorry, Jamaika; I assumed that was a reply to ShortKatz, but I doubt now.

[Jamaika]

Boy, these are warnings; it still works correctly. Just don't read the console while compiling. The only issue is that their output slows down the compilation process. But better that than a slow video encoding.
_

Oh, sorry, Jamaika; I assumed that was a reply to ShortKatz, but I doubt now.
No need to apologize. Another version of nasm.
What processors does x265 support for the AVX512?

[rwill]

No need to apologize. Another version of nasm.
What processors does x265 support for the AVX512?

Hey I can answer that one.

x265 checks cpuid eax=7, ecx=0 results for ebx=0xD0030000

see here:
https://bitbucket.org/multicoreware/x265_git/src/0b75c44c10e605fe9e9ebed58f04a46271131827/source/common/cpu.cpp#lines-204

now 0xd0030000 is 11010000000000110000000000000000b which you can check here:
https://en.wikipedia.org/wiki/CPUID#EAX=7,_ECX=0:_Extended_Features

so x265 requires: AVX-512 Foundation, AVX-512 Doubleword and Quadword Instructions, AVX-512 Conflict Detection Instructions, AVX-512 Byte and Word Instructions and AVX-512 Vector Length Extensions. Thats AVX512-*: F, DQ, CD, BW and VL in short.

This can be looked up here:
https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512

So, Intel apparently has quite a few unless they disable it for.. "reasons" and AMD seems to support it with Zen4.

* Note: Wikipedia might not be a reliable information source.

*edit*
Intel CPU capabilities are very confusing as they enable and disable features with each generations quite randomly, especially on Desktop.
I think its best to check the Intel Ark website to check if a CPU supports AVX512 or not.
Here:
https://ark.intel.com/

[FranceBB]

What processors does x265 support for the AVX512?

For what it's worth, I can only test with my very own CPU and all I can say is that it works with my Intel Xeon Gold 6238R, however you have to enable it as it's disabled by default. I probably have a screenshot somewhere.


EDIT: Found it, I'm gonna quote myself from last year:

x265 3.5+13-4c6880d

https://i.imgur.com/jSLRrzL.png

[Emulgator]

i9-11900K here: AVX512 yes, and one got to enable it in x265 CL, as FranceBB mentioned.

[LeXXuz]

Is AVX512 really that much of a holy grail some people do claim - regarding performance?

[LigH]

No. That's why its support is not auto-detected by default. It is a heat risk with only a small performance gain over AVX2.

[Jamaika]

For what it's worth, I can only test with my very own CPU and all I can say is that it works with my Intel Xeon Gold 6238R, however you have to enable it as it's disabled by default. I probably have a screenshot somewhere.
How can AVX2 enable?
I turn on basic SIMD X265.
#define ARCH_X86_64
#define HAVE_SSE3
#define HAVE_SSSE3
#define HAVE_SSE4
The rest of the AVX2 and AVX512 are probably default.
ARCH_X86_64 && cpuflag(avx512)

[benwaggoner]

How can AVX2 enable?

AVX2 on down are automatically enabled if available. AVX512 is the special case, as it is more likely to reduce performance than increase it.

[A1]

Will the current x265-3.5 encoder use ctu 64 parameters still cause 64x64 block textures to be weakened?

[vpupkind]

AVX2 on down are automatically enabled if available. AVX512 is the special case, as it is more likely to reduce performance than increase it.
I've seen <=5% improvement in motion estimation (umh) in Cascade Lake times, haven't tested on IceLake though. The problem used to be thermals -- a 900MHz frequency penalty due to use of AVX-512.

[FranceBB]

How?
ARCH_X86_64 && cpuflag(avx512)

You can enable any asm with the --asm command, like:

--asm avx512

the same goes if you want to enable only a specific set, like maybe you wanna try the speed differences between AVX512 and AVX so you can use

--asm avx

and so on and of course there's

--no-asm

for plain C.




AVX512 is the special case, as it is more likely to reduce performance than increase it.

...on consumer hardware.
Things are of course different in perfectly cooled down server rooms.

The problem used to be thermals -- a 900MHz frequency penalty due to use of AVX-512.

Correct. Temperatures skyrocket high and make the CPU throttle thus going down up to a point that it's no longer feasible and the speed gain is nullified.
This of course doesn't apply to server rooms where temperature and humidity is perfectly controlled and CPUs can keep a high enough clock under pressure like it happens with my encodes.

This is the situation while encoding a MJPEG2000 4:4:4 12bit HDR PQ IMF with x265 to create a consumer H.265 file (with AVX-512 enabled):

https://i.imgur.com/U6sWEAN.jpghttps://i.imgur.com/MpyQmOh.jpghttps://i.imgur.com/Sy45bRz.jpg

as you can see, clock fluctuates a bit, but given that the overall temperature of the server room is really low, the CPU is able to keep working at regime under sustained pressure and in this case AVX-512 really make sense, which is why they're enabled in all my workflows.

If it wasn't for the wide user-driven community and the open source nature of the project, I would argue AVX512 should be enabled by default just like other intrinsics, 'cause for companies it makes a whole lot of sense...

[excellentswordfight]

...on consumer hardware.
Things are of course different in perfectly cooled down server rooms.

? Not sure what you are on about, for example all Skylake-SP Xeons i've run avx512 code on downclocked ALOT more than my "consumer" Tiger-Lake laptop (and yeah the servers has ofc been in a proper server environment). This topic is a lot more complex then if you run the system in a cool room or not, and I'm pretty sure that most of the downclock on Xeons I've seen has been of powerlimit, not tempeture. AVX-512 behavior has been tweaked alot between models/platforms.

2,6Ghz looks rather good for 28C xeon under avx512 load. Mind sharing the frequency when you run x265 without it and the performance Numbers? Cause i also have some systems with Cascade Lake Refresh Xeons and i lost 5-10% when using avx512.

Edit. You pipe avs to x265 right? How CPU intesive is that script? How much of the load does the x265 process account for?

[Emulgator]

Is AVX512 really that much of a holy grail some people do claim - regarding performance?
Not that one should hold his breath or should spend more on such CPU, as LigH says.
Here on a i9-11900K notebook ("14nm", 70nm gate pitch, 125W, 5,3GHz single core turbo, 8 core steady 4,5GHz)
I remember to have seen like +10 to +20% x265 fps gain invoking x265 -avx512.
Sustained AVX512 CPU clock was above 4GHz, downclocking was avoided with 2 fans running full 4800rpm.
Nice to have, and I will stay there, but not worth a bigger fuss.
Will have to repeat a test encode and note down my comparison.

Now in 2022 a "5nm" (in reality 51nm gate pitch) CPU (AMD) will be the better investment, I guess.

[benwaggoner]

So, I finally picked up a 16" Apple MacBook Pro with a M1 Pro processor today.

What's the best way to get a well-optimized x265 binary to run on this hardware?