x265 HEVC Encoder

[benwaggoner]

What you can try is to pipe ffmpeg output into a file like so:

ffmpeg.exe -i %1 -pix_fmt yuv420p -f yuv4mpegpipe - > test.y4m

and then use test.y4m as an input file to a standalone x265.exe call to see what x265 does and debug that.
Yeah, I either output to .y4m or pipe into x265. It really simplifies debugging, and allows for specific x265 builds to be used.

Note that if you are doing 10-bit, you need to use:

ffmpeg.exe -i %1 -pix_fmt yuv420p10le -strict -1 -f yuv4mpegpipe - > test.y4m

And for piping:

ffmpeg.exe -i foo.mov -pix_fmt yuv420p10le -strict -1 -f yuv4mpegpipe - | x265.exe - --y4m

[asarian]

After painstakingly long denoising, I am finally ready to run the final x265-only process on The Fith Element (combined from 4x seperately denoised parts). I used the following command line:

VSPipe --y4m "f:\jobs\fifthfin.vpy" - | x265 --y4m --input - --preset medium --input-depth 10 --output-depth 10 --crf 10 --colorprim 9 --transfer 16 --colormatrix 9 --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)" --max-cll "10000,724" --frames 181104 --chromaloc 2 --output "g:\video\fifthfin.hevc"

x265 outputs:

[0.8%] 1483/181104 frames, 4.180 fps, 18984 kb/s, 145.92 MB, eta 11:56:15, est.size 17819 MB

Says around 19 Mb/s, and estimated file-size of ca. 18 G. Those values seem extremely low, especially considering the source was 45 G. I even set CRF to 10. But it still seems too low.

Am I doing anything wrong?

[Boulder]

Looks ok to me. The CRF value's behaviour in HDR and SDR differs quite a lot as the HDR input is very flat and the encoder does not do any internal grading when analysing the video. I usually lower the CRF value by 4 with HDR encodes to get to the similar quality level.

[asarian]

Looks ok to me. The CRF value's behaviour in HDR and SDR differs quite a lot as the HDR input is very flat and the encoder does not do any internal grading when analysing the video. I usually lower the CRF value by 4 with HDR encodes to get to the similar quality level.

Thx. So, should I even go to CRF = 6? Or should 10 suffice? Overall, I'm very impressed with the compression ratio of x265. :)

[rwill]

My new baby arrived today.
I look forward to take it for a spin with x265 (*_*)

Intel Xeon Gold, 56c/112th with AVX-512 and this time is in a server room with freezing cold temperatures, so I dare AVX512 to make it hot! xD

Too low base frequency, too many cores.

[_kermit]

Yeah, I either output to .y4m or pipe into x265. It really simplifies debugging, and allows for specific x265 builds to be used.

Note that if you are doing 10-bit, you need to use:

ffmpeg.exe -i %1 -pix_fmt yuv420p10le -strict -1 -f yuv4mpegpipe - > test.y4m

And for piping:

ffmpeg.exe -i foo.mov -pix_fmt yuv420p10le -strict -1 -f yuv4mpegpipe - | x265.exe - --y4m

thanks to both.

so, this would have been wrong?

ffmpeg.exe -i %1 -pix_fmt yuv420p -f yuv4mpegpipe -| x265.exe --input - --y4m ....

so I tried this:

ffmpeg.exe -i %1 -pix_fmt yuv420p10le -strict -1 -f yuv4mpegpipe - > %1.y4m
x265.exe --input %1.y4m --y4m ....

what I noticed:
- ffmpeg runs async in the background, continuously creating the file while x265 already starts processing.
- The file is huge, already 90GB out of a 20GB mkv

Is both expected and ok?

[Boulder]

Thx. So, should I even go to CRF = 6? Or should 10 suffice? Overall, I'm very impressed with the compression ratio of x265. :)

I kind of would expect CRF 10 to look very good. Of course, it depends on your requirements and viewing distance so testing the results with different CRF in your real life viewing conditions is always recommended.

In addition to your settings, I'd set --no-sao to disable the infamous Smooth All Objects functionality. I'd probably also use --deblock -1:-1.

[FranceBB]

Too low base frequency, too many cores.

Not really, I'm not an home user, I'm gonna be encoding professional UHD 12bit masterfiles coming from IMF Packages with MJPEG2000 RGB 12bit sources and I expect x265 to scale quite efficiently on all the cores. We'll see.

[rwill]

what I noticed:
- ffmpeg runs async in the background, continuously creating the file while x265 already starts processing.
- The file is huge, already 90GB out of a 20GB mkv

Is both expected and ok?

My intention was to check whether x265 would crash on the .y4m or complete. Because the input is the same as piped but pipe failed.

Regarding the size, you get ~6Mb per HD frame or ~24Mb per UHD frame. So at 24fps thats ~150 or ~600 Megabytes per second of video. So its not practical.

[Gravitator]

--ssim-rd - results in terribly poor image quality at low bitrate.
ffmpeg -i z:\space_6s.mkv -f yuv4mpegpipe - | x265 --y4m --input - --output-depth 10 --profile main10 --max-merge 1 --no-early-skip --rskip 0 --bframes 1 --ref 1 --bitrate 1000 --tune ssim --ssim-rd z:\ssim-rd.mkv
ffmpeg -i z:\space_6s.mkv -f yuv4mpegpipe - | x265 --y4m --input - --output-depth 10 --profile main10 --max-merge 1 --no-early-skip --rskip 0 --bframes 1 --ref 1 --bitrate 1000 --tune ssim z:\ssim-rd-off.mkv
Download an example > ssim-rd vs ssim-rd-off (https://files.videohelp.com/u/227452/ssim-rd%20vs%20ssim-rd-off.rar)

[Boulder]

--ssim-rd - results in terribly poor image quality at low bitrate.
ffmpeg -i z:\space_6s.mkv -f yuv4mpegpipe - | x265 --y4m --input - --output-depth 10 --profile main10 --max-merge 1 --no-early-skip --rskip 0 --bframes 1 --ref 1 --bitrate 1000 --tune ssim --ssim-rd z:\ssim-rd.mkv
ffmpeg -i z:\space_6s.mkv -f yuv4mpegpipe - | x265 --y4m --input - --output-depth 10 --profile main10 --max-merge 1 --no-early-skip --rskip 0 --bframes 1 --ref 1 --bitrate 1000 --tune ssim z:\ssim-rd-off.mkv
Download an example > ssim-rd vs ssim-rd-off (https://files.videohelp.com/u/227452/ssim-rd%20vs%20ssim-rd-off.rar)

can achieve significant gain in terms of objective quality metrics SSIM and PSNR
Which are not a measure for visual quality I'm afraid.

[Gravitator]

Which are not a measure for visual quality I'm afraid.
The problem is in the combination of settings.

[excellentswordfight]

Not really, I'm not an home user, I'm gonna be encoding professional UHD 12bit masterfiles coming from IMF Packages with MJPEG2000 RGB 12bit sources and I expect x265 to scale quite efficiently on all the cores. We'll see.
I get decent utilization up to about 24C/48T for UHD, we ofc have servers/clusters that exceeds that as we can push multiple encodes through them at the same time.

Could you please report back what frequency you are getting under high utilization with and without AVX512? We are moving to Epyc on all our encoding hardware, the frequency under load are just much higher compared to Intel in simulair price bracket were 32/64 CPU:s can push over 3Ghz under load.

[Boulder]

The problem is in the combination of settings.

Have you found out which particular one triggers it?

Not that I expect them to fix it even if you reported the issue at the bug tracker :p

[_kermit]

My intention was to check whether x265 would crash on the .y4m or complete. Because the input is the same as piped but pipe failed.

Regarding the size, you get ~6Mb per HD frame or ~24Mb per UHD frame. So at 24fps thats ~150 or ~600 Megabytes per second of video. So its not practical.

that's fine, I use pipeline again and with that command line the error is gone.

thanks!

[benwaggoner]

I kind of would expect CRF 10 to look very good. Of course, it depends on your requirements and viewing distance so testing the results with different CRF in your real life viewing conditions is always recommended.

In addition to your settings, I'd set --no-sao to disable the infamous Smooth All Objects functionality. I'd probably also use --deblock -1:-1.
I've seen quality improvements with some unusual sources down to CRF 12, certainly. But never anything below 10.

[benwaggoner]

Thank you, I've lowered it to 16 and will report back when its finished.

I can live with 'slight' bitrate increases (which is perfectly understandable).
Also, are you looking at still frames of moving video? x265 and other encoders are tuned to optimize quality in-motion. Lots of things that look not-great when paused will go unnoticed when playing at full speed.

Reducing --ipratio and --pbratio can help with this as well, also increasing bitrate. There's also the experimental --aq-motion which might be worth poking out if you have idle encoding time.

I'm not sure why reducing --qg-size would help. That specifies the block size in which QP be can be varied, and is more useful for improving quality of content of highly variable detail.

[asarian]

I kind of would expect CRF 10 to look very good. Of course, it depends on your requirements and viewing distance so testing the results with different CRF in your real life viewing conditions is always recommended.

In addition to your settings, I'd set --no-sao to disable the infamous Smooth All Objects functionality. I'd probably also use --deblock -1:-1.

Thx, I will add your parameters for the next encoding. :)

[asarian]

I've seen quality improvements with some unusual sources down to CRF 12, certainly. But never anything below 10.

I never went below 14 with x264 (and even then friends declared me insane). Since I read the quality of x265 can often be lower, esecially in dark spots, I went as low as 10. With 10 more hours to gp on the final run, file size is estimated at 44G now, which I still deem acceptable. Shouldn't become much larger, though.

[StormMeows]

Hey guys new here and really looking for some solid advice. I would greatly appreciate it.

I am in the process of backing up my Blu-Ray Collection that has a ton of movies in it. My CPU is pretty good, but for x265 especially, one movie would take a crazy amount of time. I have a lot of space on my NAS but not enough for full REMUXES of every movie so I want to encode the video ONLY. I want to passthrough the original Blu-Ray and 4K UHD Audio (DTS-MA/Dolby Atmos/True HD, etc). Can you guys please offer advice on the best program and settings to use? I know I want to use a really low CRF, and will keep the settings constant for every movie. In the event that the file ends up being just as big or bigger than the original, I can keep the original file instead of the encoded one. I prefer to keep the video as untouched as possible so no cropping or killing the grain, etc. I will watch the movies on something like Plex or KODI (direct play).

*Also, I should mentioned I tried Handbrake, but it seems limited on settings. For instance, you can only choose up to "Slow" as the slowest setting (no slower or placebo option). I would like a program easy to use that I can just run and not have to worry about checking screenshots for each movie, especially since I have so many movies.

Thank you guys so much!

[RanmaCanada]

Hey guys new here and really looking for some solid advice. I would greatly appreciate it.

I am in the process of backing up my Blu-Ray Collection that has a ton of movies in it. My CPU is pretty good, but for x265 especially, one movie would take a crazy amount of time. I have a lot of space on my NAS but not enough for full REMUXES of every movie so I want to encode the video ONLY. I want to passthrough the original Blu-Ray and 4K UHD Audio (DTS-MA/Dolby Atmos/True HD, etc). Can you guys please offer advice on the best program and settings to use? I know I want to use a really low CRF, and will keep the settings constant for every movie. In the event that the file ends up being just as big or bigger than the original, I can keep the original file instead of the encoded one. I prefer to keep the video as untouched as possible so no cropping or killing the grain, etc. I will watch the movies on something like Plex or KODI (direct play).

*Also, I should mentioned I tried Handbrake, but it seems limited on settings. For instance, you can only choose up to "Slow" as the slowest setting (no slower or placebo option). I would like a program easy to use that I can just run and not have to worry about checking screenshots for each movie, especially since I have so many movies.

Thank you guys so much!

There are plenty of threads about this in the main forum, and you will want to look in the encoder gui forum (placebo is useless anyways and the more options box is where you put your switches). I would suggest you make your own thread if you can't find what you are looking for.

[benwaggoner]

I never went below 14 with x264 (and even then friends declared me insane). Since I read the quality of x265 can often be lower, esecially in dark spots, I went as low as 10. With 10 more hours to gp on the final run, file size is estimated at 44G now, which I still deem acceptable. Shouldn't become much larger, though.
If you're having trouble with dark areas, --aq-mode 3 can also be worth trying. It lowers the QP in those dark areas, and thus allows --crf to be higher without getting blocking and banding in black. --aq-mode 3 does increase bitrate by itself, but using it with a higher --crf that suits the non-dark parts of the image can be smaller on net than having to use a ---crf low enough to make everything look good.

[LeXXuz]

If you're having trouble with dark areas, --aq-mode 3 can also be worth trying. It lowers the QP in those dark areas, and thus allows --crf to be higher without getting blocking and banding in black. --aq-mode 3 does increase bitrate by itself, but using it with a higher --crf that suits the non-dark parts of the image can be smaller on net than having to use a ---crf low enough to make everything look good.

Dark areas are always troubling. Aq3 never really convinced me, as it raises the overall bitrate of crf-encodes quite a lot - not only on dark scenes.

I never go below crf16. To tackle dark scenes I prefer to play with --psy-rd and --psy-rdoq and use 10-bit encodes, as all my playback devices can handle Main 10 profiles for HEVC.

And I think it's always good to have a little bit of noise left in the video as it helps many TVs/monitors to display solid backgrounds and dark areas much better. Backgrounds of totally 'clean' videos can look quite awful on many displays.

[microchip8]

If you're having trouble with dark areas, --aq-mode 3 can also be worth trying. It lowers the QP in those dark areas, and thus allows --crf to be higher without getting blocking and banding in black. --aq-mode 3 does increase bitrate by itself, but using it with a higher --crf that suits the non-dark parts of the image can be smaller on net than having to use a ---crf low enough to make everything look good.

This is bullshit. No matter how many times I tried aq-mode 3, it never got rid of banding in dark areas. In theory it may work but in practive it does not. psy-rd and psy-rdoq are FAR more effective in getting rid of banding and halo effects in darker scenes. Try it yourself if you don't believe it (I use psy-rd 4 and psy-rdoq 15)

[Boulder]

I think the problem with --aq-mode 3 is that it is based on --aq-mode 2 which itself is not optimal at all with higher bitrates. --aq-mode 1 + bias for dark areas would be a much better combination. Once again, the adaptive quantization stuff is mostly just ported from x264 and the x265 devs have really not done anything special about them.

[Boulder]

And I think it's always good to have a little bit of noise left in the video as it helps many TVs/monitors to display solid backgrounds and dark areas much better. Backgrounds of a totally 'clean' videos can look quite awful on many displays.

This is true. Almost or completely flat areas often have issues with the default settings since the encoder doesn't spend enough bits on them.

[asarian]

Dark areas are always troubling. Aq3 never really convinced me, as it raises the overall bitrate of crf-encodes quite a lot - not only on dark scenes.

I never go below crf16. To tackle dark scenes I prefer to play with --psy-rd and --psy-rdoq and use 10-bit encodes, as all my playback devices can handle Main 10 profiles for HEVC.

And I think it's always good to have a little bit of noise left in the video as it helps many TVs/monitors to display solid backgrounds and dark areas much better. Backgrounds of totally 'clean' videos can look quite awful on many displays.


Recently re-encoded (denoised) Alien UHD blu-ray. With a CRF of 10, I did not get any noticable banding in dark scenes, but overall the movie appeared too dark for my taste. Way too dark. I read about aq-mode 3, of course, but what does 'with bias to[wards] dark scenes' mean exactly? Does it mean dark scenes get better bitrate, at the expense of other scenes? Or just extra bitrate? And will those scenes get brighter? I have a Q90T Samsung TV, capable of outputting 2,000 nits, so it ain't my TV.

[Boulder]

Is your TV calibrated? I think Alien is quite dark on purpose, it's more or less for the suspense and stuff. Aq-mode won't affect the brightness at all, mode 3 just does less quantization in dark areas of a single frame. If you use CRF and VBV is not activated or does not restrict the bitrate, it means that more bits will be spent on average.

[Boulder]

psy-rd and psy-rdoq are FAR more effective in getting rid of banding and halo effects in darker scenes. Try it yourself if you don't believe it (I use psy-rd 4 and psy-rdoq 15)

Out of interest, do you use the same CRF level compared to stock settings or did you raise CRF to compensate?

[microchip8]

Out of interest, do you use the same CRF level compared to stock settings or did you raise CRF to compensate?

I've standardized on CRF 21. Cannot tell the difference with psy-rd/psy-rdoq between it and lower ones.

[LeXXuz]

Recently re-encoded (denoised) Alien UHD blu-ray. With a CRF of 10, I did not get any noticable banding in dark scenes, but overall the movie appeared too dark for my taste. Way too dark. I read about aq-mode 3, of course, but what does 'with bias to[wards] dark scenes' mean exactly? Does it mean dark scenes get better bitrate, at the expense of other scenes? Or just extra bitrate? And will those scenes get brighter? I have a Q90T Samsung TV, capable of outputting 2,000 nits, so it ain't my TV.

aq3 is supposed to add more bits to darker areas to prevent banding/blocking. Overall filesize increases, so I don't think these bits are spend at the expense of other scenes.

So much for the theory. In daily use I never experienced much improvement in troubling dark areas by aq3.

If your encode is noticeable darker than the original, it sounds more like a colourspace or HDR metadata problem to me.

[asarian]

aq3 is supposed to add more bits to darker areas to prevent banding/blocking. Overall filesize increases, so I don't think these bits are spend at the expense of other scenes.

So much for the theory. In daily use I never experienced much improvement in troubling dark areas by aq3.

If your encode is noticeable darker than the original, it sounds more like a colourspace or HDR metadata problem to me.


Thanks for the explanation on aq-mode 3, guys.

I had taken the base HDR command line options directly from what DGindexNV appended to the .dgi file. That has worked 100% well for other HDR material (The Fifth Element, Total Recall, etc), so I assume those parameters are correct.

Could simply be the (retail) HDR transfer of Alien is darker than the original HD version (made more for highlighted light for the HDR version?).


EDIT: Range is set to Limited. Felt counterintuitive, but the original is set to Limited too.

[Boulder]

Could simply be the (retail) HDR transfer of Alien is darker than the original HD version (made more for highlighted light for the HDR version?).

Definitely. Reading the blu-ray.com review of the UHD version tells me that because of the very dark surroundings, many enhancements are in the details in the shadows, which probably were mostly flat in the SDR release. It must be remembered that a dim image is quite tough on the viewing conditions. Your room should be very dark or many of the finer details will easily be lost. But then again, a bright part of the image can make your eyes water at the same time :eek:

[benwaggoner]

I think the problem with --aq-mode 3 is that it is based on --aq-mode 2 which itself is not optimal at all with higher bitrates. --aq-mode 1 + bias for dark areas would be a much better combination. Once again, the adaptive quantization stuff is mostly just ported from x264 and the x265 devs have really not done anything special about them.
For sure! This stuff needs to be refactored

hevc-aq should be aq-mode 5, not a whole different parameter that overrides the existing one
Selecting the aq algorithm and luma bias should be different parameters, with --aq-mode 3 just aliasing to a default combination of the two.
Luma bias itself should have parameters to better tune it. It's hard to see how a single default value will work well across content and scenarios.

[benwaggoner]

This is bullshit. No matter how many times I tried aq-mode 3, it never got rid of banding in dark areas. In theory it may work but in practive it does not. psy-rd and psy-rdoq are FAR more effective in getting rid of banding and halo effects in darker scenes. Try it yourself if you don't believe it (I use psy-rd 4 and psy-rdoq 15)
I've certainly seen it be helpful with some 8-bit SDR content, although a hybrid approach also using other parameters is superior. Banding issues aren't always caused by a somewhat too high QP, and aq-mode 3 won't help the kinds of banding that occur at other luma levels. Reducing low luma basis pattern blocking is where it helps the most, and only to the degree that having lowered the overall CRF a few steps would have helped.

[rwill]

For sure! This stuff needs to be refactored

hevc-aq should be aq-mode 5, not a whole different parameter that overrides the existing one
Selecting the aq algorithm and luma bias should be different parameters, with --aq-mode 3 just aliasing to a default combination of the two.
Luma bias itself should have parameters to better tune it. It's hard to see how a single default value will work well across content and scenarios.

Different Modes and parameters to tune them are a bad idea. Unless you want to found an Encode Manufactory with hand crafted streams and that special "magic" the goal for an encoder should be to have as few parameters and settings as possible and it should Just Work for everything.

[benwaggoner]

Different Modes and parameters to tune them are a bad idea. Unless you want to found an Encode Manufactory with hand crafted streams and that special "magic" the goal for an encoder should be to have as few parameters and settings as possible and it should Just Work for everything.
That is the dream! And there are certainly lots of interesting projects going on using improved metrics and machine learning to better adapt parameters to different kinds of content.

But fundamentally, those are all layers above low-level encoder decisions. The parameters need to exist, at least at the API level, for more advanced tuning to take advantage.

The existence of different EOTFs like 709, PQ, and HLG also change the psychovisual impact and importance of code value ranges. Optimizing for 709 and PQ are quite different in ways that a traditional encoder that just inputs arrays of pixel values is blind to.

[ghostshadow]

I just built znver3 optimized binary using gcc10.3, you can get it here (https://github.com/DJATOM/x265-aMod/releases/download/3.5%2B20/x265-x64-v3.5+20-aMod-gcc10.3.0-opt-znver3.7z).

Hello DJATOM, I've been using your x265 builds for some time. I recently took a Ryzen 5900x instead of my 3900x. So I used the zen3 version of x265. On a same in code with the 5900x in x265 zen2 and zen3, the zen2 version of x265 is faster. Did you notice that too? Thank you, and bravo for your contributions

[LeXXuz]

Hello DJATOM, I've been using your x265 builds for some time. I recently took a Ryzen 5900x instead of my 3900x. So I used the zen3 version of x265. On a same in code with the 5900x in x265 zen2 and zen3, the zen2 version of x265 is faster. Did you notice that too? Thank you, and bravo for your contributions

Hm... you're quite right. Thanks for bringing that up.

https://abload.de/img/2021-06-28w0k8l.pnghttps://abload.de/img/2021-06-281pykx7.png

1) x265-x64-v3.5+20-aMod-gcc10.3.0-opt-znver3
2) x265-x64-v3.5+20-aMod-gcc10.2.1-opt-znver2

Both done on Ryzen 5950x. That seems to be more than just an error of measurement. Odd. Problem with gcc10.3 maybe? :confused:

[quietvoid]

I had done a quick test using GCC 11.1 which brought Zen3 optimizations and it was a little over 1% slower on my 5900X.
Not sure GCC 10.3 has anything for Zen3 actually.

[charliebaby]

Hm... you're quite right. Thanks for bringing that up.

https://abload.de/img/2021-06-28w0k8l.pnghttps://abload.de/img/2021-06-281pykx7.png

1) x265-x64-v3.5+20-aMod-gcc10.3.0-opt-znver3
2) x265-x64-v3.5+20-aMod-gcc10.2.1-opt-znver2

Both done on Ryzen 5950x. That seems to be more than just an error of measurement. Odd. Problem with gcc10.3 maybe? :confused:

hello you have a ryzen 9 5950x and your Fps and 5 aie it's not normal, I have the same cpu as you but my encoding is between 13-17Fps all the heart active in second pass in placebo

GCC 11.1 http://msystem.waw.pl/x265/x265-3.5+10-82786fc_gcc111-AVX2.7z

[LeXXuz]

hello you have a ryzen 9 5950x and your Fps and 5 aie it's not normal, I have the same cpu as you but my encoding is between 13-17Fps all the heart active in second pass in placebo

Speed depends on what and how you encode. ;)
Those numbers are correct. I use a very complex filtering script that uses up to 60% of the cpu's workload.

[charliebaby]

oh it's a shame to use only 60% of the processor :scared: , I put 100% at home

https://nsa40.casimages.com/img/2021/06/29/mini_210629073603709537.png

[LigH]

I believe LeXXuz does not mean "60% CPU utilization at all (and 40% idle)", but 60% of the 100% is done in AviSynth (and the 40% rest in the encoder).

[LeXXuz]

I believe LeXXuz does not mean "60% CPU utilization at all (and 40% idle)", but 60% of the 100% is done in AviSynth (and the 40% rest in the encoder).

Exactly. :)

[DJATOM]

Zen3 support might be not polished enough, I don't have zen3 cpu to benchmark with.
That build provided since It's easy to add new definition into compile script, but if -march=znver2 is faster than znver3, pick whatever is faster for you :)
There's no handcrafted stuff for zen3, so nothing to fix by my side.

[LeXXuz]

I'll stick with your Zen2 optimization for the time being. Thanks for the info. :)

[LeXXuz]

I'm thinking about a memory upgrade for my systems.

Does anyone know if bandwidth or latency has an impact on x265 performance, if any at all, on AMD machines?

[Khun_Doug]

In general, Ryzen seems to do really well with fast memory. On my 5950X system the XMP implementation is broke. By manually adjusting memory speeds, I was able to gain x265 encode performance with the same CPU clock. Best advice on this is to check the motherboard memory list and choose from that list. You may have trouble using the XMP feature. You should consider tools like Cinebench to gauge performance improvements between existing memory and the replacements.

[DJATOM]

I have 16GBx4 modules (https://www.amazon.com/Ballistix-Single-PC4-24000-288-Pin-Memory/dp/B07MGPGXPS) with overclock to 3533 MHz and timings 16-18-16-36 / 1.395 V. It can work with 3700 MHz on those voltage / timings, but I got bad memory controller with my CPU.