What are your baseline x265 encoding settings?

[Merlin93]

Hey folks,

I've been searching these forums and the web and have come to the conclusion that there isn't really a good collection of baseline encoding settings or proposed tunes for x265 that cover various types of media. Given x265 doesn't really provide much in the way of content specific tunes (aside from grain), this seems like something that would be useful to the enthusiast community, and would give people a good starting point for their own content-specific tweaks.

So I am proposing establishing a sticky thread (or using this one) as a place where people can share their settings and discuss what works (or doesn't work) and why. Assuming others are interested, of course.

Obviously, I have my own agenda since I'm in process of converting a large collection of DVD & BR media to digital format, and I'd like to use HEVC for at least some of it, so getting some good advice to tackle some of that would be handy.

As a starting point, I found the following as the most recent proposed tunes for animation and film in the HEVC discussion forum (crf 18 @ 1080p). However, they were posted more than a year ago, and may no longer be relevant based on the changes that have been made to x265 in that time...

animation:


--ctu 32 --ref 4 --bframes 6 --pbratio 1.2 --cbqpoffs -3
--crqpoffs -3 --no-sao --subme 3 --b-intra --no-amp --weightb
--aq-mode 3 --aq-strength 0.8 --rd 4 --psy-rd 1.8 --psy-rdoq 1.5
--rdoq-level 2 --rc-lookahead 80 --qcomp 0.65
--no-strong-intra-smoothing --limit-modes

film:

--ctu 32 --pbratio 1.2 --cbqpoffs -3 --crqpoffs -3
--no-sao --subme 3 --b-intra --no-amp --weightb --aq-mode 3
--aq-strength 0.9 --rd 4 --psy-rd 2.5 --psy-rdoq 4.0
--rdoq-level 2 --rc-lookahead 80 --qcomp 0.65
--no-strong-intra-smoothing --limit-modes

I'm curious what people are using now, and whether these settings still make sense?

Personally, I use the following for animation/anime (non-CGI 1080p BR transfers), but I suspect it can be improved...

--aq-mode 3 --aq-motion --aq-strength 0.9
--rc-lookahead 80 --deblock -3:-3 --tskip --tskip-fast
--tu-inter-depth 4 --tu-intra-depth 4 --limit-tu 4 --no-sao

Still looking for good settings for general films (low action, low-to-medium grain), action films (live-action martial arts, car chases, giant robots), and CGI (3d animation, Pixar, etc.) I'd also like to see what folks use for animation/anime.

What do you use for your own content, and why?

[jd17]

I got a lot of help/advice here, so these conclusions are not just my own:
https://docs.google.com/spreadsheets/d/1u9fKNsRcLgc-1oVV5GhBgoPGO9vLpcn-x3NUgTmeC-0/edit?usp=sharing

Maybe it helps. :)

Essentially, especially since x265 2.4, not too much alteration is needed in my experience to get transparent encodes from Blu-rays:

main10
CRF: 16-20
Tune: none
Preset: slow, slower or veryslow
Custom: --no-sao

That's basically it.
In my opinion, --no-sao is all the deviation from x265 2.4+ standards that is needed.


However, my experiences are just with regular film or 3D animation / CGI, no anime / 2D animation stuff.

If I encounter sources with extreme grain, I either use x264 or don't bother at all and just remux.
I also just remux, if a Blu-ray is already highly compressed, more than usual (=low bitrate).


I got help in these two threads:
https://forum.doom9.org/showthread.php?t=174679
https://forum.doom9.org/showthread.php?t=174491
Those were mainly about UHD, but I got some input for regular 1080p stuff as well.


YMMV. :)

[RanmaCanada]

I still use
pmode:rd=4:tu-intra-depth=3:rdoq-level=2:early-skip:b-intra:limit-modes:aq-mode=2:qg-size=16:ipratio=1.38:pbratio=1.28:me=3:max-merge=3:weightb:bframes=6:rc-lookahead=50:ref=6:psy-rdoq=1.38:no-sao for anime. Works wonders in handbrake.

[Merlin93]

I use the following setting:
--crf 14~16 --preset placebo --limit-refs 1 --limit-tu 1 --psy-rdoq 2~4 (--tskip-fast) --limit-modes --rd-refine (--ssim-rd) --splitrd-skip --qg-size 8 --aq-strength 0.8~0.9 --qcomp 0.65~0.75 (--cbqpoffs -3 --crqpoffs -3) --pbratio 1.2 --rc-lookahead 80 --pmode --limit-sao --no-strong-intra-smoothing
() are optional
Using StaxRip on Threadripper 1950X:)Is that for Animation or just in general?

[Merlin93]

Most of my content is anime/animation, so you could take it as a anime setting.
But my setting prioritizes quality over size/speed, so it may not be suitable for a "baseline setting".
And there does not exist universal setting parameters for every content, you can even tweak your parameters by episode if you want.
No parameters are perfect, but I think that it still has its reference value.Got it.

Yeah, I realize that settings will always need to be tweaked depending on the specific content and how well/poorly it was mastered. So when I say baseline, I mean the starting point before making any tweaks.

[excellentswordfight]

Got it.

Yeah, I realize that settings will always need to be tweaked depending on the specific content and how well/poorly it was mastered. So when I say baseline, I mean the starting point before making any tweaks.
The presets are already tweaked for general/baseline usage so when talking about non content specific scenarios you might as well just start there. I would say that --preset slow --no-sao is a pretty good baseline when quality is prioritized. SAO is in my experience only usefull for high CRF-values/low bitrates.


Personally the only other parameters I set are: --keyint fps*10 --min-keyint fps --rc-lookahead fps*2 and --bframes 8 for 50/60p material. + ofc VUI flags for color info etc.

[Merlin93]

The presets are already tweaked for genereal/baseline usage so when talking about non content specific scenarios you might as well just start there. I would say that --preset slow --no-sao is a pretty good baseline when quality is prioritized. SAO is in my experience only usefull for high CRF-values/low bitrates.I appreciate that, and as an extremely low-level baseline, yeah that does make sense. However, it cannot really be a great baseline tune for all types of media. But currently, x265 only supplies a tune for high grain content.

As mentioned in my first post, my personal interest is to find x265 equivalents to tunes for animation, CGI, low action film, and fast action film content. Though ultimately I think it would be helpful to use this thread as a good place to discuss tuning in general and what people like for various types of content. Of course, it would be more useful if we can explore why various settings work best for different types of content, but since activity on this thread is fairly slow, I'd be happy to see any submissions.

I've found that my experience with x264 tuning doesn't really apply directly for x265. Or at least, using similar settings doesn't get the same results that I would expect. So I'd really like to understand what others use (and why) to help inform my own choices as I move more of my library to x265.

Thanks for the feedback. :)

[Asmodian]

I have been testing sao with the new builds of x265. It does not seem to smooth the way it used to.

For 1080p anime I have had good results with:
--crf 18 -p 8 -F 1 --pools "5" --lookahead-slices 0 --rd-refine --tskip --tskip-fast --tu-inter 4 --tu-intra 4 --limit-tu 4 --rect --amp --limit-modes --no-strong-intra-smoothing

Adding --no-sao hurt quality and did not improve sharpness. This was not the case the last time I tested sao (probably about 6 months ago).

Does this match anyone else's experience?

[Arhu]

Adding --no-sao hurt quality and did not improve sharpness. This was not the case the last time I tested sao (probably about 6 months ago).
I only started testing with x265 2.5, don't know what it was before. I thought --no-sao made faces look dirty and prefer --sao.

As for the OP's question -- after lots of testing I came to the conclusion that I don't really like film grain. I don't like plastic faces either, however, so I'm trying to find a balance between the two for a more "natural" look. I also endlessly tried to decide which presets and settings I want to use, with no final result. After even more testing I decided to go for relatively simple presets.

1.
Apply slight digital noise reduction:

clip = core.fmtc.bitdepth(clip, bits=16)
clip = core.knlm.KNLMeansCL(clip, d = 4, s = 4, a = 4, h = 0.5)

Low values for h like 0.5 or 0.6 are usually good enough to mostly get rid of fine background noise in conjunction with x265's smoothing parameters (strong intra smoothing and sao). I also tried using BM3D and a refined combination of the two but it was just too slow.

2.
- Video parameters:
Bit depth: 10. Haven't experimented too much with 12.
Speed preset: Very slow (as others have already found out: at least Slow)
Custom parameters:

-- aq-mode 3. I think this is necessary to get rid of artifacts in dark scenes that can appear even with CRF 16. It might be too strong by default and I tried with aq-strength 0.9 too, like others, but couldn't make up my mind.
--sao (default). --no-sao made faces look dirty
--strong-intra-smoothing (default). I think it's a must for CRF >= 20, but even for lower CRF values I thought the picture looked more accurate with this enabled.

- Audio parameters (Opus):
-mapping_family 1 ... for 5.1+ encoding, to make sure the Opus library uses its multi-channel improvements from version 1.1. (At least in Staxrip 1.6 this needs to be set explicitly.)

3.
I use these quality presets as a guideline for video and audio. I also choose depending on how much I like a movie.
Note that these values are for noise reduced sources -- see step 1. Without the slight DNR I'd probably go 1 CRF higher for everything.

Video Audio
Q || CRF || Opus 2.0 | Opus 5.1 | Opus 6.1 | Opus 7.1 || Source Quality (http://www.avsforum.com/forum/150-blu-ray-software/2895785-blu-ray-uhd-picture-quality-rankings-pq-tiers-july-2017-a.html)
-------++-------++----------+----------+----------+-----------++----------------
Q0 || 16 || 160 kbps | 400 kbps | 480 kbps | 560 kbps || T0 Blu movies (reference)
Q0.5 || 16.5 || 152 kbps | 380 kbps | 456 kbps | 532 kbps || T0 Blu movies (reference)
Q1 || 17 || 144 kbps | 360 kbps | 432 kbps | 504 kbps || T1 Gold movies
Q1.25 || 17.5 || 136 kbps | 340 kbps | 408 kbps | 476 kbps ||
Q1.5 || 18 || 128 kbps | 320 kbps | 384 kbps | 448 kbps ||
Q1.75 || 18.5 || 120 kbps | 300 kbps | 360 kbps | 420 kbps ||
Q2 || 19 || 112 kbps | 280 kbps | 336 kbps | 392 kbps || T2 Silver movies | T1 Gold series
Q2.25 || 19.5 || 104 kbps | 260 kbps | 312 kbps | 364 kbps ||
Q2.5 || 20 || 96 kbps | 240 kbps | 288 kbps | 336 kbps ||
Q2.75 || 20.5 || 88 kbps | 220 kbps | 264 kbps | 308 kbps ||
Q3 || 21 || 80 kbps | 200 kbps | 240 kbps | 280 kbps || T3 Bronze movies | T2 Silver series
Q3.25 || 21.5 || 76 kbps | 190 kbps | 228 kbps | 266 kbps ||
Q3.5 || 22 || 72 kbps | 180 kbps | 216 kbps | 252 kbps ||
Q3.75 || 22.5 || 68 kbps | 170 kbps | 204 kbps | 238 kbps ||
Q4 || 23 || 64 kbps | 160 kbps | 192 kbps | 224 kbps || T4 Copper movies | T3 Bronze series
Q4.5 || 23.5 || 60 kbps | 150 kbps | 180 kbps | 210 kbps ||
Q5 || 24 || 56 kbps | 140 kbps | 168 kbps | 196 kbps || T5 Coal movies | T4 Copper series
The tier ratings for movies and series I take from Blu-ray UHD Picture Quality Rankings PQ Tiers July 2017 (http://www.avsforum.com/forum/150-blu-ray-software/2895785-blu-ray-uhd-picture-quality-rankings-pq-tiers-july-2017-a.html) at avsforum. For series I usually choose 2 CRF higher or go by the amount of episodes they have per season as a rough guideline -- and by how much I like them.

Without noise reduction I'd increase CRF by 1. With noise reduction I figure CRF needs to be one step lower to compensate for an increased chance of artifacts, but on the plus side the bitrate is used for detail that actually matters to me. Sound bitrates should be more or less proportional to the video bitrates between presets.

Regarding Atmos / DTS-X, I'm not sure if or when I'd keep it, especially if the tracks are lossless, which I think is overkill. I'd very much prefer their lossy variants, but there's no readily available encoder for that, is there?

In general I suppose the presets I'd use most often are Q2 (CRF=18 for movies) or Q3 (CRF=20 for TV shows).


I also like JD17's spreadsheet for presets, although I guess those are more for grain keeping.

[benwaggoner]

For 1080p anime I have had good results with:
--crf 18 -p 8 -F 1 --pools "5" --lookahead-slices 0 --rd-refine --tskip --tskip-fast --tu-inter 4 --tu-intra 4 --limit-tu 4 --rect --amp --limit-modes --no-strong-intra-smoothing
Why --pools "5"? Are you running on a NUMA system? I would think that explicitly setting --frame-threads would control quality and perf better. If you're running on a NUMA system, you can then set --pools "+,-" or whatever.

The number of frame threads is what impacts quality in multithreaded encoding, so better to set that directly and let x265 figure out how many cores and threads it can productively use for that encode.

using --pool 5 would map to --frame-threads 3.

Or is this about something else entirely?

[Toku]

For anime I'm using the below on CRF 19-20 depending on the source (Ripped from BD using makeMKV)


–profile main10 –output-depth 10 –tune grain –aq-mode 3 –preset veryslow –aq-strength 0.8 –ctu 32 –qcomp 0.8 –psy-rd 1 –tu-intra 4 –tu-inter 4 –limit-tu 1 –psy-rdoq 5.0 –rdoq-level 1 –deblock -2:-2 –qg-size 32 –merange 44 –me 3 –subme 5 –no-rect –no-amp


I have been testing sao with the new builds of x265. It does not seem to smooth the way it used to.

For 1080p anime I have had good results with:
--crf 18 -p 8 -F 1 --pools "5" --lookahead-slices 0 --rd-refine --tskip --tskip-fast --tu-inter 4 --tu-intra 4 --limit-tu 4 --rect --amp --limit-modes --no-strong-intra-smoothing

Adding --no-sao hurt quality and did not improve sharpness. This was not the case the last time I tested sao (probably about 6 months ago).

Does this match anyone else's experience?

I've experienced the exact same results, --no-sao now has a negative effect on animated content. (Haven't done much testing on real life content) I actually didn't like --no-strong-intra-smoothing on my tests either.

[Asmodian]

Why --pools "5"? Are you running on a NUMA system? I would think that explicitly setting --frame-threads would control quality and perf better.

I was limiting the number of threads while running four encodes at once. -F is a shortcut for --frame-threads so I was limiting each encode to one frame thread. :)

I only included the thread limits to be complete with my reporting because I hadn't tested too many variations of the command line.

I actually didn't like --no-strong-intra-smoothing on my tests either.

Interesting, I wonder if that is animation style dependent or if it is simply your slightly higher crf value. I definitely thought strong-intra-smoothing created something like that slightly smoothed look that I used to associate with sao.

[Gser]

This is what I use for 1080p live action content with medium preset, I haven't heard about limit sao before, have to run some trials with that
--crf 24.0 --ref=4 --ctu 32 --max-tu-size 16 --deblock=-2:-2 --no-strong-intra-smoothing --profile main10
--psy-rd=1.80 --psy-rdoq=5.00 --qcomp 0.7 --rdoq-level 1 --ipratio=1.30 --pbratio=1.20 --qg-size 16 --merange 44 --splitrd-skip --no-sao

[Asmodian]

If I understand correctly limit-sao is a speed up for sao, not really meant to reduce the impact of sao.

[x265_Project]

If I understand correctly limit-sao is a speed up for sao, not really meant to reduce the impact of sao.

You understand correctly.

[DotJun]

If I’m getting an error when I use —hdr-opt, is the most likely reason due to my source not being hdr?

[sneaker_ger]

Is your input 10 bit 4:2:0? Post the error message.

[DotJun]

Is your input 10 bit 4:2:0? Post the error message.


Sorry, on mobile right now so I can’t post logs. Yes it’s 4:2:0. It works fine if my source does in fact have hdr. When it doesn’t though, the encode will go all the way to the end and finish up with an error. This is using megui.

[Forteen88]

I'm unfortunately opening an old thread :p
@Arhu. Why don't you use AAC instead of Opus? Opus takes much more decoding time.
I did a test in foobar2000 v1.4 (with component "Decoding speed test"), testing the song "Ennio Morricone Conducts Morricone His Greatest Hits - The Good, the Bad and the Ugly: The Ecstasy of Gold".
"High priority: yes
Buffer entire file into memory: yes
Warm-up: yes"

Apple AAC@144kbps (using latest version with qaac_2.67, default setting),
"Decoding time: 0:00.174"

Opus@144kbps (using opus-tools-0.1.10-win64, default setting),
"Decoding time: 0:00.990"

[Asmodian]

Opus is higher quality than AAC, isn't that a reason to use it? Audio decode time is usually not a concern, it is really fast and can be done on another CPU/thread. HEVC takes a lot longer to decode than AVC too. :p

[Forteen88]

Opus is higher quality than AAC, isn't that a reason to use it? Audio decode time is usually not a concern, it is really fast and can be done on another CPU/thread. HEVC takes a lot longer to decode than AVC too. :pThere is only a slightest quality-difference between Opus & AAC (Opus being better quality). All good GPU:s nowadays (even since Nvidia GeForce 950/960) got FULL hardware-decoding for HEVC
https://forum.doom9.org/showthread.php?p=1846184#post1846184

Even a Opus@128kbps got longer a much decoding-time than AAC@144kbps,
Opus@128kbps: "Decoding time: 0:00.832".

[sneaker_ger]

And that equals to what? Only 300x instead of 1000x real-time?

[Phanton_13]

Apple AAC@144kbps (using latest version with qaac_2.67, default setting),
"Decoding time: 0:00.174"

Opus@144kbps (using opus-tools-0.1.10-win64, default setting),
"Decoding time: 0:00.990"
Try that on android and the times are going to vary greatly, in windows foobar2000 in the test make opus appear 5-6 times slower while in reality is only around 0.6 times slower in the worst case, also opus is faster than HE-AAC by a good margin.

[Forteen88]

And that equals to what? Only 300x instead of 1000x real-time?That test was for only 2 channels, but I was thinking more of how much decoding time difference is for like 6channels (with 24 bits bit depth), and combine that with a high resolution (1080p or even 4k) HEVC-video with no hardware-decoding support. That's a lot of pressure on the CPU.
Although, as 'Phanton_13' wrote, maybe foobar2000 got a much slower Opus-decoder than AAC-decoder.

I did another test, source-audio was from a DD5.1 movie,
AppleAAC@320kbps (foobar2k v1.4, 8 threads in Decoding speed test):
Decoding time: 0:37.325
874.862x realtime

Opus@300kbps (foobar2k v1.4, 8 threads in Decoding speed test):
Decoding time: 2:38.280
209.636x realtime

[sneaker_ger]

So 100% of CPU divided by 200 is 0.5% of the CPU would be used for the Opus playback. You wouldn't even be able to measure this reliably.

[FranceBB]

I'm more concerned about compatibility rather than the playback speed.
Besides, Opus was created to accomplish good communications with low bandwidth when two or more people were talking.
Later on, they developed other profiles that aimed to compress other types of contents and not just speech and they did a good job, however, Opus is not widely used and is not considered as standard as AAC and AC3 are.
The large majority of players will likely accept AAC or AC3 audio files, but will probably refuse an Opus audio file.
I'm not talking about computers, I'm talking about hardware decoders like bluray players, consoles and smart tv.
I also gotta say that AC3 might be a bit old (although still valid and widely used), but AAC has a really good psychoacoustic model and its MDCT filter bank that adaptively switches between 128 and 1024 bands (length 256 and 2048 FFT windows, using 50% overlap) demonstrated to be effective through these years, that's why AAC has become the first choice when people encode lossy audio contents.
I'm not saying that you shouldn't use Opus, but is it really worth saving few megabytes at the expense of compatibility with many devices when generally AAC 192kbit/s would be sufficient, AAC 320kbit/s would be good and AAC 384 kbit/s would be crystal and all you need?

[Asmodian]

Then why did you only mention speed and not compatibility? Some users do not care about bluray players, consoles, or smart TVs at all. Let them encode to new higher quality options if they want to to. ;)

We would be stuck on MPEG2 with MP3 if compatibility always won out. Also, HEVC is still a bad idea if compatibility is what you are going for. There are a lot of devices out that that support AVC+AAC that do not support HEVC and AVC at a bit higher bitrate would be sufficient. :p

Opus is catching on, I would not be surprised to see some smart TVs supporting soon. They are usually running Android and have decent enough CPUs they could do it even without hardware decoding.

[FranceBB]

Then why did you only mention speed and not compatibility?

'cause *I am* more concerned about compatibility, but I'm not the one who asked the question, @Arhu is, I just jumped in the topic and replied with my point of view xD

We would be stuck on MPEG2 if compatibility always won out.

Which is the reason why I encode files in MPEG-2 interlaced 25i TFF by doing speed-ups or blending at work on a daily basis. T_T (Omneon playout ports compatibility for 1080i contents :'( )

[benwaggoner]

Personally, I think xHE-AAC is going to be used a lot more than Opus ever will, particularly for commercial use. It outperforms Opus, offers seamless bitrate switching, and is broadly available in AAC licensing. Opus is an excellent codec, seamlessly bridging between low bitrate speech coding with efficient perceptually lossless encoding.

The OEMs have many years of familiarity with Fraunhofer and Via licensing, and I expect device classes that support AAC today to support xHE-AAC in the future.