Log in

View Full Version : Which settings would be best here?


tyler durdan
17th October 2022, 00:09
Hi,

I have just started encoding 2160p UHDs and was wondering which setting below may be closest to transparent please?

H265 CRF 18 Preset Very Fast
H265 CRF 20 Preset Medium
H265 CRF 22 Preset Slow

I know that CRF 18 & Preset Slow is no doubt the best but it will
take 2 days on my machine so I need to compromise

I wouldn't have thought that the Very Fast preset was any good but
I have read a few threads where some individuals swear by it.

Also is no sao required in this case?

Any advise would be much appreciated?

Thanks

benwaggoner
18th October 2022, 19:38
I have just started encoding 2160p UHDs and was wondering which setting below may be closest to transparent please?

H265 CRF 18 Preset Very Fast
H265 CRF 20 Preset Medium
H265 CRF 22 Preset Slow

I know that CRF 18 & Preset Slow is no doubt the best but it will
take 2 days on my machine so I need to compromise

I wouldn't have thought that the Very Fast preset was any good but
I have read a few threads where some individuals swear by it.
All presets converge in quality with enough bits. 4 CRF is a lot, so CRF 18 --preset veryfast may well yield the best quality, although requiring a whole lot more bits. That said, other processes can bottleneck, and you might (or might not) find that --preset faster isn't that much slower.

Also is no sao required in this case?
SAO detail loss is per-pixel, so the more pixels the less of a concern it has. I think it would be a net benefit to quality in your three examples.

If you do use SAO, I recommend -selective-sao 2 as an essentially free speedup when using SAO that should be the default.

tormento
20th October 2022, 11:54
If you do use SAO, I recommend -selective-sao 2 as an essentially free speedup when using SAO that should be the default.
Isn't selective-sao including sao too? Ooops.

benwaggoner
20th October 2022, 19:35
Isn't selective-sao including sao too? Ooops.
Yeah, you shouldn't use it if you don't want to use SAO!

Still, for most 4K content at distribution bitrates, SAO is a net positive. --no-sao only really starts to benefit when QP's are below 20. SAO is in effect a deringing filter, so if there is visible ringing, use SAO.

Boulder
21st October 2022, 06:47
Since x265's SAO tends to blur the image, won't it hurt the overall quality if the referenced I- and particularly P-frames are rather blurry compared to the original frame? I've tested --selective-sao 2 earlier but it does change the P-frames quite a lot, I-frames are not affected that much.

benwaggoner
22nd October 2022, 00:38
Since x265's SAO tends to blur the image, won't it hurt the overall quality if the referenced I- and particularly P-frames are rather blurry compared to the original frame? I've tested --selective-sao 2 earlier but it does change the P-frames quite a lot, I-frames are not affected that much.
The blurring effect is at the pixel level, so the bigger the frame size, the less impact it has.

Yes, if you're encoding where QPs are pretty consistently below 20 and have no visible artifacts, --no-sao might increase detail some.

If you're encoding where QPs are high enough to cause visible ringing or other artifacts, you'll almost always be better off using --sao.

tormento
22nd October 2022, 09:34
Yeah, you shouldn't use it if you don't want to use SAO!
What should I use for 1080p modern (read: with almost no grain if not digitally added) anime with crf 20 or higher (not much higher, up to 16 in the worst cases).

My current line is something like:

--crf 20÷16 --preset slower÷slow --output-depth 10 --limit-tu 4 --tu-intra-depth 4 --tu-inter-depth 4 --rect --amp --tskip --aq-mode 5 (--hme when really grainy) --rc-lookahead 60 --lookahead-threads 4 --gop-lookahead 23 --min-keyint 24 --keyint 120 --fades --hist-scenecut --colorprim bt709 --colormatrix bt709 --transfer bt709 --range limited --limit-sao --selective-sao 2 --sao-non-deblock

I know that every video "has its own life" but I'd like a generic line to start from. Any hint is welcome.

benwaggoner
23rd October 2022, 00:12
What should I use for 1080p modern (read: with almost no grain if not digitally added) anime with crf 20 or higher (not much higher, up to 16 in the worst cases).

My current line is something like:

--crf 20÷16 --preset slower÷slow --output-depth 10 --limit-tu 4 --tu-intra-depth 4 --tu-inter-depth 4 --rect --amp --tskip --aq-mode 5 (--hme when really grainy) --rc-lookahead 60 --lookahead-threads 4 --gop-lookahead 23 --min-keyint 24 --keyint 120 --fades --hist-scenecut --colorprim bt709 --colormatrix bt709 --transfer bt709 --range limited --limit-sao --selective-sao 2 --sao-non-deblock.
Have you tried --tune animation --preset slower as a starting point? Tune animation sets:

--psy-rd 0.4
--aq-strength 0.4
--deblock 1:1
--bframes Increase by 2


--limit-sao and particularly --sao-non-deblock seem like odd choices for what's a more quality-tuned preset. Have you seen visual improvements using them?

What is --aq-mode 5?
Have you found net benefit from --fades or --hist-scenecut? I've never really seen it do anything beneficial.
And from --hme? I could see it being more helpful with animation.
--gop-lookahead isn't something that gets used with file-based playback. There's a specific live scenario it is for that I cannot quite recall the specifics of.

tormento
23rd October 2022, 09:36
Have you tried --tune animation --preset slower as a starting point?
AFAIK --tune animation is for pure lineart, Tom & Jerry style, cartoons. Nothing as fancy as gradients, digitally added noise, solarized real footage and so, such in modern animes.
Have you seen visual improvements using them?
Unfortunately, in anime scene, there is a lot of "it's like that since ages". Some parameters are written in stone. That's why I am asking help to improve the command line.
What is --aq-mode 5?
It enables auto variance, edge information and bias to dark scenes. It's a patch present only in a few builds, such as djatom and patman ones.
And from --hme? I could see it being more helpful with animation.
It's really useful to keep digital noise and in fast panning sequences. As I said, it's a last resource setting, as it slows down everything.
--gop-lookahead isn't something that gets used with file-based playback.
What do you mean with file-based playback? Isn't the usual thing that we do when playing a file? :confused:

As most of the anime are 720p (or stranger resolutions) upscaled to 1080p, I have the necessity to preserve the fine details, for a future when I will have the hardware power to propertly rescale it with RESGAN or similar. I had the idea to downscale to original resolution and THEN encode but it would introduce more artifacts when upscaling later. Or not?

benwaggoner
24th October 2022, 02:22
AFAIK --tune animation is for pure lineart, Tom & Jerry style, cartoons. Nothing as fancy as gradients, digitally added noise, solarized real footage and so, such in modern animes.]/QUOTE]
Ah, yeah, the more the title diverges from classic cel animation, the less suitable --tune animation is. Still, can be worth a test.

[QUOTE]It enables auto variance, edge information and bias to dark scenes. It's a patch present only in a few builds, such as djatom and patman ones.
Interesting. I've not experimented with it myself.

It's really useful to keep digital noise and in fast panning sequences. As I said, it's a last resource setting, as it slows down everything.
Good, that's what it should be good for if anything.

What do you mean with file-based playback? Isn't the usual thing that we do when playing a file? :confused:
File-based like off a NAS or hard drive. Not for adaptive streaming or Blu-ray.

As most of the anime are 720p (or stranger resolutions) upscaled to 1080p, I have the necessity to preserve the fine details, for a future when I will have the hardware power to propertly rescale it with RESGAN or similar. I had the idea to downscale to original resolution and THEN encode but it would introduce more artifacts when upscaling later. Or not?
Unless you've got a really good anime-tuned upscaler, you're generally better off encoding at the source resolution with a lower CRF. You can get better net quality at low or moderate bitrates.

tormento
24th October 2022, 11:00
Interesting. I've not experimented with it myself.
Please share your findings.
File-based like off a NAS or hard drive. Not for adaptive streaming or Blu-ray.
I don't plan to burn my encodes. Is there any advantage to use BD compliant parameters?
you're generally better off encoding at the source resolution
With "source" you mean the BD file (fake 1080p) or the native lower resolution?

benwaggoner
28th October 2022, 20:14
I don't plan to burn my encodes. Is there any advantage to use BD compliant parameters?
The only advantage of BD compliant parameters is that's the only way to burn to a BD disc. The constraints themselves reduce compression efficiency quite a bit, which is one reason BD needs those high peak bitrates. Don't use them unless you need to burn a disc.

With "source" you mean the BD file (fake 1080p) or the native lower resolution?
The source is the earliest-generation file you have available, which sounds like it was 720p.

There are times where a really good upscale can yield an actually better source. After all, sufficiently advanced preprocessing becomes indistinguishable from remastering. So there's not a hard rule of thumb that it's never a good idea. But if bitrates or encoding time are a constraint at 1080p, using the source resolution and letting the device scale makes good sense. And all sorts of devices are getting ever-better machine learning based superresolution upscalers which can produce very impressive results.

It's not like the old days where we had to expect bilinear playback upscaling at best. Heck, early in my career, nearest neighbor would be the default, and there were all sorts of tips and tricks to avoid that. Sometimes there was a fast path where exactly 2x scaling would be bilinear, for example. For full-screen video, we'd automatically change the monitor resolution to that of the content to avoid scaling.

tormento
30th October 2022, 10:52
The source is the earliest-generation file you have available, which sounds like it was 720p.
Unfortunately the trend is to upscale with bicubic to 1080p, so it's really hard to find a "original" resolution source. Picture that anime can have really strange resolutions, because of the habit of overscanning, such as 888p or 896p and so.

My doubt, therefore, is if to downscale to original resolution and crank CRF a bit lower or keep the badly upscaled one and encode with the usual CRF.

I can't get an idea of what is better.

Do you think we get more loss encoding a lower resolution with higher CRF (and let hardware do the upscaling while playing) or keep the bicubic resample? This also in a future (remote, considering how much video cards cost now) possibility to apply expert systems on tensor cores and create a much better 1080p video.

benwaggoner
31st October 2022, 03:43
Unfortunately the trend is to upscale with bicubic to 1080p, so it's really hard to find a "original" resolution source. Picture that anime can have really strange resolutions, because of the habit of overscanning, such as 888p or 896p and so.

My doubt, therefore, is if to downscale to original resolution and crank CRF a bit lower or keep the badly upscaled one and encode with the usual CRF.

I can't get an idea of what is better.

Do you think we get more loss encoding a lower resolution with higher CRF (and let hardware do the upscaling while playing) or keep the bicubic resample? This also in a future (remote, considering how much video cards cost now) possibility to apply expert systems on tensor cores and create a much better 1080p video.
If it's already been scaled up well, you're okay. Although I'm a little surprised they'd not use something more advanced or anime-tuned than bicubic.