2019 great x265 4k settings?

[jlw_4049]

I like to rip my BluRays and encode them into smaller file sizes for my PLEX server.

I've been doing 1080p for years, while I'm pretty informed I have only just hit the tip of the ice burg.

I use handbrake to encode on my home server/plex machine.

I am looking for near lossless quality for 4k with a nice size reduction. I know that you lose quality encoding anything etc.

I have encoded some 4k clips with handbrake with the settings CRF 24, 21, 19, 18, and 17 @slow.

So far 19 feels like the best option in my opinion for the most part but I was wondering if you guys had any better options.

1 more question, is slow worth it over medium. Since medium is technically double the speed.

[jlw_4049]

Anyone?

[excellentswordfight]

Anyone?
I think the reason why no one has responded here is because this is something that comes up alot, and there are plenty of threads here for you to look at to gather the information you are asking for. Apart from that, these forums arnt really that great for these types of generic questions, cause, the answer you will get it is: it depends... Which is also the correct answer.

What exactly is your question? What CRF value you should choose or if medium or slow is the best are stuff only you can answer, we dont know your compression ratio target or speed requirements. Just try different CRF-values until you find a compression ratio that you are comfortable with. It also very source dependent, very high quality 4k sources or grainy sources might break your bitrate budget when using say 18-19, and you might need to go towards CRF 20-22 (which has been the case for me when compressing stuff from DI-sources).

I find slow to be worth the speed trade off, its imo the the preset that offers the best compression without going in too deep in the diminishing return territory. But you need to decide (and probably test) if it worth the trade off for you.

x265 is already tuned for 4k by deafault, so it doesnt need much tweeking outside the presets. The only setting that has good generic properties outside that is imo no-sao (that setting alone or with deblock -1,-1 and no-strong-intra-smoothing could be looked at something as x264 tune film), but again, if you are compressing animation, you might not wanna use these settings anyway. So... It depends.


This is what I use as "base" settings for 2160p24 "film" material, I might then do some tweaking, but as most things, source dependant
--preset slow --profile main10 --level-idc 51 --crf 20 --keyint 240 --min-keyint 24 --rc-lookahead 48 --no-sao

Together with the relevant color information:

e.g.

SDR:
--colorprim bt709 --transfer bt709 --colormatrix bt709 --range limited

HDR10:
--hdr-opt --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --range limited --max-cll "1000,400" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)"

[asarian]

I too, like the OP, am interested in this. Reading the above (and other stuffz), I came to the following (for an 8-bit encode):

--preset placebo --sar 1:1 --aud --nal-hrd none --profile main --level-idc 51 --crf 14 --aq-mode 3 --qg-size 64 --rc-lookahead 120 --subme 7 --colorprim bt709 --transfer bt709 --colormatrix bt709 --range limited

Does this look particularly unreasonable to anyone? If so, please share. :)

[excellentswordfight]

I too, like the OP, am interested in this. Reading the above (and other stuffz), I came to the following (for an 8-bit encode):

--preset placebo --sar 1:1 --aud --nal-hrd none --profile main --level-idc 51 --crf 14 --aq-mode 3 --qg-size 64 --rc-lookahead 120 --subme 7 --colorprim bt709 --transfer bt709 --colormatrix bt709 --range limited

Does this look particularly unreasonable to anyone? If so, please share. :)
I assume this is a joke, but good luck using those settings for uhd-bluray backups, it will only take a week or so per movie (assuming you have a beefy CPU) and you will end up with pretty much the same bitrate as you started with (or even higher)...

[asarian]

I assume this is a joke, but good luck using those settings for uhd-bluray backups, it will only take a week or so per movie (assuming you have a beefy CPU) and you will end up with pretty much the same bitrate as you started with (or even higher)...

I would have thought the mention of 8-bit encoding was a clear giveaway, but no, this is going to be for regular 1080p Blu-Ray material. Essentially, I'm just looking to replace my future x264 encodings with x265 ones, provided I can achieve the same high quality I'm used to (and provided the HEVC stream will be, you know, more Highly Efficiently encoded: aka shorter).

[excellentswordfight]

I would have thought the mention of 8-bit encoding was a clear giveaway, but no, this is going to be for regular 1080p Blu-Ray material. Essentially, I'm just looking to replace my future x264 encodings with x265 ones, provided I can achieve the same high quality I'm used to (and provided the HEVC stream will be, you know, more Highly Efficiently encoded: aka shorter).
Well you did post in a thread with 4K in the titel, and specified level 5.1 in your settings...

[benwaggoner]

I assume this is a joke, but good luck using those settings for uhd-bluray backups, it will only take a week or so per movie (assuming you have a beefy CPU) and you will end up with pretty much the same bitrate as you started with (or even higher)...
Yeah, you could easily be 20x faster at 5% higher bitrate.

And why 8-bit with Level 5.1? Anything I can think of that can do Level 5.1 can also decode Main10. That'll be a bigger quality and efficiency gain than the ultraplacebo setting you showed versus just --preset slower.

[asarian]

Yeah, you could easily be 20x faster at 5% higher bitrate.

And why 8-bit with Level 5.1? Anything I can think of that can do Level 5.1 can also decode Main10. That'll be a bigger quality and efficiency gain than the ultraplacebo setting you showed versus just --preset slower.

Hmm, currently doing a first run, at 0.2 fps. That's going to be too slow. :( Didn't realize it would be this slow.

As for the 5.1 level, I figured I would need it for a HEVC compliant stream. I will try out Main10 on the next run. But yeah, something's gotta give: I can't live with 0.2 fps.

[Boulder]

This is what I've set as my base settings. I feed 16-bit data from Vapoursynth with vspipe, hence the "--dither" call.


SDR 1080p: --dither --profile main10 --min-keyint 5 --keyint 480 --splitrd-skip --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --preset veryslow --rc-lookahead 60 --deblock -2:-2 --no-strong-intra-smoothing
--cbqpoffs -3 --crqpoffs -3 --subme 3 --merange 44 --no-sao --rect --amp --qcomp 0.7 --rd-refine --aq-mode 1 --aq-strength 1.0 --ipratio 1.38 --pbratio 1.28 --ctu 32 --max-tu-size 8 --qg-size 16
--tu-inter-depth 3 --tu-intra-depth 3 --limit-tu 3 --limit-refs 3 --max-merge 2 --ref 5 --bframes 8 --crf 19

SDR 720p: --dither --profile main10 --min-keyint 5 --keyint 480 --splitrd-skip --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --preset veryslow --rc-lookahead 60 --deblock -2:-2 --no-strong-intra-smoothing
--cbqpoffs -3 --crqpoffs -3 --subme 3 --merange 38 --no-sao --no-rect --qcomp 0.7 --rd-refine --aq-mode 1 --aq-strength 1.0 --ipratio 1.38 --pbratio 1.28 --ctu 16 --max-tu-size 8 --qg-size 16
--tu-inter-depth 2 --tu-intra-depth 2 --limit-tu 3 --limit-refs 3 --max-merge 2 --ref 5 --bframes 8 --crf 18

For HDR (1080p since I don't encode in 4K), I'd use the same 1080p settings but CRF needs to be much lower, probably 14 to begin with. Of course, those HDR-specific parameters need to be in as well.

My testing method is simply changing one parameter at a time and testing still frames by comparing them at sections where the encoded one is distorted from the original. I check the result in motion when I've done all the comparisons and reached the basic script.

One surprise was that in 1080p I needed to add --amp to avoid slight blocking on the edge of one character's lower lip, --rect was not enough. In 720p, it's not needed but it's probably due to the details being smaller and also CTU being smaller.

I mainly use CRF for testing as I don't have a clear bitrate limit. I use what is needed to make it look good enough for me, a 65" 4K TV with a viewing distance of about 3,5 metres. By testing things on my computer display at close range, I can be sure that the result will be almost if not entirely transparent on the TV.

[asarian]

^^ Thanks, Boulder! Very good stuff in here. :) I'll use your settings to see if I can speed up things a bit.

[asarian]

Ok, this is slightly weird. My first x265 test I did as follows, with these 'joke' settings:

VSPipe f:\jobs\%1.vpy - --y4m | x265 - --y4m --preset placebo --sar 1:1 --aud --profile main --vbv-bufsize 160000 --vbv-maxrate 160000 --level-idc 51 --frames %_frames% --crf %2 --aq-mode 3 --qg-size 64 --rc-lookahead 120 --subme 7 --colorprim bt709 --transfer bt709 --colormatrix bt709 --range limited --output "%3:\video\%1.265"

Then I did a regular x264 test, with the same 5 sec sample:

VSPipe f:\jobs\%1.vpy - --y4m | x264 - --demuxer y4m --opencl --frames %_frames% --crf %2 --sar 1:1 --aud --nal-hrd none --level 4.1 --preset placebo --vbv-bufsize 70000 --vbv-maxrate 60000 --aq-mode 2 --ref %_reframes% --tune film --output "%3:\video\%1.264"

These are the exact commandlines used in my cmd script, for good measure. CRF = 14 in both cases. Now where it gets weird, is where the HEVC result is actually 39k, vs. 38k for the x264 test (Sic!). The former took an order of magnitude longer to process, though.

Now, how can this be?! The whole idea of trying to transition to HEVC (for me), was so as to get smaller files, not larger ones. Average bitrate of both results is about the same: ca. 21.x MBps.

[Boulder]

The "save 50% of bitrate" is just a marketing trick. To be honest, it basically means that you can get watchable video with 50% less bits. When there's not enough bits to spend, x264 starts to create blocking and x265 blurs. Blurred video is easier to watch than a really blocky one.

[excellentswordfight]

Ok, this is slightly weird. My first x265 test I did as follows, with these 'joke' settings:

VSPipe f:\jobs\%1.vpy - --y4m | x265 - --y4m --preset placebo --sar 1:1 --aud --profile main --vbv-bufsize 160000 --vbv-maxrate 160000 --level-idc 51 --frames %_frames% --crf %2 --aq-mode 3 --qg-size 64 --rc-lookahead 120 --subme 7 --colorprim bt709 --transfer bt709 --colormatrix bt709 --range limited --output "%3:\video\%1.265"

Then I did a regular x264 test, with the same 5 sec sample:

VSPipe f:\jobs\%1.vpy - --y4m | x264 - --demuxer y4m --opencl --frames %_frames% --crf %2 --sar 1:1 --aud --nal-hrd none --level 4.1 --preset placebo --vbv-bufsize 70000 --vbv-maxrate 60000 --aq-mode 2 --ref %_reframes% --tune film --output "%3:\video\%1.264"

These are the exact commandlines used in my cmd script, for good measure. CRF = 14 in both cases. Now where it gets weird, is where the HEVC result is actually 39k, vs. 38k for the x264 test (Sic!). The former took an order of magnitude longer to process, though.

Now, how can this be?! The whole idea of trying to transition to HEVC (for me), was so as to get smaller files, not larger ones. Average bitrate of both results is about the same: ca. 21.x MBps.
Its not weird, and these are the results I was anticipating, hence why I thought you were kidding.

Imo the use case for x265 with very low preset with very low crf value are very limited, especially for consumer ripping bellow 4K (and at 4K as well as going with that low of an crf value will result in massive bitrates) Cause the more bits you spend, and the closer to visually lossless you get the less difference will there be between AVC and hevc, and with very small difference it will be very hard to justify the speed cost.

And you cannot really use the same crf value between different encoders and expect simulair behavior that effeciency conclusions can be drawn from, you cant even do that between different presets in x265! Use 2pass and use a bitrate were you are starting to get a degraded picture with x264 and see if you can improve it with x265. Then dail in a crf value that corresponds with the bitrate range were you are please with the quality.

I ripp in the more 18ish range for 1080p blurays, and there I get away with a bitrate arround 6mpbs, were x264 would need closer to 8mbps. This is with a 2.5x speed penalty mind you, and that gives me maybe a 20% bitrate reduction (calculations based on my very subjetive eyes ;) )

[asarian]

Its not weird, and these are the results I was anticipating, hence why I thought you were kidding.

Imo the use case for x265 with very low preset with very low crf value are very limited, especially for consumer ripping bellow 4K (and at 4K as well as going with that low of an crf value will result in massive bitrates) Cause the more bits you spend, and the closer to visually lossless you get the less difference will there be between AVC and hevc, and with very small difference it will be very hard to justify the speed cost.

And you cannot really use the same crf value between different encoders and expect simulair behavior that effeciency conclusions can be drawn from, you cant even do that between different presets in x265! Use 2pass and use a bitrate were you are starting to get a degraded picture with x264 and see if you can improve it with x265. Then dail in a crf value that corresponds with the bitrate range were you are please with the quality.

I ripp in the more 18ish range for 1080p blurays, and there I get away with a bitrate arround 6mpbs, were x264 would need closer to 8mbps. This is with a 2.5x speed penalty mind you, and that gives me maybe a 20% bitrate reduction (calculations based on my very subjetive eyes ;) )

Okay, thanks for the explanation, guys. I will need to do some substantially different tests.

As for 'lower bitrate at more-or-less the same quality' for x265, that's cute, but, in all honesty, for me only of interest if a (significantly) smaller output file would be the result. Setting CRF to 18 (instead of 14) would probably accomplish that already. So, the HEVC efficiency apparently is about similar output quality at lesser bitrates. I can live with that. :)

[benwaggoner]

Hmm, currently doing a first run, at 0.2 fps. That's going to be too slow. :( Didn't realize it would be this slow.

As for the 5.1 level, I figured I would need it for a HEVC compliant stream. I will try out Main10 on the next run. But yeah, something's gotta give: I can't live with 0.2 fps.

Level 5.0 is fine for 2160p24 for almost all content without a bunch of other restrictions. 5.1 allows for 40 instead of 25 Mbps.

[jlw_4049]

Thank you for the responses everyone!

[mparade]

This is what I use as "base" settings for 2160p24 "film" material, I might then do some tweaking, but as most things, source dependant


I am searching for a setting for my 4K HDR encodes that gives me a speed of around 6 fps. I have archival purposes and a first gen AMD Ryzen ThreadRipper processor with 16 cores. For BD and BD3D archiving purposes using x264 it is totally fast enough using multi-processes but for UHD I think it isn't and I would need to update my processor to the second gen with 32 cores at least. May I ask about the speed that can reached by using the settings in your post above? I would just like to compare it with the performance of my processor.

Thank you for your reply.

[asarian]

I have archival purposes and a first gen AMD Ryzen ThreadRipper processor with 16 cores. For BD and BD3D archiving purposes using x264 it is totally fast enough using multi-processes but for UHD I think it isn't and I would need to update my processor to the second gen with 32 cores at least.

On that matter -- if allowed here -- back in the day, for x264, it was said too many cores (= threads) would deteriorate the quality. Wasn't particularly relevant at the time, but nowadays (I'm thinking of getting an i9 9980XE myself, with 18 cores) the question may actually become pertinent again.

So, is this still an issue for x265? And, if so, at how many cores should we start to worry? :)

[Asmodian]

x265, with its 2x larger block sizes, actually hits that limit earlier. For 1080p I run two encodes at once on my i9 7900X.

[Boulder]

x265, with its 2x larger block sizes, actually hits that limit earlier. For 1080p I run two encodes at once on my i9 7900X.

Yes, there's a clear difference between CTU 64 and 32 what comes to parallel processing in the encoder. Of course, if you do extensive processing in Avisynth or better yet, Vapoursynth before feeding data into the encoder, the general utilization level should be higher by default.

[asarian]

^^ Thx, guys. Good to know.

[asarian]

x265, with its 2x larger block sizes, actually hits that limit earlier. For 1080p I run two encodes at once on my i9 7900X.

Why?! When I do heavy denoising stuffz, vspipe takes ca. 11-22% of the CPU. So, from that point of view, I can see why you would try and run multiple of those. The rest of the CPU is then usurped by the x264/x265 process.

So, what I don't understand then is how running two x265 processes concurrently lowers the amount of threads each uses. Or is that something you can actually set?

Thanks.

[mparade]

On that matter -- if allowed here -- back in the day, for x264, it was said too many cores (= threads) would deteriorate the quality. Wasn't particularly relevant at the time, but nowadays (I'm thinking of getting an i9 9980XE myself, with 18 cores) the question may actually become pertinent again.

So, is this still an issue for x265? And, if so, at how many cores should we start to worry? :)

I am not using x265 for 1080p content just because x264 is able to provide the quality I want in the size interval I am aiming at keeping menus as well and very fast using my processor even with preset slower, however, I have to divide the content into chunks for a better processor utilization to reach.
For HD and SD res. I maximalize threads and lookahead threads to 12&4 and 6&2 correspondingly.

[asarian]

I am not using x265 for 1080p content just because x264 is able to provide the quality I want in the size interval I am aiming at keeping menus as well and very fast using my processor even with preset slower, however, I have to divide the content into chunks for a better processor utilization to reach.
For HD and SD res. I maximalize threads and lookahead threads to 12&4 and 6&2 correspondingly.

Okay, thx. :) I'll look into that.

[Stereodude]

x265, with its 2x larger block sizes, actually hits that limit earlier. For 1080p I run two encodes at once on my i9 7900X.
Wait, you mean the devs of x265 didn't make its threading resolution aware as to not have it degrade image quality by spawning excess threads (by default)? I know x264 has that problem, but I thought I read that x265 was smarter about threading...

[Asmodian]

So, what I don't understand then is how running two x265 processes concurrently lowers the amount of threads each uses. Or is that something you can actually set?


It is something you can set with --pools and/or --frame-threads.

Wait, you mean the devs of x265 didn't make its threading resolution aware as to not have it degrade image quality by spawning excess threads (by default)? I know x264 has that problem, but I thought I read that x265 was smarter about threading...

It is smarter, in that WPP helps, but it still allocates a thread for each logical core. By default it will also start using more frame threads, which hurt quality, as core count goes up.

"The number of frame threads used is auto-detected from the (hyperthreaded) CPU core count"
Cores: Frames
> 32: 6..8
>=16: 5
>= 8: 3
>= 4: 2
Source (https://x265.readthedocs.io/en/default/threading.html)

[Stereodude]

It is something you can set with --pools and/or --frame-threads.



It is smarter, in that WPP helps, but it still allocates a thread for each logical core. By default it will also start using more frame threads, which hurt quality, as core count goes up.

"The number of frame threads used is auto-detected from the (hyperthreaded) CPU core count"
Cores: Frames
> 32: 6..8
>=16: 5
>= 8: 3
>= 4: 2
Source (https://x265.readthedocs.io/en/default/threading.html)
I've read that before. Maybe I'm misunderstanding it, but what I get out of that is that x265 will spawn a lot of threads on a high core count system, but they won't degrade image quality because they may largely sit idle waiting. They can impact determinism. Also, don't bother manually increasing the threading.

There certainly is no warning (or even a vague suggestion for that matter) to limit threading manually based on the input resolution for the sake of quality. In fact there's pretty much a statement to the opposite.
When frame threading is disabled, the entirety of all reference frames are always fully available (by definition) and thus the available pixel area is not restricted at all, and this can sometimes improve compression efficiency. Because of this, the output of encodes with frame parallelism disabled will not match the output of encodes with frame parallelism enabled; but when enabled the number of frame threads should have no effect on the output bitstream except when using ABR or VBV rate control or noise reduction.

[Asmodian]

When frame threading is disabled, the entirety of all reference frames are always fully available (by definition) and thus the available pixel area is not restricted at all, and this can sometimes improve compression efficiency. Because of this, the output of encodes with frame parallelism disabled will not match the output of encodes with frame parallelism enabled; but when enabled the number of frame threads should have no effect on the output bitstream except when using ABR or VBV rate control or noise reduction.

What I understand from this is that restricting the number of threads in a pool is pointless when running one encode but setting --frame-threads 1 can improve compression efficiency. I believe "no effect on the output bitstream" means all the frames are the same types and it can be decoded the same way, not that there is no loss of compression efficiency.

[Stereodude]

What I understand from this is that restricting the number of threads in a pool is pointless when running one encode but setting --frame-threads 1 can improve compression efficiency. I believe "no effect on the output bitstream" means all the frames are the same types and it can be decoded the same way, not that there is no loss of compression efficiency.
I took "no effect on the output bitstream" to mean no loss in visual quality because the encode is still deterministic (unless you use things that inherently break determinism).

[Asmodian]

The first sentence in your quote doesn't make any sense then. :confused:

It cannot both sometimes improve quality when disabled and not impact quality when enabled. I think the second sentence is contrasting frame level parallelism against slices as a way to allow parallelism, slices change the bitstream.

[Stereodude]

The first sentence in your quote doesn't make any sense then. :confused:

It cannot both sometimes improve quality when disabled and not impact quality when enabled. I think the second sentence is contrasting frame level parallelism against slices as a way to allow parallelism, slices change the bitstream.
Well, I didn't write it. It's ambiguous on both ends. :scared:

[asarian]

The first sentence in your quote doesn't make any sense then. :confused:

It cannot both sometimes improve quality when disabled and not impact quality when enabled.

Why not?! Leaving a feature disabled can sometimes improve quality; and sometimes having the feature enabled will not impact quality.

[Asmodian]

Why not?! Leaving a feature disabled can sometimes improve quality; and sometimes having the feature enabled will not impact quality.

For one, the second sentence does not say sometimes.

It also does not make sense technically. If you do not wait for all previous frames to be encoded sometimes you cannot chose what would have been the best reference block because it isn't available yet.

When frame threading is disabled, the entirety of all reference frames are always fully available (by definition) and thus the available pixel area is not restricted at all, and this can sometimes improve compression efficiency. Because of this, the output of encodes with frame parallelism disabled will not match the output of encodes with frame parallelism enabled; but when enabled the number of frame threads should have no effect on the output bitstream except when using ABR or VBV rate control or noise reduction.

Also, what would the bold mean if "no effect on the output bitstream" means "no effect on quality"?

Edit: Maybe it is saying that once --frame-threads = 2 more frame threads should have no effect? I find this hard to believe, because more incomplete frames seems like it has to mean fewer reference blocks available, but it might be what is meant and I don't know how the details of reference block selection interacts with frame parallelism. :)

[benwaggoner]

I read it as saying that frame-threads on/off can make a difference, but if frame threading is being used, the number of threads being used doesn't impact output quality.

This is not true with different number of frame-threads (with quality going down as the number goes up, although not nearly the impact it was in prior years). It might be true when frame-threads is constant but the number of threads in general varies.

[Asmodian]

But it explicitly says "the number of frame threads should have no effect on the output bitstream" which really doesn't seem like it could be true if it means size v.s. quality. :confused:

Oh wait, it means the number of threads working on each frame, not the number of frames being worked on at once? :)

[benwaggoner]

But it explicitly says "the number of frame threads should have no effect on the output bitstream" which really doesn't seem like it could be true if it means size v.s. quality. :confused:

Oh wait, it means the number of threads working on each frame, not the number of frames being worked on at once? :)
That is the only thing I thought it could mean that would make sense. The number of threads per frame go up with frame size. You can get quite a lot of cores going at once at UHD resolutions with high quality settings.

[jlw_4049]

Wow, last I checked no one had responded to this. I appreciate all the information here!! Thanks!

[blublub]

Wow, last I checked no one had responded to this. I appreciate all the information here!! Thanks!

lol.

Here is what I use:

1080P for high quality:
CRF: 17 to 19 - depending on the movie type / image noise
no-sao
frame-threads=3 to 4
ctu=32
merange=27
me=3
subme=4
rd=4
deblock=-1;-1
no-strong-intra-smoothing
bframes=4
ref=4
psy-rd=3.0
aq-mode=2 / aq=3 for dark movies
level-idc=51
high-tier
qcomp=0.63
vbv-maxrate=75000
vbv-bufsize=75000

4K HDR:
CRF 17 to 19 - same as above
--profile main10
--output-depth 10
--no-sao --frame-threads=3
--pme
--hdr-opt
--colorprim bt2020
--ctu=32
--qcomp=0.7
--no-strong-intra-smoothing
--aq-mode=2
--deblock=-1:-1
--level-idc=51
--high-tier
--qg-size=16

[Nico8583]

Hi,
I tried some settings and some encodes but I can see every time x265 lose a lot of details, even with a high bitrate (2 pass 35 MBits, CRF16...)
Do you have some tricks to encode ?
Thank you !

[excellentswordfight]

Hi,
I tried some settings and some encodes but I can see every time x265 lose a lot of details, even with a high bitrate (2 pass 35 MBits, CRF16...)
Do you have some tricks to encode ?
Thank you !
Preset slow, or lower, and --no-sao --no-strong-intra-smoothing --deblock -1:-1.

Sounds a bit odd that you lose a lot of detail at crf16 though (unless you are using a fast preset). Mind sharing settings and some samples?

[Nico8583]

Thank you.
I'm using slower or veryslow and no-sao, I'll try others settings. And I'll share my settings and samples.
I'm using Captain America Civil War chapter 17 to make my tests.

[~ VEGETA ~]

how much time does it take to finish your encode? I have an ATOM 2750 CPU dedicated server (yes I know it is not suited for encoding) and it is so slow. I wonder what affordable cpu I could use\buy to suit hevc 1080p encodes? any suggestions?

[Forteen88]

...
I wonder what affordable cpu I could use\buy to suit hevc 1080p encodes? any suggestions?You should wait until AMD releases their 7nm CPU:s this summer. Intel's CPU-prices (if you're an Intel-fanboi :)) will drop then too.

[excellentswordfight]

You should wait until AMD releases their 7nm CPU:s this summer. Intel's CPU-prices (if you're an Intel-fanboi :)) will drop then too.
Well with the latest Intel generation prices went up rather then down even with Ryzen2 released though... The prices could drop, but I woudlnt just assume that they do.

There is very little information that suggest that Ryzen3 will do much to increase general performance in a significant way. However there are two things that are very promising for the target group on this forum. AVX-performance and probably an 16C/32T mainstream modell.

[Nico8583]

So you think it's better to wait Ryzen 3 instead of buy a i9 9900K or i7 9700K ?

[excellentswordfight]

So you think it's better to wait Ryzen 3 instead of buy a i9 9900K or i7 9700K ?
In this case yes, with the improved AVX performance of Ryzen3 they should give a nice pump in price/performance over the current offering for encoding. But if money isnt a big issue, and you think that you are fine with 16threads, 9900k isnt a bad option. It will still be fast, and probably faster then ryzen3 thread for thread. But I'm pretty sure we will get an 12c/24t chip that is priced under 9900k.

[Nico8583]

Yes you're probably right, Ryzen 3 should be released soon so I can wait ;) thank you

[redbtn]

I don't wanna start new topic for small question, so I decided ask for help here.
I'm encoding 4k HDR > 1080p HDR with preset Slower, CRF 12-13 with output bitrate 16-17mbps. And my question is how much --merange and --ctu affects to quality?

For example:

--ctu 64 --merange 57 (2.5fps)
--ctu 32 --merange 26 (2.83fps) +13% speed

Avg QP is the same, output file size almost the same (428.2mb vs 428.5mb).

Is it worth spending 13% speed?

Ps: I have i5-9400f 6 core cpu, so just lowering --ctu don't give me boost on speed, all boost from lowering --merange.

My full settings:

--level-idc 51 --sar 1:1 --colorprim 9 --colormatrix 9 --transfer 16 --range limited --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" --max-cll "0,0" --hdr --hdr-opt --hrd --chromaloc 2 --repeat-headers --min-luma 0 --max-luma 1023 --no-cutree --no-sao --selective-sao 0 --no-open-gop --no-b-pyramid --no-strong-intra-smoothing --vbv-bufsize 160000 --vbv-maxrate 160000 --min-keyint 23 --keyint 240 --ipratio 1.30 --pbratio 1.20 --deblock -3:-3 --qcomp 0.65 --aq-mode 2 --aq-strength 0.8 --psy-rd 2 --psy-rdoq 2 --rd 4 --limit-refs 3 --bframes 8 --rc-lookahead 60 --subme 5 --me star --ctu 32 --merange 26 --max-merge 4

[benwaggoner]

I don't wanna start new topic for small question, so I decided ask for help here.
I'm encoding 4k HDR > 1080p HDR with preset Slower, CRF 12-13 with output bitrate 16-17mbps. And my question is how much --merange and --ctu affects to quality?

For example:

--ctu 64 --merange 57 (2.5fps)
--ctu 32 --merange 26 (2.83fps) +13% speed

I'd get nervous about having a small merange when working at 4K resolution, but that would be content dependent. Visual comparison is probably required here.

And most 4K content can wind up using 64x64 CTUs. It's probably a bigger deal at lower bitrates.