Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 2nd January 2019, 16:29   #1  |  Link
jlw_4049
Registered User
 
Join Date: Sep 2018
Posts: 97
2019 great x265 4k settings?

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 is offline   Reply With Quote
Old 4th January 2019, 02:34   #2  |  Link
jlw_4049
Registered User
 
Join Date: Sep 2018
Posts: 97
Anyone?
jlw_4049 is offline   Reply With Quote
Old 4th January 2019, 10:15   #3  |  Link
excellentswordfight
Lost my old account :(
 
Join Date: Jul 2017
Posts: 98
Quote:
Originally Posted by jlw_4049 View Post
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
Code:
--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:
Code:
--colorprim bt709 --transfer bt709 --colormatrix bt709 --range limited
HDR10:
Code:
--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)"

Last edited by excellentswordfight; 4th January 2019 at 10:48.
excellentswordfight is online now   Reply With Quote
Old 4th January 2019, 15:42   #4  |  Link
asarian
Registered User
 
Join Date: May 2005
Posts: 1,372
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):

Code:
--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.
__________________
Gorgeous, delicious, deculture!
asarian is offline   Reply With Quote
Old 4th January 2019, 16:02   #5  |  Link
excellentswordfight
Lost my old account :(
 
Join Date: Jul 2017
Posts: 98
Quote:
Originally Posted by asarian View Post
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):

Code:
--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)...

Last edited by excellentswordfight; 4th January 2019 at 16:05.
excellentswordfight is online now   Reply With Quote
Old 4th January 2019, 17:25   #6  |  Link
asarian
Registered User
 
Join Date: May 2005
Posts: 1,372
Quote:
Originally Posted by excellentswordfight View Post
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).
__________________
Gorgeous, delicious, deculture!
asarian is offline   Reply With Quote
Old 4th January 2019, 18:59   #7  |  Link
excellentswordfight
Lost my old account :(
 
Join Date: Jul 2017
Posts: 98
Quote:
Originally Posted by asarian View Post
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...
excellentswordfight is online now   Reply With Quote
Old 4th January 2019, 19:04   #8  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,928
Quote:
Originally Posted by excellentswordfight View Post
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 4th January 2019, 19:18   #9  |  Link
asarian
Registered User
 
Join Date: May 2005
Posts: 1,372
Quote:
Originally Posted by benwaggoner View Post
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.
__________________
Gorgeous, delicious, deculture!
asarian is offline   Reply With Quote
Old 4th January 2019, 20:35   #10  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,566
This is what I've set as my base settings. I feed 16-bit data from Vapoursynth with vspipe, hence the "--dither" call.

Code:
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.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 4th January 2019, 21:13   #11  |  Link
asarian
Registered User
 
Join Date: May 2005
Posts: 1,372
^^ Thanks, Boulder! Very good stuff in here. I'll use your settings to see if I can speed up things a bit.
__________________
Gorgeous, delicious, deculture!
asarian is offline   Reply With Quote
Old 5th January 2019, 02:42   #12  |  Link
asarian
Registered User
 
Join Date: May 2005
Posts: 1,372
Ok, this is slightly weird. My first x265 test I did as follows, with these 'joke' settings:

Code:
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:

Code:
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.
__________________
Gorgeous, delicious, deculture!
asarian is offline   Reply With Quote
Old 5th January 2019, 08:33   #13  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,566
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.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 5th January 2019, 09:33   #14  |  Link
excellentswordfight
Lost my old account :(
 
Join Date: Jul 2017
Posts: 98
Quote:
Originally Posted by asarian View Post
Ok, this is slightly weird. My first x265 test I did as follows, with these 'joke' settings:

Code:
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:

Code:
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 )

Last edited by excellentswordfight; 5th January 2019 at 10:19.
excellentswordfight is online now   Reply With Quote
Old 5th January 2019, 14:30   #15  |  Link
asarian
Registered User
 
Join Date: May 2005
Posts: 1,372
Quote:
Originally Posted by excellentswordfight View Post
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.
__________________
Gorgeous, delicious, deculture!
asarian is offline   Reply With Quote
Old 5th January 2019, 19:54   #16  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,928
Quote:
Originally Posted by asarian View Post
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 17th January 2019, 14:48   #17  |  Link
jlw_4049
Registered User
 
Join Date: Sep 2018
Posts: 97
Thank you for the responses everyone!
jlw_4049 is offline   Reply With Quote
Old 20th January 2019, 13:27   #18  |  Link
mparade
Registered User
 
Join Date: Nov 2013
Posts: 522
Quote:
Originally Posted by excellentswordfight View Post
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.

Last edited by mparade; 20th January 2019 at 13:31.
mparade is offline   Reply With Quote
Old 20th January 2019, 14:18   #19  |  Link
asarian
Registered User
 
Join Date: May 2005
Posts: 1,372
Quote:
Originally Posted by mparade View Post
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?
__________________
Gorgeous, delicious, deculture!
asarian is offline   Reply With Quote
Old 20th January 2019, 14:37   #20  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 3,631
x265, with its 2x larger block sizes, actually hits that limit earlier. For 1080p I run two encodes at once on my i9 7900X.
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Reply

Tags
handbrake, hevc, x265

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 16:25.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.