Any advice on --tune grain ?

[blublub]

You may see some benefit to rd 5. You're also a lot closer to your TV than I am. :)

hu, I gotta admit that rd 5 is a real performance killer. Drops like 20-30% fps for encoding and thats well below my target speed. So I will stick to CRF 17.

[blublub]

You may see some benefit to rd 5. You're also a lot closer to your TV than I am. :)Hi

I am now done re-encoding almost all if my BluRays with x265.
Now I think about doing this again with some DVDs - are there an setting I should change for DVDs despite rd=5 , in especially I thought of CTU an d me size.

[TB54]

I find this thread two years later, having the same trouble as described here: the "grain" tune seems to *add* grain (while the "none" tube is too smooth, not enough texture). I would love to find something between the two tunes, but being a hard newbie to this, i could use some help if you have time for it!

I've seen some code propositions here, but as i like the precision of the "grain" tune (besides its too grainy look), i wonder if there is not just one property to change in it for it to work well.

The h265 readocs (https://x265.readthedocs.io/en/latest/presets.html#film-grain) tell that film grain is all that:


--aq-mode 0
--cutree 0
--ipratio 1.1
--pbratio 1.0
--qpstep 1
--sao 0
--psy-rd 4.0
--psy-rdoq 10.0
--recursion-skip 0

For those who know how to read that (it's chinese to me, and i have difficulties to understand the impact of each property even by reading the descriptions...), do you know which one I have to change to just tame a little the grain intensity, while keeping the general look of it?

There is an "advanced option" in handbrake (https://i.imgur.com/PY36iNu.jpeg) in which i suppose i could put this code modified, after choosing a "none" tune...

For now the only easy solution I have to tame grain without deleting it completely seems to be using a medium preset (instead of slow), but quality suffers from it...

[Boulder]

I would try adjusting the psy options down, they affect how much blurring x265 applies. Change one at a time and see what happens.

[TB54]

Thanks, i will start with that, i come back to you if i find a good preset!

[excellentswordfight]

Thanks, i will start with that, i come back to you if i find a good preset!
I would start with adding --no-sao --deblock -1,-1, that usually does a rather good job to keep more detail/grain. aq-mode 1 can also be worth trying for encodes were quality is prioritized heavier then compression rather then the default method (2).

Other then that, as Boulder said, psy is what you want to tweak if you are still unhappy with how it handles high-frequency detail. And preset 'slow' is otherwise a rather good starting point so you probably want to keep that as a base. Using 10bit (main10) if you are not already can also be worth exploring.

[TB54]

Thanks to you two!

I've tried several combinations with the leads you proposed, but for now, if it helps to reduce grain, it creates some problems (i have a close-up of a quick moving face on the clip i use to test all that, and whatever the thing i change myself in the code, the compression shows/appear on the face at this moment)... Still trying things.

Do you have a personal code you apply whatever you encode? Maybe it will work better than trying to modify the grain tune myself...

Using 10bit (main10) if you are not already can also be worth exploring.

I realized that on "Roma" (black and white, no grain): whatever the bitrate chosen, it was the only way to make banding disappear on surfaces. But doesn't make files much bigger?

[Forteen88]

I realized that on "Roma" (black and white, no grain): whatever the bitrate chosen, it was the only way to make banding disappear on surfaces. But doesn't make files much bigger?Use should read this,
https://forum.doom9.org/showthread.php?p=1923339#post1923339

[excellentswordfight]

Do you have a personal code you apply whatever you encode? Maybe it will work better than trying to modify the grain tune myself...

Just to make sure, are you still using tune grain? As mentioned in this thread, that preset is not really recommended for general use, my post was under the context that tune grain was not in use.

So start just with the basics: --preset slow --profile main10 --no-sao --deblock -1:-1 and go from there.

This is what i personally use as default for 1080p SDR encodes:

--preset slow --profile main10 --level-idc 41 --crf 18 --keyint 240 --min-keyint 24 --rc-lookahead 48 --no-sao --deblock -1:-1 --colorprim bt709 --transfer bt709 --colormatrix bt709 --range limited

This is by no means settings to retain a great amount of noise mind you, more in the line of keeping a decent amount of details at a rather high compression level. For 1080p, if grain retention is very important I rather save my computer some work and use x264 as the compression differens at that point is imo not worth the CPU cycles needed to achive that with x265.
I realized that on "Roma" (black and white, no grain): whatever the bitrate chosen, it was the only way to make banding disappear on surfaces. But doesn't make files much bigger?
Well not sure how it effects bitrate at given crf level, but the short answer is no.

As you can see in the screenshots in this post I made, using main10 gives some interesting results at the same bitrate, and as you said, it can also prevent stuff like banding.

https://forum.doom9.org/showthread.php?p=1922398#post1922398

edit.
Adding some samples (screenshots are upscaled to 2160p and cropped back down to 1080p)

Original (ToS transcoded to x264 25Mbps Bluray-compatable with preset veryslow and tune film):
https://ibb.co/S0C9hcQ

x265 with the settings above:
https://ibb.co/tzyX4tH

x264 with preset veryslow and tune film (crf 18.8 to match the ~7Mbps from the encode above):
https://ibb.co/6g5TD8f

Altough motion is really key to evaluate grain and high-frequency details, as can be seen on the screenshots, x265 does a rather good job of keeping most of it intact with those settings, while x264 is clearly out of bits to keep up and is blocking and adding flat spots.

[benwaggoner]

Yeah, --tune-grain was designed to get around pretty early x265 limitations. The amount of grain that the default settings can handle has gone up a LOT. What tune grain does, in essence, is turn off the stuff that save bits from varying QP inside and between frames. It winds up being a relatively fixed-QP encode. Last I tried, using --tune-grain for content that didn't need it increased bitrate around 50% versus defaults at the same subjective quality.

Today, in general, any content that needs --tune grain throughout is pretty painful to watch even pre-compression. Its best use would be on individual shots/scenes with lots of grain for style reasons. The titles that are SO grainy as to need it overall are typically 4K remasters of so-so film masters (often Super 35) that got rescanned at high resolution and had all the grain left in. This is often justified as "creative intent" - but those titles were always shown on a perf screen at maybe 48 nits. None of the creatives EVER saw all that grain when making that film!

Another grain tip: try --hme. Since grain is high frequency randomization, it tends to get averaged out when scaling down. Encoding 1920x1080 in HME means analyzing at 480x270 first, then refining at 960x540, then finally at 1920x1080. The motion vectors that get obscured with high grain at full rez are much easier to find at the lower resolutions, and then get retained with refinement.

[Emulgator]

Many thanks for that idea !

[benwaggoner]

Many thanks for that idea !
Let us know if it helps!

[TB54]

Yes, sorry everyone, i have been pretty busy and not able to test serioulsy (with all the variations, differents settings...) the last suggestions, but I will come to it as soon as I have time!

[TB54]

Another grain tip: try --hme.
Just this code alone, or followed by a number? It makes handbrake crash if just put it alone in the advanced dialog boxed.

Thanks for all the suggestions, i tried everything, but still don't have a satisfying result (at least if i want to stay around 7Mb/s on the final 720p file).

If anyone wants to try his own solution, here is the very grainy test clip i use in ProResHQ (i know most of sources won't be as grainy as that, but with it I can see more clearly the problem I encounter in a milder way with every other sources): https://we.tl/t-Maamur6Wzm


TO SUM THIS UP (with comparison slides, which don't seem to display on chrome weirdly)...

- If i try h265 "grain", detail is preserved, but the grain is more present/harsher, which in movement makes the movie clip difficult to watch: https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=f49cf784-2c5b-11eb-83c8-ebb5d6f907df

- If i try h265 "none", detail disappear, and it makes a porridge-image on the face movements: https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=30220358-2c5c-11eb-83c8-ebb5d6f907df

- Weirdly, the closest to source image (the right amount of grain while preserving some detail) is obtained using h264 "grain": https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=57919c8c-2c5c-11eb-83c8-ebb5d6f907df

... but it doesn't do well on every shot (see the blocks around the guy on this large shot, or his face - you can see the problem more clearly in motion, on the little h264 excerpt I put in the wetansfer): https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=f6debe68-2c5d-11eb-83c8-ebb5d6f907df

If anyone wants to play with it, you're more than welcome, but anyway it is an occasion for newcomers to show the effect of each tune. Thanks again all for your help, and sorry to the long answer delay!

[excellentswordfight]

Just this code alone, or followed by a number? It makes handbrake crash if just put it alone in the advanced dialog boxed.

Thanks for all the suggestions, i tried everything, but still don't have a satisfying result (at least if i want to stay around 7Mb/s on the final 720p file).

If anyone wants to try his own solution, here is the very grainy test clip i use in ProResHQ (i know most of sources won't be as grainy as that, but with it I can see more clearly the problem I encounter in a milder way with every other sources): https://we.tl/t-Maamur6Wzm


TO SUM THIS UP (with comparison slides, which don't seem to display on chrome weirdly)...

- If i try h265 "grain", detail is preserved, but the grain is more present/harsher, which in movement makes the movie clip difficult to watch: https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=f49cf784-2c5b-11eb-83c8-ebb5d6f907df

- If i try h265 "none", detail disappear, and it makes a porridge-image on the face movements: https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=30220358-2c5c-11eb-83c8-ebb5d6f907df

- Weirdly, the closest to source image (the right amount of grain while preserving some detail) is obtained using h264 "grain": https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=57919c8c-2c5c-11eb-83c8-ebb5d6f907df

... but it doesn't do well on every shot (see the blocks around the guy on this large shot, or his face - you can see the problem more clearly in motion, on the little h264 excerpt I put in the wetansfer): https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=f6debe68-2c5d-11eb-83c8-ebb5d6f907df


If anyone wants to play with it, you're more than welcome, but anyway it is an occasion for newcomers to show the effect of each tune. Thanks again all for your help, and sorry to the long answer delay!
https://we.tl/t-111C1r2CA0

Using the settings recommended previously, playing it back side by side to your source and I would say it looks fine. Way better then the attached h264 version that completely breaks apart in some areas of the image. But 7Mbps is streatching it a bit for this source, had to go to crf22.5 and still ended up a bit over 7Mbps (7,6Mbps).

[TB54]

Thanks a lot !

You mean this code ?

--preset slow --profile main10 --level-idc 41 --crf 18
--keyint 240 --min-keyint 24 --rc-lookahead 48 --no-sao
--deblock -1:-1 --colorprim bt709 --transfer bt709 --colormatrix bt709 --range limited

Okaaay, i'm stupid; trying to replicate it with crf 22.5, and not achieving the same result as you (even if it's close: i end up on a 32,6 Mo file and 7 192 kb/s) I realize handbrake doesn't seem to take in consideration what i put in the advanced dialog box (don't know why)... That means that all i tried since day one (except the main things, like slow or using 10 bits) didn't have an effect! I'm sorry, that explains why your code didn't look to work for me at first...

I will definitely learn to use ffmpeg directly.

Your result is indeed very good! I still have a little weird feeling on the first close-up on him (this head movement...), but you're right, the bitrate limits us here for such a complex source.

Thanks again, and sorry for the bug :-/


EDIT : for handbrake if someone's interested, it seems to be a syntax problem (https://github.com/HandBrake/HandBrake/issues/2563). I can now achieve something very close to your result (34.8 MiB - 7 684 kb/s)

[benwaggoner]

That's a good chunk of grain in there. Maybe try --nr-intra 150 --nr-inter 500? That'll make it easier to encode and reduce the swirling moving noise. The underlying source isn't that detailed anyway. It'll let you save some bits or reduce QPs.