x265 Sharpness and Detail (Best Settings?)

[HD MOVIE SOURCE]

Hi,

I'm looking to find settings that increase detail and sharpness. In turn, I'm also looking for settings that apply blurring or softness and can be turned off.

Here are the settings that I know of so far that do this.

subme=7 (A sharpener, detail increase)
no-deblock / deblock (Blurring/detail loss the more deblock is used)
no-sao / sao (High Blur)
no-strong-intra-smoothing / strong-intra-smoothing (Smoother/Blur)
psy-rd=-- & psy-rdoq=-- rdoq-level=-- (Detail increase as the cost of accuracy - Can look over-digital)



These are all the detail increase settings that I know of so far. Are there any more? I saw some things on QBlur, I don't know what it does, because I haven't researched it. Just because blur is in the title made me think, but is this anything that controls sharpness and detail?

Are there any more? My goal is to get the most detailed image possible use x265 (which is notorious for having a soft image). However, if anything goes over the top, like, giving an edge-enhanced look or heavy ringing, I will back off. The goal is maximum blur removal and ultra-high detail without looking overly digital, this is why I'm trying to back off from using psy-rd and rdoq, I just don't like the look personally.

Thank you.

[benwaggoner]

Hi,

I'm looking to find settings that increase detail and sharpness. In turn, I'm also looking for settings that apply blurring or softness and can be turned off.

Here are the settings that I know of so far that do this.

subme=7 (A sharpener, detail increase)
no-deblock / deblock (Blurring/detail loss the more deblock is used)
no-sao / sao (High Blur)
no-strong-intra-smoothing / strong-intra-smoothing (Smoother/Blur)
psy-rd=-- & psy-rdoq=-- rdoq-level=-- (Detail increase as the cost of accuracy - Can look over-digital)

I am unaware of any evidence that --strong-intra-smoothing reduces visible detail in any scenario.
Nor does --deblock if used appropriately. Both will reduce detail at moderate-low bitrates, as they reduce compression efficiency and drive QPs higher, which itself is a low-pass filter. The HEVC built-in deblocking filter is better turned than H.264's.

--subme only goes up to 5 in --preset placebo. I've not seen visible quality improvements from using higher values.

If you have sharp synthetic details (text, line art, noise-free anime), --tskip can increase detail.

In theory --hme can help with very noisy content.
--amp and --rect can improve detail by allowing TUs to better match the shape of content, for example encoding a mild horizontal curve as 32x8 instead of forcing it to be square.

But in general, a lot of these things are controlled by the preset. It's best to pick the slowest preset that is fast enough, and start tweaking from there.

[QUOTE]These are all the detail increase settings that I know of so far. Are there any more? I saw some things on QBlur, I don't know what it does, because I haven't researched it. Just because blur is in the title made me think, but is this anything that controls sharpness and detail?
That "blurrs" differences in QP to reduce quality fluctuations. It has no direct impact on sharpness.

Are there any more? My goal is to get the most detailed image possible use x265 (which is notorious for having a soft image). However, if anything goes over the top, like, giving an edge-enhanced look or heavy ringing, I will back off. The goal is maximum blur removal and ultra-high detail without looking overly digital, this is why I'm trying to back off from using psy-rd and rdoq, I just don't like the look personally.
I'd start doing a test encode at --preset slower --crf 18 --no-sao and see if the detail retention and file size are okay for you. If not, tweak from there. Jumping in with parameters without having some reference encodes to compare with the source and each other makes for a lot more work.

[BuccoBruce]

I'm going to second and expand upon benwaggoner's great advice.


Don't turn deblock off completely
Don't turn SAO off completely

You will see more artifacts, or end up wasting bits trying to prevent them. It isn't 2015 anymore, they don't destroy detail or sharpness in most scenarios.

For deblock, you should turn the strength down and turn the threshold up instead of disabling it outright. Start with --deblock -1:1 and work your way down/up from there to taste. I personally wouldn't go higher than 1 on the threshold, and I don't think I've seen any encodes "in the wild" with threshold >1 either. Some people use e.g. -2:0.

For SAO, I'm not sure what the "best" option is, but I use --limit-sao --selective-sao 1 --sao-non-deblock to "reel it in" as opposed to turning it off completely, and it has been working well for me. Now that I look at the documentation, --selective-sao 3 might be a better choice. I'm not sure why you'd ever want SAO on non-reference slices though, so definitely use at least one of those two choices, or "2" if you don't want it on any reference B slices.

--amp --rect and --tskip-fast are all indispensable for animated content, if you can stomach all the extra time they consume. I haven't tried them with live action content.

--hme is pretty useful for getting away with using a lower subme and knocking slower presets down to --me umh at higher resolutions, although I personally haven't seen any benefit from using it at 1080p and below.

[benwaggoner]

--selective-sao 2 is the one you want, and should be the x265 default. SAO is designed around forward-prediction only, so 99% of the value is seen on just I and P frames. Applying it to B and b frames just slows the encode down a bit. In theory I could imagine --selective-sao 3 maybe helping a tiny bit in some odd scenarios, but don't have any evidence or examples of that.

What impact have you found from --sao-non-deblock? I don't think I've ever tried it (which is pretty rare!). I'd presumed it was a quality-versus-performance tradeoff parameter.

And yeah, cel animation and motion graphics require much different tuning that natural image content. Motion blur and noise make a huge difference compared to not having those.

[HD MOVIE SOURCE]

Thank you for the feedback guys, much appreciated. And yes, I have been encoding from the basic preset first and then adjusting from there.

I personally can't stand using sao, its way too aggressively soft, I just don't think it's needed, at least on high bit-rate content like 4k UHD Blu-ray. Streaming maybe another matter or low bit-rates, but I will not use sao, that's the opposite direction I want to go.


"-tskip can increase detail" --- Is this okay to use in grainy content too?


"In theory --hme can help with very noisy content" --- This doesn't remove noise or grain though does it? as long as it doesn't remove anything, Ill try it.


--amp and --rect I will look into, I know they add quite a bit of encoding time so I will have to think about these.


Right now I'm encoding SolLevante from Netflix which is grain free but has ultra-fine details. When she dives down into the ocean, I want to retain as much of the ultra-fine detail that the source has. I also thinking about grain content also. i want to preserve as much grain as possible also, without blurring or blending anything.

Ill run a few encodes with these new settings. Thank you.

[HD MOVIE SOURCE]

--subme only goes up to 5 in --preset placebo. I've not seen visible quality improvements from using higher values.

If you have sharp synthetic details (text, line art, noise-free anime), --tskip can increase detail.

In theory --hme can help with very noisy content.
--amp and --rect can improve detail by allowing TUs to better match the shape of content, for example encoding a mild horizontal curve as 32x8 instead of forcing it to be square.

But in general, a lot of these things are controlled by the preset. It's best to pick the slowest preset that is fast enough, and start tweaking from there.


That "blurrs" differences in QP to reduce quality fluctuations. It has no direct impact on sharpness.


I'd start doing a test encode at --preset slower --crf 18 --no-sao and see if the detail retention and file size are okay for you. If not, tweak from there. Jumping in with parameters without having some reference encodes to compare with the source and each other makes for a lot more work.


Okay, I added tskip, hme amp, and rect to my encoding settings. The sharpness is off the chain right now. It's pin sharp. The facial detail on SolLevante looks as thought it was drawn with a pencil it looks that sharp.

The biggest issue is the encoding time. It took about 16 hours just to encode SolLevante and that was about 4 minutes of content. I was encoding this in 2 and a half hours before these settings. I'm just using an old PC to encode with overnight. If I want to encode using these settings I will definitely have to get an optimized encoding PC.

The settings I used that have an effect in detail.

subme=7
no-deblock
no-sao
no-strong-intra-smoothing
psy-rd=0.00, psy-rdoq=0.00, rdoq-level=0
(I dislike everything the RD and RDOQ does to the image, I think it makes the image look too digital, so I set those to 0 and get my detail with other settings that don't look digital)
tskip
hme
amp
rect


The sharpness is extremely impressive, I didn't think x265 was capable of this level of detail. Thank you, now you'll have to send me an encoding PC LOL.

[benwaggoner]

Okay, I added tskip, hme amp, and rect to my encoding settings. The sharpness is off the chain right now. It's pin sharp. The facial detail on SolLevante looks as thought it was drawn with a pencil it looks that sharp.

The biggest issue is the encoding time. It took about 16 hours just to encode SolLevante and that was about 4 minutes of content. I was encoding this in 2 and a half hours before these settings. I'm just using an old PC to encode with overnight. If I want to encode using these settings I will definitely have to get an optimized encoding PC.

The settings I used that have an effect in detail.

subme=7
no-deblock
no-sao
no-strong-intra-smoothing
psy-rd=0.00, psy-rdoq=0.00, rdoq-level=0
(I dislike everything the RD and RDOQ does to the image, I think it makes the image look too digital, so I set those to 0 and get my detail with other settings that don't look digital)
tskip
hme
amp
rect


The sharpness is extremely impressive, I didn't think x265 was capable of this level of detail. Thank you, now you'll have to send me an encoding PC LOL.
I'd start with just --preset slower --selective-sao 2 and adjust from there. --preset slower enables fast modes of the slower tools where available, and generally is targeting your kind of scenario overall.

If that doesn't give you the detail you want, first try --no-sao.

If you find --tskip helpful, try --tskip --tskip-fast.

[microchip8]

Okay, I added tskip, hme amp, and rect to my encoding settings. The sharpness is off the chain right now. It's pin sharp. The facial detail on SolLevante looks as thought it was drawn with a pencil it looks that sharp.

The biggest issue is the encoding time. It took about 16 hours just to encode SolLevante and that was about 4 minutes of content. I was encoding this in 2 and a half hours before these settings. I'm just using an old PC to encode with overnight. If I want to encode using these settings I will definitely have to get an optimized encoding PC.

The settings I used that have an effect in detail.

subme=7
no-deblock
no-sao
no-strong-intra-smoothing
psy-rd=0.00, psy-rdoq=0.00, rdoq-level=0
(I dislike everything the RD and RDOQ does to the image, I think it makes the image look too digital, so I set those to 0 and get my detail with other settings that don't look digital)
tskip
hme
amp
rect


The sharpness is extremely impressive, I didn't think x265 was capable of this level of detail. Thank you, now you'll have to send me an encoding PC LOL.

I've no idea how you came to the conclusion that Psy setting make the image too "digital". Both psy-rd and psy-rdoq, at *high* values, virtually completely elliminate banding artifacts. So, either disable psy-rd/psy-rdoq and enjoy your banding or turn them on at high values and enjoy a clean, crisp image.

I've been encoding for ages with high psy-rd/psy-rdoq and have yet to see it destroy detail or sharpness. At worse, it makes the image more "static".

[rwill]

I've no idea how you came to the conclusion that Psy setting make the image too "digital". Both psy-rd and psy-rdoq, at *high* values, virtually completely elliminate banding artifacts. So, either disable psy-rd/psy-rdoq and enjoy your banding or turn them on at high values and enjoy a clean, crisp image.

I've been encoding for ages with high psy-rd/psy-rdoq and have yet to see it destroy detail or sharpness. At worse, it makes the image more "static".

Well he has not mentioned the bitrate, crf or qp he encodes at. For all we know he could be pushing 500Mbit/s and marvel at the transparent quality.

[HD MOVIE SOURCE]

I'd start with just --preset slower --selective-sao 2 and adjust from there. --preset slower enables fast modes of the slower tools where available, and generally is targeting your kind of scenario overall.

If that doesn't give you the detail you want, first try --no-sao.

If you find --tskip helpful, try --tskip --tskip-fast.

Thank you Ben.

One thing I've noticed is that no-hme is used in all 10 presets by default. Is this because the encoding time added is huge by using hme? I have tried it on SolLevante, but it's a very short piece of material so I could get away with it. But, unless you have a supercomputer I don't think hme is even viable to setups like mine.

I will run some speed tests on the other settings and see what I can get away with. As long as it can add detail and not take away with minimal impact on encoding time, I'm fine with that.

I cannot encode a full movie using beyond medium. Medium and a movie of about 90 minutes is around 2 days. But, I am well aware my current encoding PC is woefully inadequate. However, for now I'm fine with it. I don't mind an encode taking 4 or 5 days, that's fine, but anything over a week is not something I can achieve right now. So I will test each setting to see the speed impact.

Thanks.

Well he has not mentioned the bitrate, crf or qp he encodes at. For all we know he could be pushing 500Mbit/s and marvel at the transparent quality.

I'm encoding at uhd-bd=1 maxrate which is around 98 Mbps. That's my target bit-rate. I use Constant Rate Factor = 0. But that doesn't mean that you don't have bit-rate control. Bit-rates can still bit controlled by using vbv-maxrate=98000:vbv-bufsize=99000. When using maxrate with CFR it essentially becomes the target bit-rate, and buffsize basically turns into maxrate when compared to a 2-pass encode. I read this in the x265 docs, and since doing it my encodes look incredible.

What this does is makes it so anything under my target bit-rates is essentially transparent, and anything getting up to 98 Mbps is so high in bit-rate that it basically transparent also.

SolLevante was encoded using these settings and my final average bit-rate is 68.7 Mb/s. The average QP is 8.21.

If you want to see my encode for SolLevate here it is: https://drive.google.com/file/d/1v8-A-R_giU8Fx_4zflGgX56W0kKVV2St/view

Somebody mentioned banding in a previous comment. Using aq-mode=3 and aq strength of 1.6 removes banding entirely for me. I tested this over and over again and 1.6 gives you the lowest QP (highest quality possible). Going above 1.6 lowers the quality. With SolLevante using 1.6 and aq-mode=3 removes all banding on a professionally calibrated LGC9 OLED.

[benwaggoner]

One thing I've noticed is that no-hme is used in all 10 presets by default. Is this because the encoding time added is huge by using hme? I have tried it on SolLevante, but it's a very short piece of material so I could get away with it. But, unless you have a supercomputer I don't think hme is even viable to setups like mine.
The bigger reason is probably that --hme wasn't done the last time the presets were implemented. I honestly haven't seen that much benefit from using it for single-stream encoding. In theory it might help quality at UHD resolution with a lot of grain/noise.

The primary use case for that the --hme infrastructure was built around was to encode lower resolutions of the bitrate ladder and use the analysis data from that to encode the next resolution up a lot faster.

So 540 -> 1080 -> 2160 and 360 -> 720 -> 1440.

Using the --hme command lets you emulate the quality impact of doing the above, but without the speed benefits. I'm not sure how much parallelism is implemented in there; the speed hit could be a lot less or even get faster with enough cores if properly threaded.

--hme also allows for different search ranges and methods to be used for each resolution tier, which would allow for finer-grained quality and performance tuning.

I cannot encode a full movie using beyond medium. Medium and a movie of about 90 minutes is around 2 days. But, I am well aware my current encoding PC is woefully inadequate. However, for now I'm fine with it. I don't mind an encode taking 4 or 5 days, that's fine, but anything over a week is not something I can achieve right now. So I will test each setting to see the speed impact.
I find a high quality, high bitrate 4K HDR encode takes me about 24 hours per hour of source on my somewhat old workstation, using --pools to pin each encode to one socket of: "Intel(R) Xeon(R) Gold 6240 CPU @ 2.60GHz, 2594 Mhz, 18 Core(s), 36 Logical Processors."

If I'm doing content-specific tuning, I can make it 2-3x faster without significant visible quality loss as I can turn off tools that don't help in that particular case. Things like --tu-inter/intra 4 and --tskip can help a lot with some content and do nothing for other content.

I'm encoding at uhd-bd=1 maxrate which is around 98 Mbps. That's my target bit-rate. I use Constant Rate Factor = 0. But that doesn't mean that you don't have bit-rate control. Bit-rates can still bit controlled by using vbv-maxrate=98000:vbv-bufsize=99000. When using maxrate with CFR it essentially becomes the target bit-rate, and buffsize basically turns into maxrate when compared to a 2-pass encode. I read this in the x265 docs, and since doing it my encodes look incredible.

What this does is makes it so anything under my target bit-rates is essentially transparent, and anything getting up to 98 Mbps is so high in bit-rate that it basically transparent also.

SolLevante was encoded using these settings and my final average bit-rate is 68.7 Mb/s. The average QP is 8.21.
Yeah, a mean QP of ~8 is going to look really good almost irrespective of what you do! This is reliant on having a really high bitrate, though.

[Boulder]

If you are going to hit bitrates that high, why bother re-encoding at all?

[HD MOVIE SOURCE]

If you are going to hit bitrates that high, why bother re-encoding at all?

The original file of SolLevante from Netflix has a bit-rate of 1200 Mbps, which is not a re-encode.

However, I have re-encoded many things like Big Buck Bunny, Tears of Steel, and others just for science, and just for fun. I like to see how close to the original source I can get.

Yeah, a mean QP of ~8 is going to look really good almost irrespective of what you do! This is reliant on having a really high bitrate, though.

Yeah, it looks incredible. How do you know when it's a good time to use tskip? The settings do offer incredible detail, if it's possible to encode at 1 hour per day and use these settings that would be really cool.

[benwaggoner]

The original file of SolLevante from Netflix has a bit-rate of 1200 Mbps, which is not a re-encode.

However, I have re-encoded many things like Big Buck Bunny, Tears of Steel, and others just for science, and just for fun. I like to see how close to the original source I can get.
That's an interesting mix of content. Sol Levante is one of the most challenging clips I've ever seen, and Big Buck Bunny one of the easiest. Neither are particularly representative of mainstream content. Tears of Steel is the most representative of typical TV/movie content, with a mix of live action and CGI.

Yeah, it looks incredible. How do you know when it's a good time to use tskip? The settings do offer incredible detail, if it's possible to encode at 1 hour per day and use these settings that would be really cool.
I use --tskip when there are very sharp visual elements with low noise. CGI, cel animation, text, titles, and credits all can benefit. Live action with some noise rarely gets as much value.

In general, --tskip is useful in similar scenarios where --tu-inter/intra 4 are helpful. And the even slower --cu-lossless only really helps when --tskip is already helpful, or at extremely high bitrates.

[HD MOVIE SOURCE]

That's an interesting mix of content. Sol Levante is one of the most challenging clips I've ever seen, and Big Buck Bunny one of the easiest. Neither are particularly representative of mainstream content. Tears of Steel is the most representative of typical TV/movie content, with a mix of live action and CGI.


I use --tskip when there are very sharp visual elements with low noise. CGI, cel animation, text, titles, and credits all can benefit. Live action with some noise rarely gets as much value.

In general, --tskip is useful in similar scenarios where --tu-inter/intra 4 are helpful. And the even slower --cu-lossless only really helps when --tskip is already helpful, or at extremely high bitrates.

Though I have been encoding at 98 Mbps, SolLevante is definitely difficult content to encode. There's lots of complex movements, and I have seen artifacts in the past. While I was encoding that, I started from scratch and there must have been some odd settings that were causing issues because I never see any breakup now.

I'd like to try a really slow encode one time with all the detail settings that you have provided just for fun.

I always though tskip was a speed increase, but it's definitely a speed loss. Is -tskip-fast a weaker version of tskip?

Thanks for the help.

[benwaggoner]

I always though tskip was a speed increase, but it's definitely a speed loss. Is -tskip-fast a weaker version of tskip?

--tskip definitely slows things down. --tskip-fast reduced the speed impact, but can miss some cases where tranform skip would have been better that straight --tskip would have found. But you certainly get most of the benefit with a lot less of the speed hit using --tskip --tskip-fast.

[jpsdr]

I have an encode running and it will finish only on a few days, so i can't make tests right now (and also can't check the speed difference), so i'll ask... ;)
Is tskip enabled in slower preset ? (Or in any preset)
Is tskip significant, on 4k HDR 10 bits, on multipass encode, average 40000, maxrate 90000 vbv-buffsize 70000 ?
In any case, from what i've understood, --tskip --tskip-fast will always be better than without tskip, if tskip is realy too slow. As i don't have tskip in my settings and i'm at 0,5fps encode speed, i'm not realy enthusiast reducing speed more... :(

[benwaggoner]

Is tskip enabled in slower preset ? (Or in any preset)
Nope, not in any preset (it should be on for placebo at least, IMHO). You can see all the preset parameters here:
https://x265.readthedocs.io/en/master/presets.html

Is tskip significant, on 4k HDR 10 bits, on multipass encode, average 40000, maxrate 90000 vbv-buffsize 70000 ?
I doubt it'll make a visible difference at those bitrates. I certainly wouldn't consider using it until I was at least at --preset slower except for very specific content.

In any case, from what i've understood, --tskip --tskip-fast will always be better than without tskip, if tskip is realy too slow. As i don't have tskip in my settings and i'm at 0,5fps encode speed, i'm not realy enthusiast reducing speed more... :(
Tskip won't make things worse, but there is content where it'll burn a lot of CPU without offering appreciable benefit. For example, anywhere there is visible grain.

[jpsdr]

I am at preset slower with the bitrate i've told, so according your answer it will probably not make a visible difference. When your encode take between 10-15 days, and following this thread you realised that, maybe, you've missed an option to increase quality, you're very... (don't know how to translate, anyway) after having allready done around 3-4 files... :(
But according your answer, it seems that i didn't miss so much, going a little more... :)
As i denoised/degrain (so i'm not in the "bad case"), i, out of curiosity, when my encode will finish, make a quick test to see the effect on the speed.

[tormento]

What is the difference between tskip and tskip-fast? Why they can be used together? What will happen?

[benwaggoner]

What is the difference between tskip and tskip-fast? Why they can be used together? What will happen?
--tskip-fast doesn't do anything if --tskip isn't on. If --tskip is on, it will do a slower, more thorough job without --tskip-fast than if it is on. For most content, --tskip is only occassionally helpful, and --tskip-fast catches most of those cases. --tskip by itself has a pretty big perf hit, So I recommend trying it with --tskip-fast first, and seeing if there is any benefit. If there is benefit, try without --tskip fast and see if there is additional benefit worth the slower encoding speed.

[benwaggoner]

In retrospect, it should have been implemented as --tskip 0, 1, or 2, following the other speed/quality ordinal parameters like --me, --subme, --limit-refs, etc.

[jpsdr]

I've made a very quick test on a 10 frames video, speed difference between with and without tskip is 0,52fps to 0,49fps, i can live with that... :)

[benwaggoner]

I've made a very quick test on a 10 frames video, speed difference between with and without tskip is 0,52fps to 0,49fps, i can live with that... :)
I suspect the gap will be larger with a more representative number of frames. You need to encode a decent multiple of --keyint to get accurate performance numbers. 10 frames is less than default --rc-lookahead, and fps is typically way higher for the --rc-lookahead duration.

--rc-lookahead is really a secret weapon for improving quality and reducing quality fluctuations with single-pass encoding.

[jpsdr]

Seeing the speed of a big real encode i've started, I think my true drop is 0,50 average to 0,42 average. It's allmost 20%... I'll check with --tskip-fast... If it catches allmost all the cases for a speed drop less significant, it will be enough for me. rc-lookahead is set to 48.

[HD MOVIE SOURCE]

Yeah, tskip is too impactful on performance with my current step, not the end of the world for me, I'm pretty happy with my current detail settings. I would use rect, amp, hme and tskip if I could, But a full movie is 2 days with my settings, and 20+ days with just adding these 4 settings, so that shows you how much impact they have, and how unoptimized my pc is for encoding, LOL.

Because SolLevante is only around 4 thousand frames, I encoded that using the highest settings possible, placebo and hme / tskip and the quality is shockingly good. Took me 2 days, but I wanted to see it and it doesn't disappoint.

Unless there's anymore settings that Ben is keeping secret from us, I think its about as good as it gets. haha...

[benwaggoner]

Wow, those four commands should NOT cause encoding time to go up 10x! I haven't seen --hme really prove its value yet. Have you?

You can get --amp and --rect with much less of a hit using --limit-refs 2 or 3
And of course, add --tskip-fast with tskip

[jpsdr]

@benwaggoner
What do you know (brief/quick) of the new commited option ?

[benwaggoner]

@benwaggoner
What do you know (brief/quick) of the new commited option ?
A MCTF filter essentially removes psychovisually irrelevant detail, making the video easier to encode. So better quality at a fixed bitrate, lower bitrate for a fixed quality. It can be quite helpful for moderate-low bitrates.

I've not tried this new implementation yet myself.

[jpsdr]

@benwagonner
Sorry to bother you again... :D
First, thank for explanation, i read the code of the commit, and from the few i understood, it adjusts, for each frame, according the content, the aq-mode. It seems indeed interesting.
Also, if i understood properly, you just need to put --sbrc, no aq-mode is needed anymore.

--hevc-aq and aq-mode are exclusive. Do you happend to know (by any chance), if there is one "better" than the other ? Or is it just 2 differents ways, but with no one realy better than anoter ?

Don't tested yet --hevc-aq with sbrc, but from the few i understood, they should be also exclusive but see nothing about it in the commited code...

[benwaggoner]

@benwagonner
Sorry to bother you again... :D
First, thank for explanation, i read the code of the commit, and from the few i understood, it adjusts, for each frame, according the content, the aq-mode. It seems indeed interesting.
Also, if i understood properly, you just need to put --sbrc, no aq-mode is needed anymore.
That would be welcome! Different modes are appropriate for different kinds of content. And appropriate --aq-strength varies a lot too.

--hevc-aq and aq-mode are exclusive. Do you happend to know (by any chance), if there is one "better" than the other ? Or is it just 2 differents ways, but with no one realy better than anoter ?
IIRC --aq-mode 4 is the final implementation of --hevc-aq.

[jpsdr]

IIRC --aq-mode 4 is the final implementation of --hevc-aq.


Ah... Ok...
The, the choice would be between sbrc or aq-mode 5, which are both adaptative AQ modes.

[benwaggoner]

Ah... Ok...
The, the choice would be between sbrc or aq-mode 5, which are both adaptative AQ modes.
...assuming there is a build which has both --aq-mode 5 and sbrc. And that they mean the same things. That's the tricky thing with forks. I hope we can reunify everything useful back into mainline.

[jpsdr]

Now there is... :D

[benwaggoner]

Now there is... :D
You mean this?
https://github.com/jpsdr/x265

[jpsdr]

Yes it is.

[tormento]

...assuming there is a build which has both --aq-mode 5 and sbrc.
You tried to play with 5? I am curious to read your findings about modes above 3.

[benwaggoner]

You tried to play with 5? I am curious to read your findings about modes above 3.
I've found --aq-mode 4 to be a good default for SDR content at this point, at least in the context of all the other tuning I do, and with mezzaine quality sources.

--aq-mode 2 does better for hdr still, at least in my target scenarios.

[tormento]

I've found --aq-mode 4 to be a good default for SDR content at this point
What about 5?

[benwaggoner]

What about 5?
That's only in custom forks that I've not played with.

[jpsdr]

I took a quick look at the part code of hevc-aq, and it realy doesn't look like aq-mode 4...
Real question : Is the purpose of hevc-aq of being more suitable to HDR-PQ than the others standard aq-mode ? (If i ask this it's because of the hevc part in the name... :D)

[benwaggoner]

I don't recall anything HDR-specific about --hevc-aq.

[HD MOVIE SOURCE]

I suspect the gap will be larger with a more representative number of frames. You need to encode a decent multiple of --keyint to get accurate performance numbers. 10 frames is less than default --rc-lookahead, and fps is typically way higher for the --rc-lookahead duration.

--rc-lookahead is really a secret weapon for improving quality and reducing quality fluctuations with single-pass encoding.

Sorry for the late response to this one, but what if I'm using constant rate factor with a keyint of 24 and an rc-lookahead of 24. Is there any quality gains to be had past this? I used to try 48 for rc-lookahead to be 1 second in front just to cover my back, but I was told that going over the keyint is never worth it / a waste of time.

Responding to some thoughts about aq-modes. I have personally found that aq-mode 3 seems to be best for all the content that Ive encoded, and seems to cover your back with any scenes that have black level detail. One thing that I noticed is that using aq-mode 3, and with a relatively high strength like 1.7 seems to remove microbanding, and any odd banding or bit-depth errors.

[Blue_MiSfit]

Any reason you're punching yourself in the face with such a short keyint? I'd suggest at least 2 seconds (and ideally 4-10) to let x265 stretch its legs :)

I don't think there's any benefit to rc-lookahead > keyint but I'll let Ben chime in on that

[HD MOVIE SOURCE]

Any reason you're punching yourself in the face with such a short keyint? I'd suggest at least 2 seconds (and ideally 4-10) to let x265 stretch its legs :)

I don't think there's any benefit to rc-lookahead > keyint but I'll let Ben chime in on that

Thats the keyint required for uhd-bd=1.

[benwaggoner]

Thats the keyint required for uhd-bd=1.
OG Blu-ray would allow a 2-sec GOP if the --vbv-maxrate was 15000 Kbps or below. Does UHD-BD have any equivalent option?

Back when I was trying to fit BD content on a DVD-R, I'd often use the 15 Mbps cap so I could get the longer GOPs. Going to level 4.0 instead of 4.1 also eliminates the requirement for four slices, although takes the vbv-maxrate down to 25 Mbps from 40 Mbps.

With a 2 sec GOP and single slice, most 1080p24 content could still look excellent at a 15 Mbps peak, and the improved efficiency would make average quality better than with higher peaks but with slices and 1 sec GOP.

Only mattered when trying to stick a good amount of content on a small disc, though.

[HD MOVIE SOURCE]

OG Blu-ray would allow a 2-sec GOP if the --vbv-maxrate was 15000 Kbps or below. Does UHD-BD have any equivalent option?

Back when I was trying to fit BD content on a DVD-R, I'd often use the 15 Mbps cap so I could get the longer GOPs. Going to level 4.0 instead of 4.1 also eliminates the requirement for four slices, although takes the vbv-maxrate down to 25 Mbps from 40 Mbps.

With a 2 sec GOP and single slice, most 1080p24 content could still look excellent at a 15 Mbps peak, and the improved efficiency would make average quality better than with higher peaks but with slices and 1 sec GOP.

Only mattered when trying to stick a good amount of content on a small disc, though.

Good question, honestly not sure. I've always thought UHD-bd was always a 1 second GOP. I may have tried 2 seconds before and I think the encode failed, but I could be wrong.

[benwaggoner]

Good question, honestly not sure. I've always thought UHD-bd was always a 1 second GOP. I may have tried 2 seconds before and I think the encode failed, but I could be wrong.
I don't know if UHD-BD's spec allows for 2-sec GOP in any case. UHD BD was intentionally as small as possible delta from the original Blu-ray spec. it's basically support for higher density discs plus HEVC 4K. But all the BD-J and overlays are still only 1080p.

I don't think that the special <25 Mbps (can use a single slice instead of 4) or <15 Mbps (can use 2 sec GOP) modes were used much (if ever) with commercial discs, nor was consumer authoring a concern with the UHD upgrade, so it'd be unsurprising if there's no equivalent.

[benwaggoner]

Sorry for the late response to this one, but what if I'm using constant rate factor with a keyint of 24 and an rc-lookahead of 24. Is there any quality gains to be had past this? I used to try 48 for rc-lookahead to be 1 second in front just to cover my back, but I was told that going over the keyint is never worth it / a waste of time.
--rc-lookahead is capped at --keyint in any case, so it doesn't really matter.

I've certainly seen valuable quality improvements (specifically big reductions in quality variations that yield visibly poor quality) when increasing keyint and rc-lookahead from 2 to 5 seconds, and that was mostly due to the higher --rc-lookahead (comparing --keyint 120 --rc-lookahead 48 versus 128). That said, --rc-lookahead is most impactful with single-pass --crf encodes. It offers benefit with 1-pass CBR, but a full two-pass encode is basically rc-lookahead=total frames.

Responding to some thoughts about aq-modes. I have personally found that aq-mode 3 seems to be best for all the content that Ive encoded, and seems to cover your back with any scenes that have black level detail. One thing that I noticed is that using aq-mode 3, and with a relatively high strength like 1.7 seems to remove microbanding, and any odd banding or bit-depth errors.
--aq-mode 3 is identical to --aq-mode 2 except that it lowers QP as luma values get nearer to black. This gets around Rec. 709's perceptual non-uniformity, where the difference between luma of 16 and 17 is much more visible than between, say 216 and 217. So the same compression artifacts can be much more visible near black than near white.

--aq-mode 3 can really help shadow detail and reduce banding near black. However, those lower QPs use more bits. For CBR and VBV-limited encodes, this increases QP of brighter frames, which can introduce new quality issues. Or in CRF mode, increase ABR quite a bit. It's a great tool when there's enough bandwidth, but needs to be used delicately at lower bitrates. It's not a safe feature to just leave always on when targeting best possible quality at low bitrates. It helps sometimes, and hurts others. Lower --aq-strength values are optimal with aq-mode 3 than 2 as well, as high values can really starve brighter macroblocks of bits.

It's also not appropriate for HDR-10, which is much more perceptually uniform, and where the visible difference between luma values is pretty much identical at any brightness.

10-bit encoding can make --aq-mode less needed as well, as the difference between 8-bit 16 and 17 now is the difference between 64 and 68, and those four extra steps make for more efficient encoding, reduce the need for dithering, and generally makes for much less visible banding and blocking.

I'm confident that --aq-mode 3 could be improved to be more content-adaptive. It'd prefer x264 to have aq-mode algorithm selection decouple from luma bias. So we could do stuff like

--aq-mode 4 --low-luma-bias 0.7

And make --aq-mode 3 essentially an alias to

--aq-mode 2 --low-luma-bias 1.0

[Boulder]

I'm confident that --aq-mode 3 could be improved to be more content-adaptive. It'd prefer x264 to have aq-mode algorithm selection decouple from luma bias. So we could do stuff like

--aq-mode 4 --low-luma-bias 0.7

And make --aq-mode 3 essentially an alias to

--aq-mode 2 --low-luma-bias 1.0

For example jpsdr's recent x265 mods have this kind of a feature. There is the parameter --aq-bias-strength which is a multiplier on top of aq-strength. I believe it should make --sbrc work more efficiently. (aq-mode 5 mentioned here is aq-mode 4 + low luma bias)

--aq-bias-strength <float>
Adjust the strength of dark scene bias in AQ modes 3 and 5. Setting this
to 0 will disable the dark scene bias, meaning modes will be equivalent to
their unbiased counterparts (2 and 4).
Default 1.0.

[madey83]

--rc-lookahead is capped at --keyint in any case, so it doesn't really matter.

I've certainly seen valuable quality improvements (specifically big reductions in quality variations that yield visibly poor quality) when increasing keyint and rc-lookahead from 2 to 5 seconds, and that was mostly due to the higher --rc-lookahead (comparing --keyint 120 --rc-lookahead 48 versus 128). That said, --rc-lookahead is most impactful with single-pass --crf encodes. It offers benefit with 1-pass CBR, but a full two-pass encode is basically rc-lookahead=total frames.


--aq-mode 3 is identical to --aq-mode 2 except that it lowers QP as luma values get nearer to black. This gets around Rec. 709's perceptual non-uniformity, where the difference between luma of 16 and 17 is much more visible than between, say 216 and 217. So the same compression artifacts can be much more visible near black than near white.

--aq-mode 3 can really help shadow detail and reduce banding near black. However, those lower QPs use more bits. For CBR and VBV-limited encodes, this increases QP of brighter frames, which can introduce new quality issues. Or in CRF mode, increase ABR quite a bit. It's a great tool when there's enough bandwidth, but needs to be used delicately at lower bitrates. It's not a safe feature to just leave always on when targeting best possible quality at low bitrates. It helps sometimes, and hurts others. Lower --aq-strength values are optimal with aq-mode 3 than 2 as well, as high values can really starve brighter macroblocks of bits.

It's also not appropriate for HDR-10, which is much more perceptually uniform, and where the visible difference between luma values is pretty much identical at any brightness.

10-bit encoding can make --aq-mode less needed as well, as the difference between 8-bit 16 and 17 now is the difference between 64 and 68, and those four extra steps make for more efficient encoding, reduce the need for dithering, and generally makes for much less visible banding and blocking.

I'm confident that --aq-mode 3 could be improved to be more content-adaptive. It'd prefer x264 to have aq-mode algorithm selection decouple from luma bias. So we could do stuff like

--aq-mode 4 --low-luma-bias 0.7

And make --aq-mode 3 essentially an alias to

--aq-mode 2 --low-luma-bias 1.0



Hi,

What could be your settings recommendation for Dolby vision encoder to have quite small file for 43 minutes episode ( 1-1.5GB)?

[HD MOVIE SOURCE]

--rc-lookahead is capped at --keyint in any case, so it doesn't really matter.

I've certainly seen valuable quality improvements (specifically big reductions in quality variations that yield visibly poor quality) when increasing keyint and rc-lookahead from 2 to 5 seconds, and that was mostly due to the higher --rc-lookahead (comparing --keyint 120 --rc-lookahead 48 versus 128). That said, --rc-lookahead is most impactful with single-pass --crf encodes. It offers benefit with 1-pass CBR, but a full two-pass encode is basically rc-lookahead=total frames.


--aq-mode 3 is identical to --aq-mode 2 except that it lowers QP as luma values get nearer to black. This gets around Rec. 709's perceptual non-uniformity, where the difference between luma of 16 and 17 is much more visible than between, say 216 and 217. So the same compression artifacts can be much more visible near black than near white.

--aq-mode 3 can really help shadow detail and reduce banding near black. However, those lower QPs use more bits. For CBR and VBV-limited encodes, this increases QP of brighter frames, which can introduce new quality issues. Or in CRF mode, increase ABR quite a bit. It's a great tool when there's enough bandwidth, but needs to be used delicately at lower bitrates. It's not a safe feature to just leave always on when targeting best possible quality at low bitrates. It helps sometimes, and hurts others. Lower --aq-strength values are optimal with aq-mode 3 than 2 as well, as high values can really starve brighter macroblocks of bits.

It's also not appropriate for HDR-10, which is much more perceptually uniform, and where the visible difference between luma values is pretty much identical at any brightness.

10-bit encoding can make --aq-mode less needed as well, as the difference between 8-bit 16 and 17 now is the difference between 64 and 68, and those four extra steps make for more efficient encoding, reduce the need for dithering, and generally makes for much less visible banding and blocking.

I'm confident that --aq-mode 3 could be improved to be more content-adaptive. It'd prefer x264 to have aq-mode algorithm selection decouple from luma bias. So we could do stuff like

--aq-mode 4 --low-luma-bias 0.7

And make --aq-mode 3 essentially an alias to

--aq-mode 2 --low-luma-bias 1.0

Very valuable info, thank you. I'd be interested in trying the 5x keyint for lookahead. Does higher lookahead require much more processing time? If so, it really depends on what can be gained from 5x lookahead.

I have thought about having bit-rate starved on brighter scenes, but I haven't found it to be an issue when bit-rates are high enough. I guess it could be an issue for bit-rate-restricted content. I typically find that black-level detail can still be an issue even on 4K discs. So even using it as a tool to distribute more bits into black-level detail is useful. Do you think this is why it potentially could improve gradients from black to full color? Because there are more bits being distributed in the low end of the spectrum and now the gradients look smoother?

[benwaggoner]

For example jpsdr's recent x265 mods have this kind of a feature. There is the parameter --aq-bias-strength which is a multiplier on top of aq-strength. I believe it should make --sbrc work more efficiently. (aq-mode 5 mentioned here is aq-mode 4 + low luma bias)

--aq-bias-strength <float>
Adjust the strength of dark scene bias in AQ modes 3 and 5. Setting this
to 0 will disable the dark scene bias, meaning modes will be equivalent to
their unbiased counterparts (2 and 4).
Default 1.0.
Well, that's just lovely! Have these changes been contributed back to MCW for x265? I've exactly this feature with MCW developers before, and they showed some interest.

I don't really use other private forks much to keep my settings compatible with other x265 implementations. I'm going to try this one out; I have some content types where those tweaks could really make a difference.

[Boulder]

Well, that's just lovely! Have these changes been contributed back to MCW for x265? I've exactly this feature with MCW developers before, and they showed some interest.

I don't really use other private forks much to keep my settings compatible with other x265 implementations. I'm going to try this one out; I have some content types where those tweaks could really make a difference.

Unfortunately not, at least I've not seen it discussed in the x265-devel list. In my opinion, it is too difficult to contribute since it's not just about submitting a pull request but requires more effort.

[benwaggoner]

What could be your settings recommendation for Dolby vision encoder to have quite small file for 43 minutes episode ( 1-1.5GB)?
Profile 5 or 8.1?

Those file sizes give around 3-4.5 Mbps; pretty darn low for 4K. I'd look at scaling down to 1080p or maybe 1440p. I think only clean animation would encode well at those bitrates. Something with even light noise might require --crf 30 at full resolution. 2-pass encoding could be preferable as final file sizes would vary a lot depending on source specifics.

The job is more about artifact suppression than fine detail retention at those bitrates. So definitely you'll want --sao, default in-loop deb locking, some --nr-intra, maybe some <100 --nr-inter. And I'd start with --preset slower at a minimum.

[benwaggoner]

Very valuable info, thank you. I'd be interested in trying the 5x keyint for lookahead. Does higher lookahead require much more processing time? If so, it really depends on what can be gained from 5x lookahead.
--rc-lookahead can't be higher than --keyint. For single pass encodes when I have enough RAM and time, I try to use keyint=rc-lookahead.

There is some slowdown with higher values, but I find it's relatively cheap as quality/speed tradeoff features go. The bigger limitation is the RAM requirements, which can increase almost linearly with --rc-lookahead. I've had a 60 GB single x265 process doing 8K 10-bit encoding with --rc-lookahead 96.

I have thought about having bit-rate starved on brighter scenes, but I haven't found it to be an issue when bit-rates are high enough. I guess it could be an issue for bit-rate-restricted content. I typically find that black-level detail can still be an issue even on 4K discs. So even using it as a tool to distribute more bits into black-level detail is useful. Do you think this is why it potentially could improve gradients from black to full color? Because there are more bits being distributed in the low end of the spectrum and now the gradients look smoother?
Yeah, --aq-mode 3 lowers QP near black, and so a gradient that has one end that dark will benefit from it.

Using 10-bit instead of 8-bit can also really help gradients in general. And use the --dither parameter if you're encoding at a lower color depth than the source, which can help reduce 8-bit SDR banding as well.

Lots of these things are bitrate related. If you have enough bits, they may not be much of an issue. But if trying to really maximize bang for the bit, careful tuning can really help. Optimal --aq-mode and --aq-strength can vary quite a bit in different shots and scenes.

A whole lot of deep amazing things can be done using x265 as .dll instead of an .exe, where some parameters can be varied by GOP, frame, and even CU.

It'd be lovely to have some sort of standard XML syntax for .dll specific tweaks with an .exe that would parse those and pass them on to the .dll in a predictable and portable way.

[madey83]

Profile 5 or 8.1?

Those file sizes give around 3-4.5 Mbps; pretty darn low for 4K. I'd look at scaling down to 1080p or maybe 1440p. I think only clean animation would encode well at those bitrates. Something with even light noise might require --crf 30 at full resolution. 2-pass encoding could be preferable as final file sizes would vary a lot depending on source specifics.

The job is more about artifact suppression than fine detail retention at those bitrates. So definitely you'll want --sao, default in-loop deb locking, some --nr-intra, maybe some <100 --nr-inter. And I'd start with --preset slower at a minimum.

Hi,
Sorry but I did not mention that I will downscale to 1080p profile 5 as original source and for noise source I'd probably use some denise filter.

My preference for encode is crf

[HD MOVIE SOURCE]

--rc-lookahead can't be higher than --keyint. For single pass encodes when I have enough RAM and time, I try to use keyint=rc-lookahead.

There is some slowdown with higher values, but I find it's relatively cheap as quality/speed tradeoff features go. The bigger limitation is the RAM requirements, which can increase almost linearly with --rc-lookahead. I've had a 60 GB single x265 process doing 8K 10-bit encoding with --rc-lookahead 96.


Yeah, --aq-mode 3 lowers QP near black, and so a gradient that has one end that dark will benefit from it.

Using 10-bit instead of 8-bit can also really help gradients in general. And use the --dither parameter if you're encoding at a lower color depth than the source, which can help reduce 8-bit SDR banding as well.

Lots of these things are bitrate related. If you have enough bits, they may not be much of an issue. But if trying to really maximize bang for the bit, careful tuning can really help. Optimal --aq-mode and --aq-strength can vary quite a bit in different shots and scenes.

A whole lot of deep amazing things can be done using x265 as .dll instead of an .exe, where some parameters can be varied by GOP, frame, and even CU.

It'd be lovely to have some sort of standard XML syntax for .dll specific tweaks with an .exe that would parse those and pass them on to the .dll in a predictable and portable way.

Great info, thank you.

[benwaggoner]

Hi,
Sorry but I did not mention that I will downscale to 1080p profile 5 as original source and for noise source I'd probably use some denise filter.

My preference for encode is crf
Profile 5 can be somewhat challenging for an encoder, as it shifts the PQ EOTF to maximize the dynamic range of the current shot. So, if encoding something that's only 100 nits, it'll expand the Y' range higher so there are more code values.

This looks a lot like fades to the encoder, so having p- and b-frame weighted prediction on is important. The --fades feature could help as well, although I've never actually gotten it to result in different output than not using it.

The expanded range can also through off tools that presume encoding to actually perceptually linear code values. The impact of --nr-* could vary in strength on the same content if they got mapped to different code values. The broader range of code values the image gets mapped to, the stronger the AC coefficients will be, and so the less impact a given --nr-* strength would have.

Long way of saying that it might be better to apply denoising in uncompressed PQ ICtCp before or after scaling, and send denoised frames to the encoder instead of using the built-in tools.

I've not actually tested this empirically, but it seems kind of inevitable barring some DoVi Profile 5 specific optimization in x265 that would compensate for the range expansion.

[madey83]

Profile 5 can be somewhat challenging for an encoder, as it shifts the PQ EOTF to maximize the dynamic range of the current shot. So, if encoding something that's only 100 nits, it'll expand the Y' range higher so there are more code values.

This looks a lot like fades to the encoder, so having p- and b-frame weighted prediction on is important. The --fades feature could help as well, although I've never actually gotten it to result in different output than not using it.

The expanded range can also through off tools that presume encoding to actually perceptually linear code values. The impact of --nr-* could vary in strength on the same content if they got mapped to different code values. The broader range of code values the image gets mapped to, the stronger the AC coefficients will be, and so the less impact a given --nr-* strength would have.

Long way of saying that it might be better to apply denoising in uncompressed PQ ICtCp before or after scaling, and send denoised frames to the encoder instead of using the built-in tools.

I've not actually tested this empirically, but it seems kind of inevitable barring some DoVi Profile 5 specific optimization in x265 that would compensate for the range expansion.

Hi,

Thank you for this but this is to deep explanation for me.
I have found below and I would like to ask if belove settings are good or there is something to change to get better results:


Cry Macho 2021 1080p UHD BluRay DD+5.1 DoVi x265-DON

Writing library : x265 3.5+39-931178347:[Windows][MSVC 1933][64 bit] 10bit
Encoding settings : cpuid=1049583 / frame-threads=4 / numa-pools=24 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x804 / interlace=0 / total-frames=0 / level-idc=51 / high-tier=1 / uhd-bd=0 / ref=6 / no-allow-non-conformance / repeat-headers / annexb / aud / no-eob / no-eos / hrd / info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=23 / keyint=250 / gop-lookahead=0 / bframes=16 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=40 / lookahead-slices=4 / scenecut=40 / no-hist-scenecut / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=4 / tu-intra-depth=4 / limit-tu=4 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=4 / limit-refs=1 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / weightb / no-analyze-src-pics / deblock=-3:-3 / no-sao / no-sao-non-deblock / rd=4 / selective-sao=0 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=2.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=13.7 / qcomp=0.80 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=160000 / vbv-bufsize=160000 / vbv-init=0.9 / min-vbv-fullness=50.0 / max-vbv-fullness=80.0 / crf-max=0.0 / crf-min=0.0 / ipratio=1.20 / pbratio=1.10 / aq-mode=1 / aq-strength=0.85 / no-cutree / zone-count=8 / zones: / start-frame=112 / end-frame=430 / bitrate-factor=4.000000 / zones: / start-frame=14684 / end-frame=15005 / bitrate-factor=7.000000 / zones: / start-frame=16507 / end-frame=17008 / bitrate-factor=1.500000 / zones: / start-frame=17009 / end-frame=17145 / bitrate-factor=2.000000 / zones: / start-frame=17601 / end-frame=23536 / bitrate-factor=2.500000 / zones: / start-frame=31365 / end-frame=37290 / bitrate-factor=3.000000 / zones: / start-frame=44733 / end-frame=50608 / bitrate-factor=3.000000 / zones: / start-frame=140360 / end-frame=140415 / bitrate-factor=3.000000 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=9 / transfer=16 / colormatrix=9 / chromaloc=1 / chromaloc-top=2 / chromaloc-bottom=2 / display-window=0 / master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50) / cll=1134,104 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 / no-opt-cu-delta-qp / no-aq-motion / hdr10 / hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass



Of course without providing zones to encoder.

[benwaggoner]

Could you give me your command line instead? That's easier to parse.

[madey83]

Could you give me your command line instead? That's easier to parse.


This is not mine. I found it on internet

[HD MOVIE SOURCE]

--rc-lookahead is capped at --keyint in any case, so it doesn't really matter.


--aq-mode 3 is identical to --aq-mode 2 except that it lowers QP as luma values get nearer to black. This gets around Rec. 709's perceptual non-uniformity, where the difference between luma of 16 and 17 is much more visible than between, say 216 and 217. So the same compression artifacts can be much more visible near black than near white.

--aq-mode 3 can really help shadow detail and reduce banding near black. However, those lower QPs use more bits. For CBR and VBV-limited encodes, this increases QP of brighter frames, which can introduce new quality issues. Or in CRF mode, increase ABR quite a bit. It's a great tool when there's enough bandwidth, but needs to be used delicately at lower bitrates. It's not a safe feature to just leave always on when targeting best possible quality at low bitrates. It helps sometimes, and hurts others. Lower --aq-strength values are optimal with aq-mode 3 than 2 as well, as high values can really starve brighter macroblocks of bits.

It's also not appropriate for HDR-10, which is much more perceptually uniform, and where the visible difference between luma values is pretty much identical at any brightness.

10-bit encoding can make --aq-mode less needed as well, as the difference between 8-bit 16 and 17 now is the difference between 64 and 68, and those four extra steps make for more efficient encoding, reduce the need for dithering, and generally makes for much less visible banding and blocking.

I'm confident that --aq-mode 3 could be improved to be more content-adaptive. It'd prefer x264 to have aq-mode algorithm selection decouple from luma bias. So we could do stuff like

--aq-mode 4 --low-luma-bias 0.7

And make --aq-mode 3 essentially an alias to

--aq-mode 2 --low-luma-bias 1.0

Do you any other settings that could improve detail? How about rskip=0? Is this a setting that is good for grain retention? If it's good for grain retention, could it also be good for small details that are not grain?

Thanks.

[benwaggoner]

Do you any other settings that could improve detail? How about rskip=0? Is this a setting that is good for grain retention? If it's good for grain retention, could it also be good for small details that are not grain?


I've found --rskip 2 --rskip-threshold 2 or 3 works well with typical film grain, without as big a speed hit as --rskip 0.

Raising --psy-rd and --psy-rdoq some can help. Try 3 for each as a starting point.

--ctu 32 for sure

The built-in --nr-inter and --nr-intra aren't particularly advanced denoising filters, but as they operate at the quantization phase, can offer bigger compression efficiency benefits than other methods. Start with something like --nr-intra 100 --nr-inter 400. --nr-intra is a spatial denoising filter and --nr-inter is temporal, which is why we use a good multiple higher as film grain is all temporal.

[HD MOVIE SOURCE]

I've found --rskip 2 --rskip-threshold 2 or 3 works well with typical film grain, without as big a speed hit as --rskip 0.

Raising --psy-rd and --psy-rdoq some can help. Try 3 for each as a starting point.

--ctu 32 for sure

The built-in --nr-inter and --nr-intra aren't particularly advanced denoising filters, but as they operate at the quantization phase, can offer bigger compression efficiency benefits than other methods. Start with something like --nr-intra 100 --nr-inter 400. --nr-intra is a spatial denoising filter and --nr-inter is temporal, which is why we use a good multiple higher as film grain is all temporal.

Okay, thank you. Now, what is it about ctu=32 that has a benefit over ctu=64? This isn't something I know anything about. I just assumed it defaults to 64 and that's where it should be.

Does it just give more control over each block? Would this increase bit-rates?

Thanks.

[HD MOVIE SOURCE]

I've found --rskip 2 --rskip-threshold 2 or 3 works well with typical film grain, without as big a speed hit as --rskip 0.

Raising --psy-rd and --psy-rdoq some can help. Try 3 for each as a starting point.

--ctu 32 for sure

The built-in --nr-inter and --nr-intra aren't particularly advanced denoising filters, but as they operate at the quantization phase, can offer bigger compression efficiency benefits than other methods. Start with something like --nr-intra 100 --nr-inter 400. --nr-intra is a spatial denoising filter and --nr-inter is temporal, which is why we use a good multiple higher as film grain is all temporal.


As with tskip, it has a mode where it can be useful, but use less resources with --tskip-fast. If use rskip, are 0, 1, and 2 just less and less levels of rskip, or are they completely different rskip modes meant for different content? What really asking, is there an rskip-fast like the tskip-fast, because it's extremely useful.

I wanted to ask a bit more about aq-mode=3 and aq-strength. I believe aq-strength ranges from 0 (off) to 3 (full), But, when you set aq-strength to 3 what is that really doing? Is it trying to place 100% of it's bit-rate in darker areas? Or is there a cap even when set to 3 that only, say, 25% of it's bit-rate looks fo darker content?

----Lets just say it looked for 25% of it's bit-rate to be added in dark areas. If I lower aq-strength from 3 to 1.5, would that mean it it not distributes 12.5% of it's bit-rates into dark areas?

I'm just trying to understand how aq-strength works in relation to aq-mode 3.

Thanks.

[benwaggoner]

All your questions and more are answered at: https://x265.readthedocs.io/en/master/cli.html

It specifies the data type of each parameter.

For --rskip, --rskip 2 is the mode you want to use (deprecating the older, poor at grain default --rskip 1). You control speed/quality tradeoff with --rskip 2 with the --rskip-edge-threshold parameter. Lower values are slower but more accurate. The default is 5, and I like to use 2-3 for high quality encoding.

I'm not aware of any methods to estimate the bitrate impact of different --aq-modes, as they are quite content dependent.

[HD MOVIE SOURCE]

All your questions and more are answered at: https://x265.readthedocs.io/en/master/cli.html

It specifies the data type of each parameter.

For --rskip, --rskip 2 is the mode you want to use (deprecating the older, poor at grain default --rskip 1). You control speed/quality tradeoff with --rskip 2 with the --rskip-edge-threshold parameter. Lower values are slower but more accurate. The default is 5, and I like to use 2-3 for high quality encoding.

I'm not aware of any methods to estimate the bitrate impact of different --aq-modes, as they are quite content dependent.

I appreciate it thank you.

[HD MOVIE SOURCE]

I've found --rskip 2 --rskip-threshold 2 or 3 works well with typical film grain, without as big a speed hit as --rskip 0.

Raising --psy-rd and --psy-rdoq some can help. Try 3 for each as a starting point.

--ctu 32 for sure

The built-in --nr-inter and --nr-intra aren't particularly advanced denoising filters, but as they operate at the quantization phase, can offer bigger compression efficiency benefits than other methods. Start with something like --nr-intra 100 --nr-inter 400. --nr-intra is a spatial denoising filter and --nr-inter is temporal, which is why we use a good multiple higher as film grain is all temporal.


With all the settings I'm using to pull out as much detail as possible using x265. One setting that Ive forgot about is cu-lossless. Can this help pull out more detail in grain and fine particles?

[benwaggoner]

With all the settings I'm using to pull out as much detail as possible using x265. One setting that Ive forgot about is cu-lossless. Can this help pull out more detail in grain and fine particles?
No, --cu-lossless just tries mathematically lossless encoding for a given CU, and picks it if it is lower bitrate/distortion. In essence it's a really specialized and compute-intensive subset of --tskip. It would only be used with very high bitrates or some very specialized patterns, like a fully noise-free digitally rendered black/white checkerboard pattern, color bars, or something artificial like that. Grainy content is pretty much the inverse of when it might be helpful.

I've never found a real-world scenario where --cu-lossless would be useful for a distribution encode. Perhaps for a mezzanine file. --tskip should capture most or all of the value at a much lower performance hit. There's no --cu-lossless-fast equivalent to --tskip-fast.

[HD MOVIE SOURCE]

No, --cu-lossless just tries mathematically lossless encoding for a given CU, and picks it if it is lower bitrate/distortion. In essence it's a really specialized and compute-intensive subset of --tskip. It would only be used with very high bitrates or some very specialized patterns, like a fully noise-free digitally rendered black/white checkerboard pattern, color bars, or something artificial like that. Grainy content is pretty much the inverse of when it might be helpful.

I've never found a real-world scenario where --cu-lossless would be useful for a distribution encode. Perhaps for a mezzanine file. --tskip should capture most or all of the value at a much lower performance hit. There's no --cu-lossless-fast equivalent to --tskip-fast.

Thanks, will run some more encodes to see what it's giving me. I'll also run some film grain tests, but as you said, it's very compute-intensive, and you need a monster setup to run this. It's okay for 4-minute content to test, but for full movies, it's a real struggle.

I appreciate the feedback.

[HD MOVIE SOURCE]

No, --cu-lossless just tries mathematically lossless encoding for a given CU, and picks it if it is lower bitrate/distortion. In essence it's a really specialized and compute-intensive subset of --tskip. It would only be used with very high bitrates or some very specialized patterns, like a fully noise-free digitally rendered black/white checkerboard pattern, color bars, or something artificial like that. Grainy content is pretty much the inverse of when it might be helpful.

I've never found a real-world scenario where --cu-lossless would be useful for a distribution encode. Perhaps for a mezzanine file. --tskip should capture most or all of the value at a much lower performance hit. There's no --cu-lossless-fast equivalent to --tskip-fast.

You're right, I tested this on grain content, and I got the exact same results, right down to the average QP. Hmm, interesting, good to know. I was also using tskip, and both encodes with cu-lossless and without have the exact same results. It may as well have been the exact same file. Very interesting.

[benwaggoner]

You're right, I tested this on grain content, and I got the exact same results, right down to the average QP. Hmm, interesting, good to know. I was also using tskip, and both encodes with cu-lossless and without have the exact same results. It may as well have been the exact same file. Very interesting.
Yep, that's what will happen if x265 doesn't detect any CUs where lossless encoding has better rate/distortion. Which I would expect if the clip is all grainy frames.

You may not be getting any benefit from --tskip either. It can help with noise-free credits in grainy movies, but isn't going to be useful for any CU with significant random noise. It's pretty hard to simply spend more compute to make grainy content look better than --preset slower. What improves grain is using the --nr-i* features, lowering ipratio and pbratio, and other things that are more qualitative tuning, not just more expensive modes.

[HD MOVIE SOURCE]

Yep, that's what will happen if x265 doesn't detect any CUs where lossless encoding has better rate/distortion. Which I would expect if the clip is all grainy frames.

You may not be getting any benefit from --tskip either. It can help with noise-free credits in grainy movies, but isn't going to be useful for any CU with significant random noise. It's pretty hard to simply spend more compute to make grainy content look better than --preset slower. What improves grain is using the --nr-i* features, lowering ipratio and pbratio, and other things that are more qualitative tuning, not just more expensive modes.

Good to know, and thank you for the advice.

[HD MOVIE SOURCE]

Yep, that's what will happen if x265 doesn't detect any CUs where lossless encoding has better rate/distortion. Which I would expect if the clip is all grainy frames.

You may not be getting any benefit from --tskip either. It can help with noise-free credits in grainy movies, but isn't going to be useful for any CU with significant random noise. It's pretty hard to simply spend more compute to make grainy content look better than --preset slower. What improves grain is using the --nr-i* features, lowering ipratio and pbratio, and other things that are more qualitative tuning, not just more expensive modes.

Hey, was just running some tests for ctu=64 and ctu=32, and ctu=32 was minorly better. Is this a simple...test on the content first? To find out what's the best methodology? Are there rules like, animation is best on ctu=64 and film is best on ctu=32? Because I was testing film content and 32, again, was better, but by a hair.

Would going lower than this be viable? Have you ever done that?

Also, based on the cut size, does this effect tu-intra-depth and tu-inter-depth? From my understand, tu-intra-depth and tu-inter-depth
are how small into the details the encode goes, is that correct? So for fine details, film grain and things like that tu-intra-depth=4 and tu-inter-depth=4 would typically be better.
Does using ctu=32 effect the size of the intra depth and inter?

[benwaggoner]

Hey, was just running some tests for ctu=64 and ctu=32, and ctu=32 was minorly better. Is this a simple...test on the content first? To find out what's the best methodology? Are there rules like, animation is best on ctu=64 and film is best on ctu=32? Because I was testing film content and 32, again, was better, but by a hair.

Would going lower than this be viable? Have you ever done that?
I've never seen any benefit to using ctu below 32 myself, other squeezing a last bit of extra encoder speed and parallelization.

Also, based on the cut size, does this effect tu-intra-depth and tu-inter-depth? From my understand, tu-intra-depth and tu-inter-depth
are how small into the details the encode goes, is that correct? So for fine details, film grain and things like that tu-intra-depth=4 and tu-inter-depth=4 would typically be better.
Does using ctu=32 effect the size of the intra depth and inter?
They are relative to ctu. So going all 4 down is only possible with ctu 64. ctu 32 to 3, 16 to 2.

[Boulder]

They are relative to ctu. So going all 4 down is only possible with ctu 64. ctu 32 to 3, 16 to 2.
They are relative to TU. The default TU should be the same as CTU as per the docs, but it actually is 32 unless CTU is lower. 32 is enough to use depth 4. I use CTU 32, TU 32, depth 4 in my encodes.

[HD MOVIE SOURCE]

They are relative to TU. The default TU should be the same as CTU as per the docs, but it actually is 32 unless CTU is lower. 32 is enough to use depth 4. I use CTU 32, TU 32, depth 4 in my encodes.

Interesting, are you seeing better encodes using CTU=32? I've seen one encode where the QP only dropped by 0.1 on average, so I didn't know whether to use it or not.

In theory can CTU=32 grab more detail than 64? I might just run some tests for even lower than 32 just to see it.

[Boulder]

Interesting, are you seeing better encodes using CTU=32? I've seen one encode where the QP only dropped by 0.1 on average, so I didn't know whether to use it or not.

In theory can CTU=32 grab more detail than 64? I might just run some tests for even lower than 32 just to see it.

Let's say that I've not seen any quality loss because of it. I mostly do encodes between 720p and 1440p and the lower value improves multithreading a lot.

There is also something strange happening with CTU 64 + limit-tu 0 + rskip 2 and MultiCoreWare just ignored the report. I don't trust that it wouldn't appear also in other cases. CTU 32 doesn't have it.

https://forum.doom9.org/showthread.php?p=1919347&highlight=--limit-tu%2A0#post1919347

[excellentswordfight]

Interesting, are you seeing better encodes using CTU=32? I've seen one encode where the QP only dropped by 0.1 on average, so I didn't know whether to use it or not.
What resolution are you encoding at? There are benefits of using it at high resolutions, i.e. 4k/uhd. Many years ago I asked someone at multicoreware (when they were active here) why they didnt automatically lower it to 32 for lower resolutions as 64 seems a bit overkill there and since it improves multithreading so much by lowering it, and they replied with some numbers showing increased compression efficiency even at 720/1080p, it was minor mind you, and tbh I have never seen any kind noticeable improvement that was worth the speed-penalty on high thread count systems.
In theory can CTU=32 grab more detail than 64? I might just run some tests for even lower than 32 just to see it.
The theory is that larger CU-sizes can compress the image more efficiently, and by that it should actually increase details as it can spend saved bits were more needed instead. But as with a lot of other parameters for improved compression, they might not yield "better" results when encoding for visually lossless, not sure why it would hurt quality in this case though. I've seen people mention that it would improve grain-encoding, but I have yet seen it demonstrated.

[benwaggoner]

Interesting, are you seeing better encodes using CTU=32? I've seen one encode where the QP only dropped by 0.1 on average, so I didn't know whether to use it or not.

In theory can CTU=32 grab more detail than 64? I might just run some tests for even lower than 32 just to see it.
I have seen --ctu 32 provide better quality with very grainy content at 4K and HD resolutions.

[HD MOVIE SOURCE]

I have seen --ctu 32 provide better quality with very grainy content at 4K and HD resolutions.

Thats interesting. Does CTU=32 typically cost more bit-rate to use than CT=64? Is CTU=64, typically better for animation with plain objects, like plain skies, where CTU=64 would be more useful?

[HD MOVIE SOURCE]

I have seen --ctu 32 provide better quality with very grainy content at 4K and HD resolutions.

I noticed that --hme has some settings that goes with it.

--hme-search between 0,1,2. Is 2 the best? / Highest setting?

--hme-range between 0,1,2. Same question.

Is 2 for both settings maxed out?

[benwaggoner]

Thats interesting. Does CTU=32 typically cost more bit-rate to use than CT=64? Is CTU=64, typically better for animation with plain objects, like plain skies, where CTU=64 would be more useful?
Yes, its main value is increased compression efficiency for big flatter/gradient areas. It's not a big improvement; 32x32 is already much bigger than prior codecs supported.

[benwaggoner]

I noticed that --hme has some settings that goes with it.

--hme-search between 0,1,2. Is 2 the best? / Highest setting?

--hme-range between 0,1,2. Same question.

Is 2 for both settings maxed out?
The are documented here: https://x265.readthedocs.io/en/master/cli.html#temporal-motion-search-options

--hme-search is 0-5, just replicating the --me options.
--hme-range replicates --merange, and so can be anything from 0 to 32768

[HD MOVIE SOURCE]

The are documented here: https://x265.readthedocs.io/en/master/cli.html#temporal-motion-search-options

--hme-search is 0-5, just replicating the --me options.
--hme-range replicates --merange, and so can be anything from 0 to 32768

I appreciate it thanks. Have you experimented with any specific settings here? Are the defaults more than fine?

Is search best at 5, but say, the hme range to follow whichever settings you use for merange? Which for me is 57.

[benwaggoner]

I appreciate it thanks. Have you experimented with any specific settings here? Are the defaults more than fine?

Is search best at 5, but say, the hme range to follow whichever settings you use for merange? Which for me is 57.
I've not found any material quality or performance benefit form using --hme instead of not. x265 doesn't seem to be doing frame or GOP level parallelism for the different sizes, so practical speed benefits are a real challenge. I believe the engineering was more focused on the UHDKit product's ability to simultaneously encode, for example, a 540p, 1080p, and 2160p with each higher resolution reusing the motion search of the prior resolution, and getting parallelism from that.

I can see some combination of coarser --me with a wider net (note that 24 px at the 25% size would be 96 px in the final frame) search range for the lower resolutions, and a more precise me with a smaller search range at the higher makes intuitive sense as a potential quality/speed tradeoff improvement. I've not dived deep to try and find that combination, however.

There was some early talk from MCW some years ago that --hme would help improve quality with very grainy content, as the low pass filtering of the downscales would exclude false positive motion vectors resulting from random grain matches, with the full resolution pass refining on the initial matches. Which makes intuitive sense, but I never saw an actual PoC of this benefit.

I didn't find any benefit in a couple of rounds of initial testing. It's on my backlog of things to noodle with further time permitting.

[HD MOVIE SOURCE]

I've not found any material quality or performance benefit form using --hme instead of not. x265 doesn't seem to be doing frame or GOP level parallelism for the different sizes, so practical speed benefits are a real challenge. I believe the engineering was more focused on the UHDKit product's ability to simultaneously encode, for example, a 540p, 1080p, and 2160p with each higher resolution reusing the motion search of the prior resolution, and getting parallelism from that.

I can see some combination of coarser --me with a wider net (note that 24 px at the 25% size would be 96 px in the final frame) search range for the lower resolutions, and a more precise me with a smaller search range at the higher makes intuitive sense as a potential quality/speed tradeoff improvement. I've not dived deep to try and find that combination, however.

There was some early talk from MCW some years ago that --hme would help improve quality with very grainy content, as the low pass filtering of the downscales would exclude false positive motion vectors resulting from random grain matches, with the full resolution pass refining on the initial matches. Which makes intuitive sense, but I never saw an actual PoC of this benefit.

I didn't find any benefit in a couple of rounds of initial testing. It's on my backlog of things to noodle with further time permitting.

Interesting, thanks.

[HD MOVIE SOURCE]

I've not found any material quality or performance benefit form using --hme instead of not. x265 doesn't seem to be doing frame or GOP level parallelism for the different sizes, so practical speed benefits are a real challenge. I believe the engineering was more focused on the UHDKit product's ability to simultaneously encode, for example, a 540p, 1080p, and 2160p with each higher resolution reusing the motion search of the prior resolution, and getting parallelism from that.

I can see some combination of coarser --me with a wider net (note that 24 px at the 25% size would be 96 px in the final frame) search range for the lower resolutions, and a more precise me with a smaller search range at the higher makes intuitive sense as a potential quality/speed tradeoff improvement. I've not dived deep to try and find that combination, however.

There was some early talk from MCW some years ago that --hme would help improve quality with very grainy content, as the low pass filtering of the downscales would exclude false positive motion vectors resulting from random grain matches, with the full resolution pass refining on the initial matches. Which makes intuitive sense, but I never saw an actual PoC of this benefit.

I didn't find any benefit in a couple of rounds of initial testing. It's on my backlog of things to noodle with further time permitting.

One thing I've noticed, and I think it's when I started using hme, and that's...Even when I set my encoder to placebo, me=2 gets set to 2 and I believe placebo should be set to 5. merange=48 gets set to 48 and placebo is 92.

I re-encoded with me=5 and that got set fine. However, I set merange to the default of 57 and it still gets set to 48. Is hme controlling this?

[microchip8]

One thing I've noticed, and I think it's when I started using hme, and that's...Even when I set my encoder to placebo, me=2 gets set to 2 and I believe placebo should be set to 5. merange=48 gets set to 48 and placebo is 92.

I re-encoded with me=5 and that got set fine. However, I set merange to the default of 57 and it still gets set to 48. Is hme controlling this?

hme has its own search radius, which you can set using --hme-range

[HD MOVIE SOURCE]

hme has its own search radius, which you can set using --hme-range

Okay, thank you. I haven't had much experience with this so I'm still learning how hme affects other settings. Thanks

[benwaggoner]

One thing I've noticed, and I think it's when I started using hme, and that's...Even when I set my encoder to placebo, me=2 gets set to 2 and I believe placebo should be set to 5. merange=48 gets set to 48 and placebo is 92.

I re-encoded with me=5 and that got set fine. However, I set merange to the default of 57 and it still gets set to 48. Is hme controlling this?
When you're using --hme, the --hme-search and --hme-range override --me and --me-range. So --preset has no impact on those.

To get a "placebo" --hme, you'd probably use

--hme-search 3,3,3 --hme-range 92,92,92

it's the last digit of each that's most important, as those are for the full resolution final pass. I imagine that

--hme-search 2,2,3 --hme-range 57,57,92

Would give you essentially equal results.

I don't think that --hme would offer much benefit at all in placebo. To get a better speed-quality benefit, something like the below would be more likely to be net beneficial. HME techniques are generally about improving quality @ speed, not maximum quality when not speed bound.

--hme-search 2,2,3 --hme-range 25,25,26

Where the motion search range can be constrained for the higher resolution passes as the coarser stages were able to identify good matches to refine in the later stages. a 25 range at quarter resolution maps to 100 at the final resolution.

(25 constrains motion search to 32x32 in hex, as does 26 to 32x32 in star. That allows another 32x32 row to be parallelized in WPP versus higher values).

[HD MOVIE SOURCE]

When you're using --hme, the --hme-search and --hme-range override --me and --me-range. So --preset has no impact on those.

To get a "placebo" --hme, you'd probably use

--hme-search 3,3,3 --hme-range 92,92,92

it's the last digit of each that's most important, as those are for the full resolution final pass. I imagine that

--hme-search 2,2,3 --hme-range 57,57,92

Would give you essentially equal results.

I don't think that --hme would offer much benefit at all in placebo. To get a better speed-quality benefit, something like the below would be more likely to be net beneficial. HME techniques are generally about improving quality @ speed, not maximum quality when not speed bound.

--hme-search 2,2,3 --hme-range 25,25,26

Where the motion search range can be constrained for the higher resolution passes as the coarser stages were able to identify good matches to refine in the later stages. a 25 range at quarter resolution maps to 100 at the final resolution.

(25 constrains motion search to 32x32 in hex, as does 26 to 32x32 in star. That allows another 32x32 row to be parallelized in WPP versus higher values).

I really appreciate the explanation on this, because I've been testing some search and range settings for hme and my encodes have been crashing. Now, you've provided the command lines to be more understandable I'll give them a try.

I've recently been testing placebo vs straight hme, and hme gave me 0.1 QP average QP more than not using it vs placebo that then uses me=5 and 92 for the merange.
Interestingly enough the hme encode was faster than placebo when just stating hme, and not stating the range or search values. So, I think you might be right that under placebo it may not be needed. However, now knowing what I can change, I might be able to eek more out of it, LOL.

Placebo with no hme = Job completed (Elapsed Time: 8h 16m)
Placebo with basic hme turned on = Job completed (Elapsed Time: 7h 09m)

Placebo with no hme average QP= Avg QP:8.74
Placebo with basic hme turned on = Avg QP:8.73

So, unless you can tune hme significantly with the settings you said
--hme-search 3,3,3 --hme-range 92,92,92, maybe there's some more quality to be gained? But, I assume you'd lose speed with these settings vs the default which is 16,32,48 for the range, but I'm not sure what for the search.

My media info says hme / Level / merange / L0,L1,L2=16,32,48, which is me just stating hme in the command line. I did a search for hme-search and that isn't there. I assume that you have to manually state that?

The big this is, is there a visual difference when using hme vs not using it when using placebo? Also, I wonder when the speed crosses over? Meaning, I wonder which preset hme becomes slower? Because the merange is always 57 on every other preset. If hme-range is the equivalent and by default only goes to 48, is hme always better to use?

hme-range <integer>,<integer>,<integer> is the last number the most important number? Does the first and second number matter if they are lower-resolution searches?

Thanks.

[microchip8]

If you're encoding Full HD or lower, I wouldn't bother with HME.

[benwaggoner]

My media info says hme / Level / merange / L0,L1,L2=16,32,48, which is me just stating hme in the command line. I did a search for hme-search and that isn't there. I assume that you have to manually state that?
It's the same values as --me and --me-range, so

--hme-search:
0: dia
1: hex (default)
2: umh
3: star
4: sea
5: full

Thus the default search modes for HME are Dia for 1/4 res, Hex for 1/2 res, and UMH for full res. --preset placebo uses 3: Star. So for placebo-equivalent you'd want at least the third --hme-search value to be 3.

The big this is, is there a visual difference when using hme vs not using it when using placebo? Also, I wonder when the speed crosses over? Meaning, I wonder which preset hme becomes slower? Because the merange is always 57 on every other preset. If hme-range is the equivalent and by default only goes to 48, is hme always better to use?
You can always use --me 48. But the key goal of a HME algorithm is that you can do an initial coarse search at a lower resolution, and then refine with more accuracy but smaller search range as the resolutions go up. So, in theory, a --me 92 gets handled by having the first motion search range be 92/4=23. There are intricacies between search modes and such, but that's the basic idea.

hme-range <integer>,<integer>,<integer> is the last number the most important number? Does the first and second number matter if they are lower-resolution searches?

I'm not sure which number is the most "important" - it gets down to finding the right combination of quality, speed.

Sure --hme-search 3,3,3 --hme-range 24, 48, 92 should match placebo quality, but I don't know that it would look better than placebo, or that it would save any encoding time.

[N'Cha]

[QUOTE=HD MOVIE SOURCE;1975282]Hi,

I'm looking to find settings that increase detail and sharpness. In turn, I'm also looking for settings that apply blurring or softness and can be turned off.

Here are the settings that I know of so far that do this.

subme=7 (A sharpener, detail increase)
no-deblock / deblock (Blurring/detail loss the more deblock is used)
no-sao / sao (High Blur)
no-strong-intra-smoothing / strong-intra-smoothing (Smoother/Blur)
psy-rd=-- & psy-rdoq=-- rdoq-level=-- (Detail increase as the cost of accuracy - Can look over-digital)

I am unaware of any evidence that --strong-intra-smoothing reduces visible detail in any scenario.
Nor does --deblock if used appropriately. Both will reduce detail at moderate-low bitrates, as they reduce compression efficiency and drive QPs higher, which itself is a low-pass filter. The HEVC built-in deblocking filter is better turned than H.264's.

--subme only goes up to 5 in --preset placebo. I've not seen visible quality improvements from using higher values.

If you have sharp synthetic details (text, line art, noise-free anime), --tskip can increase detail.

In theory --hme can help with very noisy content.
--amp and --rect can improve detail by allowing TUs to better match the shape of content, for example encoding a mild horizontal curve as 32x8 instead of forcing it to be square.

But in general, a lot of these things are controlled by the preset. It's best to pick the slowest preset that is fast enough, and start tweaking from there.


That "blurrs" differences in QP to reduce quality fluctuations. It has no direct impact on sharpness.


I'd start doing a test encode at --preset slower --crf 18 --no-sao and see if the detail retention and file size are okay for you. If not, tweak from there. Jumping in with parameters without having some reference encodes to compare with the source and each other makes for a lot more work.Is it still your opinion that subme 7 is not sharper/more detailed than subme 5 ? (especially for anime)

[benwaggoner]

Is it still your opinion that subme 7 is not sharper/more detailed than subme 5 ? (especially for anime)
I haven't tested this is many years, but I'm not aware of any changes that could make a difference. MCW's testing showed that --subme 7 wasn't even worth using in --preset placebo.

If anyone has more recent or specific results, I'd love to hear about them!

[brad86]

Recently found a good balance of settings and quality I would like for my encodes, except for one issues that I can not seem to fix.
I'm getting a great image overall with these settings, other than blurring near the top of the canvas. It's like it doesn't know how to handle the edge very well.
I would love to find a setting that can stop this. A lower CRF value (even 0 for testing) does not stop it. aq-strength, is really the only tweak I make between different films (1.0-1.3), but again, even a high value here does not help.

You can see the issue I'm having below.

https://i.ibb.co/qsSjqs0/mpv-shot0001.jpg

My settings current settings are;
10-bit. CRF 17. Slow preset.
selective-sao=2:no-strong-intra-smoothing:rskip=2:rskip-edge-threshold=3:aq-mode=3:aq-strength=1.2:deblock=-3:-3

[Boulder]

Borders cropped off before encoding? Mod-8/16 vertical resolution?

[brad86]

Borders cropped off before encoding? Mod-8/16 vertical resolution?

No cropping. I despise doing such a thing. It is as it is on my disc.

[Boulder]

Well, why not try cropping and see what happens. Your player will definitely add them back during playback and you'll save a few bits too.

[brad86]

Well, why not try cropping and see what happens. Your player will definitely add them back during playback and you'll save a few bits too.

Same result. It blurs near the top edge.

[Boulder]

Hmm.. some things to test would be changing CTU to 32 (or 16 just for debugging) and cropping the border so that the actual active image area would not share a CTU with the border.

Also make sure that it's not a decoder related thing, because we've seen something similar at the bottom of the frame with Amlogic chips when the vertical resolution is not mod-8.

[brad86]

Sadly, no go with the CTU change. It changes the position of the blur somewhat, but it's still visible and not decreased.

Removing the boarders is something I will always avoid. Not everything plays nicely when you do this. My 2023 Sony TV has very good scaling, but it has to be fed normal resolutions, or it will not scale, and instead defaulting to a simple bilinear method. I want to keep a native 4K resolution.

[Boulder]

Removing the boarders is something I will always avoid. Not everything plays nicely when you do this. My 2023 Sony TV has very good scaling, but it has to be fed normal resolutions, or it will not scale, and instead defaulting to a simple bilinear method. I want to keep a native 4K resolution.

That is quite odd behaviour, I have a 2019 Sony (XF9005) and I've not noticed any difference between feeding a 1920x800 or 1920x1080 source to the TV from the media player.

Is there some discussion regarding this somewhere?

[brad86]

That is quite odd behaviour, I have a 2019 Sony (XF9005) and I've not noticed any difference between feeding a 1920x800 or 1920x1080 source to the TV from the media player.

Is there some discussion regarding this somewhere?

Not that I am aware of. I enabled developer option within the android settings and have a resource overlay. MPV would be an easier way to see everything.

I have just switched to Slower preset whilst keeping the parameters I already had for Slow preset. It has absolutely helped removed most of the blocking I was seeing at the edge.

Encoding time has now skyrocketed, as expected. Would love to know which setting within Slower is helping solve it, so I can just use that along with the Slow preset.

[Boulder]

Not that I am aware of. I enabled developer option within the android settings and have a resource overlay. MPV would be an easier way to see everything.

I have just switched to Slower preset whilst keeping the parameters I already had for Slow preset. It has absolutely helped removed most of the blocking I was seeing at the edge.

Encoding time has now skyrocketed, as expected. Would love to know which setting within Slower is helping solve it, so I can just use that along with the Slow preset.

My guess is that it's --amp. I almost proposed checking if it's enabled in the encode, but figured that Slow would probably have both --rect and --amp. So that one allows to split the CTU into asymmetric parts which most likely helps there.

[brad86]

My guess is that it's --amp. I almost proposed checking if it's enabled in the encode, but figured that Slow would probably have both --rect and --amp. So that one allows to split the CTU into asymmetric parts which most likely helps there.

Unless I am adding the parameter incorrectly. :amp does not seem to be the fix. Another setting within Slower that is fixing it.

selective-sao=2:no-strong-intra-smoothing:rskip=2:rskip-edge-threshold=3:aq-mode=3:aq-strength=1.3:deblock=-3:-3:amp

[Boulder]

You can see and compare the presets here: https://x265.readthedocs.io/en/master/presets.html.

[brad86]

You can see and compare the presets here: https://x265.readthedocs.io/en/master/presets.html.

That should be very helpful. Thanks :)

[benwaggoner]

That is quite odd behaviour, I have a 2019 Sony (XF9005) and I've not noticed any difference between feeding a 1920x800 or 1920x1080 source to the TV from the media player.

Is there some discussion regarding this somewhere?
Yeah, also works fine for me on my 2017 and 2023 Sony TVs.

Making sure the Sample Aspect Ratio is set correctly (probably 1:1 in your case) possibly can help.

[brad86]

Happy days. Changing rd=4 to rd=6 has fixed it.

Although, encoding time has doubled. It is what it is, though.

[benwaggoner]

Happy days. Changing rd=4 to rd=6 has fixed it.

Although, encoding time has doubled. It is what it is, though.
Huh! I wouldn't have guessed that would be the magic knob.

Anyone have any theories as to why?

[brad86]

I can't figure why the higher RD level fixed the issue. Maybe some other parameters were not active unless RD was above 4 ?

I currently have it on 5, but it does add 2-3 hours to any encode. Finding the specific setting would be good, so I can get back that lower encoding time.

I went through all the preset parameters table, and still couldn't find what does it.

[Boulder]

I can't figure why the higher RD level fixed the issue. Maybe some other parameters were not active unless RD was above 4 ?

I currently have it on 5, but it does add 2-3 hours to any encode. Finding the specific setting would be good, so I can get back that lower encoding time.

I went through all the preset parameters table, and still couldn't find what does it.

A higher value just adds more decision-making which naturally means slower encodes. By the way, 5 and 6 are the same.
I don't know if it also affects the decisions made by psychovisual settings (psy-rd, psy-rdoq), but at least it doesn't enable any other settings that you can do manually using parameters.

[benwaggoner]

A higher value just adds more decision-making which naturally means slower encodes. By the way, 5 and 6 are the same.
I don't know if it also affects the decisions made by psychovisual settings (psy-rd, psy-rdoq), but at least it doesn't enable any other settings that you can do manually using parameters.
--rd 6 can change psychovisual aspect for sure. I've seen a number of grainy UHD HDR sources where --rd 4 looked better than --rd 6.

I remember having a good theory about why that was, but I don't remember the theory ;).

[brad86]

It's a weird one. From the encodes I have been doing, it appears that 1080p videos are perfectly fine with rd 4, but if I do anything 4K with the exact same settings used for 1080, I need to increase rd to 5 or I start to get strange artefacts, and not always what was in my initial post. They seem to vary. A common one is small seems/lines, or the odd block which looks like if compression were to miss a few pixels. This is the case with SDR video, or when passing through HDR data for the encode.

[benwaggoner]

It's a weird one. From the encodes I have been doing, it appears that 1080p videos are perfectly fine with rd 4, but if I do anything 4K with the exact same settings used for 1080, I need to increase rd to 5 or I start to get strange artefacts, and not always what was in my initial post. They seem to vary. A common one is small seems/lines, or the odd block which looks like if compression were to miss a few pixels. This is the case with SDR video, or when passing through HDR data for the encode.
Yeah, without much grain rd 6 is better, with a lot of grain rd 4 is better. It's possible a lot of other parameter tuning could make rd 6 more viable with grain, but I've not found a magic formula yet.