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]

Originally Posted by jlw_4049

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]

Originally Posted by 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.

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]

Originally Posted by excellentswordfight

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]

Originally Posted by asarian

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]

Originally Posted by excellentswordfight

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]

Originally Posted by benwaggoner

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]

Originally Posted by 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.

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]

Originally Posted by excellentswordfight

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]

Originally Posted by asarian

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]

Originally Posted by excellentswordfight

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]

Originally Posted by mparade

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.