This guide only delves into x265-settings SDR for now!
ANYONE can enter their own recommended x265-settings here! But type your handle before writing your preferred settings!
ToDo: We should copy most relevant info from GrandDK's x264 guide (but give credits too).
This guide should be updated to include HDR encode info, or maybe there should be another guide for that.
Software you will need
| Description | Tool / Software | Download Link |
|---|---|---|
| For SDR-video | Simple-x264-Launcher | https://github.com/lordmulder/Simple-x264-Launcher |
| For HDR-video | StaxRip | https://github.com/staxrip/staxrip |
| Codec | x265 (latest) | http://www.msystem.waw.pl/x265/ |
| Tool | AvsPmod | https://forum.doom9.org/showthread.php?t=175823 |
| Framework | AviSynth+ | http://avisynth.nl/index.php/AviSynth%2B |
All x265 binaries do the same, so it is only about encoding speed. My recommendations are: for AVX2-CPU the fastest should be VS 2017 AVX2 version, for AVX-CPU – VS 2017 AVX version, for SSE4-CPU – VS 2017 none or GCC none version, for SSSE3-CPU – GCC SSSE3 version, for CPU without even SSSE3 – GCC none version. You can determine fastest version by comparing encoding time on the same short sample.
HDR
Use StaxRip software to more easily encode HDR-videos.
StaxRip supports HDR10, HDR10+, HLG, and Ngx-TrueHDR. StaxRip supports Dolby Vision workflows,
Encoding Dolby-Vision with StaxRip workflow
x265 setting recommendations
General setting for high quality (ie high bitrate, like CRF 18) SDR HD-encodes:
AJ8's general recommendation:
x265 --crf 18 --preset slower --profile main10 --output-depth 10 --rc-lookahead 60 --ctu 32 --frame-threads 2 --no-sao --deblock -2:-2 --qcomp 0.65 --aq-mode 3 --ref 6 --bframes 8
"--ctu 32" is good to set (for encoding-speed) at resolutions lower or equal to 1920x1080, at higher resolutions you may remove this setting!
Grained movie setting for high quality (ie high bitrate, like CRF 18) SDR HD-encodes:
AJ8's grained recommendation (added to AJ8's general recommendation):
--bframes 3 --tune grain --no-sao --psy-rdoq 0 --no-strong-intra-smoothing --max-tu-size 16 --qg-size 16
Warning!
"Overriding the --tune grain settings might result in grain strobing, especially when enabling features like --aq-mode and --cutree that modify per-block QPs within a given frame."
https://x265.readthedocs.io/en/default/presets.html#tuning
jd17 at doom9 wrote:
"--psy-rdoq 10, which generates artificial grain with relatively clean sources. While --tune grain can surely help with noisy 16/35/65mm sources (or those with a grain filter), even with slower presets, it will hurt other, clean digital sources. High grain/noise sources have never been the strong suit for x265 so far. Even if the source were lossless or low compression / high bitrate, opting for x265 might be a mistake."
Sagittaire at Doom9 wrote:
"Use 10 bframes vs 3 bframes is perhaps useful for really flat anime. Certainly not for grainy movie (in this case never x265 use 10 consecutive bframe)."
foxyshadis at Doom9 wrote:
"The only way to get x265 to retain detail/grain in absolutely all circumstances is --tune grain combined with enough bitrate to not starve it. That will massively change but the bitrate and distribution of your entire movie, not a first choice if you're happy with the rest."
3D-animation settings for high quality (ie high bitrate, like CRF 18) SDR HD-encodes:
AJ8's 3D-animation recommendation (added to AJ8's general recommendation):
--ref 6 --bframes 16 --aq-strength 0.8 --psy-rd 1 --tu-intra-depth 4 --tu-inter-depth 4
Set higher --aq-strength for better debanding!
benwaggoner at Doom9 wrote this about "Ideal encoding settings for a 3D animated show"-topic:
"I'd start with --preset slower --tu-intra-depth 4 --tu-inter-depth 4."
Cartoon/anime setting for high quality (ie high bitrate, like CRF 18) SDR HD-encodes:
AJ8's cartoon/anime-animation recommendation (added to AJ8's general recommendation):
--ref 6 --bframes 16 --aq-strength 0.4 --psy-rd 0.4 --psy-rdoq 0 --tu-intra-depth 4 --tu-inter-depth 4 --limit-tu 4
Set as many --refs and --bframes as possible (within GPU-decoding-compatibility!), it's great for Cartoon/anime!
benwaggoner at Doom9 wrote:
"For anime, I've found positive results also using: --tskip --tskip-fast --tu-intra-depth 4 --tu-inter-depth 4 --limit-tu 4 ...But at a speed hit."
benwaggoner at Doom9 wrote this about dark scenes with default AQ-mode:
"Are you using --aq-mode 3? That can really help in low luma details. It might also be your display. Depending on how it's made, lots of displays get weird artifacts in near-black."
GrandDK's x264-guide wrote this about encoding Anime/Cartoon:
"Psy-rdo Can be used but remember to keep it lower than usual as it can create artifacts."
x265 options
--crf
Generally use --crf 18, but some video-sources might need a lower CRF, like 16.
Although don't set a lower CRF "just to be sure" that the encode will look fine, since what's the point of doing a reencode if low bitrate is not important (just do a remux if you don't care about low bitrate!)
--profile
For GPU H.265 decoding-compatibility, set to:
--profile main10
FoxyShadis at Doom9 wrote:
"Nvidia GeForce 960-graphicscards or better got FULL H265/HEVC HW-decoding!"
But even my old Nvidia GeForce 840M graphicscard got partial H.265 decoding-compatibility.
--preset
If you got a very fast CPU, set this to:
--preset slower
benwaggoner at Doom9 wrote:
"Personally, I feel --preset slower is where HEVC starts to really strut its stuff."
--ref
--ref 6
shouldn't be changed to a bigger value since --ref 6 is the highest value for GPU-decoding.
--ref 6 is the max inside spec. As many refs and bframes as possible is (within GPU-decoding-compatibility!) great for clean cartoon/anime & 3D-animation!
FoxyShadis at Doom9 wrote:
"Nvidia GeForce 960-graphicscards or better got FULL H265/HEVC HW-decoding!"
--bframes
Especially if you're encoding clean cartoon/anime & 3D-animation, set to:
--bframes 16
bframes 16 is GPU H.265 decoding-compatible!
--aq-mode
If your video-source got many dark scenes, then set to:
--aq-mode 3
benwaggoner at Doom9 wrote:
"--aq-mode 3 is really there for 8-bit SDR encodes. I wouldn't expect it to be valuable elsewhere. For distribution bitrates, I generally prefer --aq-mode 3 for SDR content and --aq-mode 2 for HDR content. Some prefer --aq-mode 1 when absolute bang for the bit is less essential."
benwaggoner at Doom9 wrote this about dark scenes with default AQ-mode:
"Are you using --aq-mode 3? That can really help in low luma details. It might also be your display. Depending on how it's made, lots of displays get weird artifacts in near-black."
benwaggoner at Doom9 wrote:
"--aq-mode 3 is exactly for reducing blocking in dark scenes. It will increase bitrate at a given CRF, but will also allow you to increase your CRF without increasing blocking in black, so the net bitrate required for a given quality should be lower."
--qcomp
Keep in mind that raising this value increases the risk of dark scenes looking even worse (you can solve this by setting --zones with higher bitrate at dark scenes).
foxyshadis at Doom9 wrote:
"I noticed you raised qcomp to 0.7 from the default 0.6, effectively telling x265, "I want fast-motion and difficult-to-compress scenes compressed harder than usual." Was there a specific reason for raising it?"
--merange
Some unknown at Doom9 wrote:
"Change merange to 24 for 480p, 32 for 720p and 48 for 1080p".
benwaggoner at Doom9 wrote:
"I am not sure than merange operates the same in x264 and x265. Also, as HEVC has intra-frame prediction, it can potentially make better use of merange than H.264 can."
--no-sao
benwaggoner at Doom9 wrote:
"Things like --no-sao can improve quality at high bitrates (although not nearly as much in more recent x265 builds) but can hurt quality at lower bitrates."
excellentswordfight at Doom9 wrote:
"I would say that --no-sao is a pretty good baseline when quality is prioritized. SAO is in my experience only useful for high CRF-values/low bitrates."
--deblock
Normally set this to:
--deblock -2:-2
If you encode CRF 17 or lower (with x265 at higher uality settings), it is safe (for a little more details) to set this to:
--deblock -3:-3
--deblock -3:-3 at higher CRF (around CRF 19) increases the risk of visible ringing, mosquito noise, and block edges.
benwaggoner at Doom9 wrote:
"Use higher deblock-value to improve compression efficiency."
benwaggoner at Doom9 wrote:
"Deblocking also improves quality by making prediction more efficient. Even if you can't see a sharp block boundary on a given screen, it being there makes that area a poor reference for a predicted block. Using deblocking can reduce residual substantially, and thus lower QPs overall."
Sagittaire at Doom9 wrote:
"Anyway -2;-2 is not bad value and will produce better high frequency conservation but more blocking/ringing too." & "-2;-2 don't produce the best psnr/ssim result. -2;-2 produce really strong deblocking effect too at high quantizer too."
--zones
Using zones for dark scenes in a video can be a good idea if
--aq-mode 3
gives not enough image-quality on dark scenes. Just lower the CRF-value at the scenes with dark scenes.
--frame-threads
benwaggoner at Doom9 wrote:
"Using <1 --frame-threads isn't as bad as it was in prior versions of x265, but -F 2 is about the max I'd use for high-quality encoding."
benwaggoner at Doom9 wrote:
"There can be quality upside to reducing threads. It's not as big as it used to be, but --frame-threads 1 and --lookahead-threads 1 could reduce CPU load some while upping quality some. In general, there is CPU and cache overhead in parallelization, so if you're doing higher resolutions on smaller numbers of cores, you can actually get a bit faster, a bit better, and a bit lower power draw at the same time. Not generally, but it is possible in some circumstances."
Mod16 & Mod4
benwaggoner at Doom9 wrote:
"HEVC is very efficient for non mod16 resolutions. I doubt that'll have a material impact (the extra 8 lines of 360 versus 352 are going to take way more bits than the non-mod16 overhead). If there is a sweet spot, it'd be optimal at Mod64!".
Just keep the resolution numbers even though (like 1920x1080 or 1280x720).
Screenshots
If you're not using AvsPmod for screenshots, for high-quality screenshots, use madVR in MPC-HC to make screenshots of x265-encoded video!
If you're using FFMS2 in AvsPmod to make screenshots, use this line to get frame number and frame type on the screenshot you make:
FFInfo(version=false, framenum=true, frametype=true, cfrtime=false, vfrtime=false, varprefix = "", colorspace=false, colorrange=false, cropping=false, SAR=false)
Credits
This guide is adapted from HDBits and shared here in good faith. Many thanks to them for creating such a helpful resource.