Any advice on --tune grain ?

[DocWhiplash]

Hello,

I plan to encode a pretty high grain BR source (1080p) in HEVC, usually since 2.4 my "go to" settings are :

preset slow / crf 18-19 / --profile main10 --output-depth 10 --aq-mode 3 --aq-strength 0.9 --no-sao --no-rect --no-strong-intra-smoothing --cbqpoffs -3 --crqpoffs -3 /
So I try to figure if adding that --tune grain will give me better results and if I should combine it with other CL ? Also should I mess with --aq-strength when encoding a grainy source ?

Thanks.

[RainyDog]

Hello,

I plan to encode a pretty high grain BR source (1080p) in HEVC, usually since 2.4 my "go to" settings are :

preset slow / crf 18-19 / --profile main10 --output-depth 10 --aq-mode 3 --aq-strength 0.9 --no-sao --no-rect --no-strong-intra-smoothing --cbqpoffs -3 --crqpoffs -3

So I try to figure if adding that --tune grain will give me better results and if I should combine it with other CL ? Also should I mess with --aq-strength when encoding a grainy source ?

Thanks.

I don't like tune grain. In addition to your base settings, my own typical tweaks for grainy sources are :-

--aq-strength 0.6-0.8 depending on grain density and consistency
--qcomp 0.7-0.75
--bframes 6-10
--ipratio 1.2 --pbratio 1.1
--weightb
--no-cutree
--qg-size 8
--deblock -2/3:-2/3
--rdpenalty 1

I sometimes mess about with psy-rd and psy-rdoq tunings too but never deviate far from the defaults. I'd also use --rd 6 across the board if I could afford the time :)

AQ strength, qcomp, ip-pbratio, no-cu(mb)tree, psy-rd and deblock settings are the same base tweaks I always made using x264 really.

[jd17]

In my experience, probably because of the high PSY values, --tune grain adds artificial grain with presets slower than --preset medium.

[RainyDog]

In my experience, probably because of the high PSY values, --tune grain adds artificial grain with presets slower than --medium.

True, --tune grain amplifies grain. We just want to retain it, not amplify it.

[Forteen88]

True, --tune grain amplifies grain. We just want to retain it, not amplify it.In x264, the second value of --psy-rd amplified grain, --tune grain used --psy-rd <unset>:0.25.
What in x265 equals that 2nd value, is it really just an inbuilt in --psy-rd as one value?

EDIT: OK, thanks RainyDog.

[RainyDog]

In x264, the second value of --psy-rd amplified grain, --tune grain used --psy-rd <unset>:0.25.
What in x265 equals that 2nd value, is it really just an inbuilt in --psy-rd as one value?

In x264 it was psy-trellis. The x265 equivalent is psy-rdoq.

[DocWhiplash]

In my experience, probably because of the high PSY values, --tune grain adds artificial grain with presets slower than --preset medium.

I did a little testing today and that's the conclusion I came up with too unfortunatly.

I don't like tune grain. In addition to your base settings, my own typical tweaks for grainy sources are :

--aq-strength 0.6-0.8 depending on grain density and consistency
--qcomp 0.7-0.75
--bframes 6-10
--ipratio 1.2 --pbratio 1.1
--weightb
--no-cutree
--qg-size 8
--deblock -2/3:-2/3
--rdpenalty 1
I will definitely give a try to these tweaks. Thanks :)

[Forteen88]

Thanks RainyDog.
I don't like tune grain. In addition to your base settings, my own typical tweaks for grainy sources are :-
...
--bframes 6-10Isn't it better to set like --bframes 3 when encoding grainy video-sources, since every frame (with few exceptions) differs with grainy sources?

EDIT: This is when you're doing encoding at like CRF 20 and under. CRF at 25+ might have more usage of more bframes.

[jd17]

So I try to figure if adding that --tune grain will give me better results...

May I ask what kind of improvement you are looking for?

I simply encode in preset slow, CRF 17-19 and add --no-sao, everything else deault. I was always very satisfied with the results, even on grainy sources.

With extreme grain, an encode is not worth the hassle imho.
That was even true for x264.
It's not really worth the time bringing a 30gb source to 25gb. ;)
With x265, those videos will come to maybe 18gb and still look good, but you will see the difference to the source.
Using --tune grain, even with a (grain-)sensible preset like medium or fast, you just end up at 25gb again and it won't be closer to the source than slow/no-sao. At least in my experience. :)

[DocWhiplash]

May I ask what kind of improvement you are looking for? Just a better grain retention overall, each build makes it better but HEVC is still struggling a bit whith that.

I simply encode in preset slow, CRF 17-19 and add --no-sao, everything else deault. I was always very satisfied with the results, even on grainy sources.
Most of the time that's what I do too and it's just fine but in this case I try to encode Battlestar Galactica which is a pain in the **s when it comes to grain.
After messing around with it a little I can agree, --tune grain does not seems to be the right approach at all here. :p

[benwaggoner]

Just a better grain retention overall, each build makes it better but HEVC is still struggling a bit whith that.

Most of the time that's what I do too and it's just fine but in this case I try to encode Battlestar Galactica which is a pain in the **s when it comes to grain.
After messing around with it a little I can agree, --tune grain does not seems to be the right approach at all here. :p
Grain is always the hardest thing for encoders, since it really is random, spatially and temporally. Throwing some --nr-inter in can help smooth out some of the motion of grain, making it both less annoying and saving some bits.

The whole issue of creative intent with grain is quite complex. Battlestar Galactica was presumably mastered with relatively small CRT professional reference monitors. Grain just isn't as apparent on those as on a big LCD panel; CRT itself is a bit of a low-pass filter :sly:. That was the issue with a lot of the first wave of Blu-ray discs; they got approved on $30K professional HD CRT monitors, which didn't show all kinds of imperfections (particularly grain and low-luma blocking) that were glaring on a typical consumer 1080p panel of the era. There was a massive rush in Hollywood authoring studios to get consumer monitors into the rooms so that mastering and QA could be done on a professional AND consumer monitor at the same time.

Same with movies. Things more than 10-15 years old were absolutely approved in projection on a perf screen, which also obscures a lot of fine detail. So the director signed of on something that showed a lot less grain than can be projected by a modern 4K projector on a non-perf screen.

I'm all for preserving creative intent, but spending TONS of bits saving grain that the creatives never approved doesn't seem appropriate. Figuring out how much grain they would have picked is pretty speculative unless the original creatives have done a recent remaster.

Big picture, some well done degrain can actually make the picture MORE like it is meant to be, as well as simplifying encoding a bunch. But knowing how much is "right" is a complex question that will never yield a clear specific answer.

[foxyshadis]

Aside from that, I don't understand why FGM is the red-headed step-child of AVC and HEVC. It's in both standards, it's just never implemented outside the reference encoder (very non-optimized, naturally). It's a very good formula that was tweaked to be even better in HEVC, could potentially save huge bitrate to still represent grain faithfully, and would have saved HEVC from being consigned to the "use it for low bitrate, but use x264 for anything with film grain" ghetto that's been the default non-professional opinion since x265 first appeared. Sure, the big studios can just throw stupid bitrate at content, but you'd think Netflix, Amazon, and DTV broadcasters would have pushed for it.

[sneaker_ger]

Isn't FGM optional for AVC and HEVC decoders? No decoder implements it, that's why it's useless.

[benwaggoner]

Isn't FGM optional for AVC and HEVC decoders? No decoder implements it, that's why it's useless.


Correct. I can’t think of anything other than HD-DVD players that shipped with FGM working, and even then I don’t thing any titles ever used it.

I don’t know what it isn’t a priority. Maybe because it doesn’t help PSNR and falls into the whole “PSNR at fixed QP” metric that so much bitstream work is based on.


Sent from my iPhone using Tapatalk

[Forteen88]

Grain is always the hardest thing for encoders, since it really is random, spatially and temporally. Throwing some --nr-inter in can help smooth out some of the motion of grain, making it both less annoying and saving some bits.Isn't it better (quality-wise) to use the AVS-script Temporal Degrain instead of --nr-inter?

[blublub]

Hi

After a long time I am again looking at x265 as the standard encoder. In 2015 and 2016 I stayed with x264 because x265 took away all the detail grain/noise from my BluRay sources. The result was an encode that looked nothing like the original in most of my sources.

Today I did some tests and it looks a lot different!

Even Preset "medium" and CRF 17 does retain a lot of detail and in my quick and dirty test I failed to see an additional detail with the option "no-sao".


So what is the most all day practical option to get high bluray encodes that keep the original picture aspect?
Is no-sao still needed and what is option "grain" actually good for?
Do I need deblock -1/-1?

So if anyone could shed some light on my questions that would be really cool!

[blublub]

May I ask what kind of improvement you are looking for?

I simply encode in preset slow, CRF 17-19 and add --no-sao, everything else deault. I was always very satisfied with the results, even on grainy sources.

With extreme grain, an encode is not worth the hassle imho.
That was even true for x264.
It's not really worth the time bringing a 30gb source to 25gb. ;)
With x265, those videos will come to maybe 18gb and still look good, but you will see the difference to the source.
Using --tune grain, even with a (grain-)sensible preset like medium or fast, you just end up at 25gb again and it won't be closer to the source than slow/no-sao. At least in my experience. :)

Hi

I found your encoding presets in another thread, very interesting.

However after I have taken a look here:

https://mattgadient.com/x264-vs-x265-vs-vp8-vs-vp9-examples/


I am not so sure about x265 as the is quite some detail lost in faces - especially the close up ones if I compare x265 crf to x265.
I know that this comparison is from 2016 but the other one available on that site is newer and there I notice similar changes from x264 to x265

[Forteen88]

blublub. Your source is HDR (SW:TFA), while your encodes aren't. You should use a SDR-source instead, so it's easier to see which encode is closer to the source.

[blublub]

blublub. Your source is HDR (SW:TFA), while your encodes aren't. You should use a SDR-source instead, so it's easier to see which encode is closer to the source.

Hi

What does "(SW:TFA" mean?


My sources are standard bluray which I did encode in x265 10bitMAIN - as suggested by some ppl here it might give less banding artifact compared to 8bit

[Forteen88]

What does "(SW:TFA" mean?Hi. It means Star Wars: The Force Awakens. The movie-source. Very crap SJW-movie.

[blublub]

Ahhh.

The encodes from that link weren't my encodes. I just found that site for comparison - there is another comparison with 10bit encoding

Edit:
https://mattgadient.com/results-encoding-8-bit-video-at-81012-bit-in-handbrake-x264x265/

[Forteen88]

blublub. OK. BTW, 10bit x265-encodes are great for 8bit-source,
https://forum.doom9.org/showthread.php?p=1833322&highlight=ateme#post1833322

[jd17]

Is no-sao still needed...
"Needed" is a relative term.
In my opinion: yes, it still makes a significant difference.
That difference becomes particularly apparent when you make still-frame comparisons.
This brings us to the link you provided.
That lost detail in faces you mentioned will return once you add --no-sao.
More importantly, --no-sao neither adds bitrate, not does it slow down your encode time.

Essentially though, it's always best to make your own comparisons. That's what I did and that's what many here did before choosing x265 as their encoder.

...and what is option "grain" actually good for?
Not much, really.
With presets starting at --preset slow (and all the slower ones below it), --tune grain adds unwanted, artificial grain and noise.
At --preset medium and --preset fast, --tune grain actually produces very nice results, but the encodes will be larger than slow/no-sao encodes. Encoding time is quicker though.

Do I need deblock -1/-1?
I am not an expert in deblocking, others might help with that.
My results were mostly very good without changing the standard 0/0.

[ShortKatz]

Hello,

I plan to encode a pretty high grain BR source (1080p) in HEVC, usually since 2.4 my "go to" settings are :


So I try to figure if adding that --tune grain will give me better results and if I should combine it with other CL ? Also should I mess with --aq-strength when encoding a grainy source ?

Thanks.
--aq-mode 3 from your command line options is not compatible to --tune grain and will result in grain strobing, according to the doc.

Overriding the –tune grain settings might result in grain strobing, especially when enabling features like --aq-mode and --cutree that modify per-block QPs within a given frame.
https://x265.readthedocs.io/en/default/presets.html#tuning

[blublub]

"Needed" is a relative term.
In my opinion: yes, it still makes a significant difference.
That difference becomes particularly apparent when you make still-frame comparisons.
This brings us to the link you provided.
That lost detail in faces you mentioned will return once you add --no-sao.
More importantly, --no-sao neither adds bitrate, not does it slow down your encode time.

Essentially though, it's always best to make your own comparisons. That's what I did and that's what many here did before choosing x265 as their encoder.


Not much, really.
With presets starting at --preset slow (and all the slower ones below it), --tune grain adds unwanted, artificial grain and noise.
At --preset medium and --preset fast, --tune grain actually produces very nice results, but the encodes will be larger than slow/no-sao encodes. Encoding time is quicker though.


I am not an expert in deblocking, others might help with that.
My results were mostly very good without changing the standard 0/0.


Ok, thx.

Via still frame comparison I made from a small test section of a BluRay movie I can't see any difference compared to my x264 encodes with the following settings:

no-sao:ctu=32:merange=25:me=3:subme=4:rd=4:qg-size=16:deblock:-2,-2:no-strong-intra-smoothing:frame-threads=6:max-tu-size=16:psy-rd=2.0:psy-rdoq=4.00:rdoq-level=2:no-rect:no-amp:qcomp=0.68

Some settings are from this thread, others from an older x265 a 2015 dated post of littlepox of which settings are equivalent for tune film in x265 and others are from brumsky.


The catch with those encoding settings is that with a CRF encode of 17 and preset medium the file size of a full movie ends up the same as my x264 settings at CRF 17 - so no compression saving but slower encoding speed with x265.
Only the 10bit encoding would be a benefit for x265 with those settings.

From my testing especially the qcomp, and psy-rd=2.0:psy-rdoq=4.00:rdoq-level=2 drove bitrate up a lot.

[Forteen88]

Only the 10bit encoding would be a benefit for x265 with those settings.Why wouldn't you set 10-bits in x265? 10-bit in x265 is supported by the GPU:s that can decode H.265, while 10-bit x264 is not supported by H.264-decoding GPU:s.
Just set --profile main10

no-sao:ctu=32:merange=25:me=3:subme=4:rd=4:qg-size=16:deblock:-2,-2:no-strong-intra-smoothing:frame-threads=6:max-tu-size=16:psy-rd=2.0:psy-rdoq=4.00:rdoq-level=2:no-rect:no-amp:qcomp=0.68

B.Waggoner wrote:
"Using <1 --frame-threads isn't as bad as it was in prior versions of x265, but -F 2 is about the max I'd use for high-quality encoding."

I really don't like this (psy-trellis) for grain-sources,
--psy-rdoq=4.00
Try disable it, and instead set --psy-rd 4.0

Also, click "Go Advanced" and chose to disable smilies to make your posts here more readable! You had 3 unintentional smilies in your last post.

[blublub]

Why wouldn't you set 10-bits in x265? 10-bit in x265 is supported by the GPU:s that can decode H.265, while 10-bit x264 is not supported by H.264-decoding GPU:s.
Just set --profile main10



B.Waggoner wrote:

I really don't like this (psy-trellis) for grain-sources,
--psy-rdoq=4.00
Try disable it, and instead set --psy-rd 4.0

Yeah I used 10b all the time. That was a misunderstanding.
What I was trying to say was that x265s ending up at the same size as x264 it's only advantage is 10b over 8bit encode

I will try without psy-rdoq, thx

[excellentswordfight]

Ok, thx.

Via still frame comparison I made from a small test section of a BluRay movie I can't see any difference compared to my x264 encodes with the following settings:

no-sao:ctu=32:merange=25:me=3:subme=4:rd=4:qg-size=16:deblock:-2,-2:no-strong-intra-smoothing:frame-threads=6:max-tu-size=16:psy-rd=2.0:psy-rdoq=4.00:rdoq-level=2:no-rect:no-amp:qcomp=0.68

Some settings are from this thread, others from an older x265 a 2015 dated post of littlepox of which settings are equivalent for tune film in x265 and others are from brumsky.


The catch with those encoding settings is that with a CRF encode of 17 and preset medium the file size of a full movie ends up the same as my x264 settings at CRF 17 - so no compression saving but slower encoding speed with x265.
Only the 10bit encoding would be a benefit for x265 with those settings.

From my testing especially the qcomp, and psy-rd=2.0:psy-rdoq=4.00:rdoq-level=2 drove bitrate up a lot.
I would try to keep it a bit more simple at first, throwing a bunch of tweaked settings that are copy pasted from different situations might not be the best thing for you.

Start simple, start with trying a slower preset, try --profile main10 --preset slow --crf 18 --no-sao and use that as i reference and go from there. But if you prioritize speed over compression, then x264 might be the way to go for blurayripping at high quality.

[Forteen88]

But if you prioritize speed over compression, then x264 might be the way to go for blurayripping at high quality.I don't know if that's true,
x264 got crappy result here,
"Speed/quality trade-off “Universal use case,” all sequences"
http://www.compression.ru/video/codec_comparison/hevc_2018/

SSIM isn't the most reliable metric though, IIRC it don't mind blurry frames.

[excellentswordfight]

I don't know if that's true,
x264 got crappy result here,
"Speed/quality trade-off “Universal use case,” all sequences"
http://www.compression.ru/video/codec_comparison/hevc_2018/

SSIM isn't the most reliable metric though, IIRC it don't mind blurry frames.
I havnt looked in to the exact scenario/settings for that test. But if it's possible then please let me know what settings to use :) Cause I havnt found them for high detail retention bluray rips. Preset fast is close to x264 with someting like preset slow with tune film in speed, I havnt found a way to tune presets that high not be soft while saving bits.

Not looking down on x265 here, I think its great, but for this use case (which pops up here alot), its imo not that great if you prioritize speed over saving some bits, cause I havnt seen any settings that can match x264 when tuned for the same speed for this scenario. And I think thats fine, but in my experience we are looking at a 20-30% bitrate reduction for a 2-3x difference in speed, cause x265 needs to be tuned very slow for it to start to retain a lot of detail. But if we are talking about "good enough", and for people that are not frame peeking, sure x265 will blow it away.

[blublub]

I would try to keep it a bit more simple at first, throwing a bunch of tweaked settings that are copy pasted from different situations might not be the best thing for you.

Start simple, start with trying a slower preset, try --profile main10 --preset slow --crf 18 --no-sao and use that as i reference and go from there. But if you prioritize speed over compression, then x264 might be the way to go for blurayripping at high quality.

Hi

I started simple with preset medium and:

no-sao:frame-threads=6:ctu=32:merange=27:deblock:-1,-1:no-strong-intra-smoothing - quality was pretty good. Visually a little different to my x264 encodes but I wouldn't really consider it any worse.

and then added: me=3:rd=4:qg-size=16:subme=4 - small bitrate increase and I didn't see any drop in quality here but neither any gain.


My goal with x265 is to either increase or stay at the same image quality but to reduce the file size/bitrate while maintaining a decent encoding speed - x264 speed is between 30 and 40fps. With x264 I was either able to increase compression by a mere 3-5% with a drop in encoding speed way below 20fps - so not worth it.
For x265 a try to maintain a encoding speed between 20 and 26fps - so close to mealtime an my 16c machine.


My x264 setting are a mixture of slow/slower and some modification that didn't reduce encoding time on my system but did slightly decrease file size:

cabac=1 / ref=6 / deblock=1:-1:-1 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.10 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=34 / lookahead_threads=8 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=5 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=17.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=300000 / vbv_bufsize=300000 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00

[blublub]

Why wouldn't you set 10-bits in x265? 10-bit in x265 is supported by the GPU:s that can decode H.265, while 10-bit x264 is not supported by H.264-decoding GPU:s.
Just set --profile main10



B.Waggoner wrote:
"Using <1 --frame-threads isn't as bad as it was in prior versions of x265, but -F 2 is about the max I'd use for high-quality encoding."

I really don't like this (psy-trellis) for grain-sources,
--psy-rdoq=4.00
Try disable it, and instead set --psy-rd 4.0

Also, click "Go Advanced" and chose to disable smilies to make your posts here more readable! You had 3 unintentional smilies in your last post.

Removing psy-trellis dropped my encodes back to normal size

[Forteen88]

My x264 settingthreads=34Be aware that,
If you have a multi-processor machine, you should really consider using it as it can to increase encoding speed linearly with the number of CPU cores (about 94% per CPU core), with very little quality reduction (about 0.005dB for dual processor, about 0.01dB for a quad processor machine). http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html

And I wouldn't say that 0.3dB (if you're setting 4 threads instead of 34) is "very little quality reduction".

[blublub]

Yeah I know. But if you want to encode a lot you need a fast CPU so I just have to live with that penalty as there is no quad core CPU that runs at 16ghz per core ;-)

[Forteen88]

Yeah I know. But if you want to encode a lot you need a fast CPU so I just have to live with that penalty as there is no quad core CPU that runs at 16ghz per core ;-)Why not make two or more encodes at the same time then?
Someone wrote this though (which I don't know is true or false, and if AVX2 is different): In contradiction to The Stilt' comment I can run 2 encode simultaneously with together 26-30fps - so the catch here is that if AVX would be the bottleneck the second job should just choke at the already maxed out AVX load and my total fps with 2 jobs should not exceed the 20fps like I would only be doing 1 job.

So from my limited perspective here AVX can't be the reason why x265 just doesn't max out my 16c machine - there should be another reason.https://forum.doom9.org/showthread.php?p=1852755#post1852755

[blublub]

Why not make two or more encodes at the same time then?
Someone wrote this though (which I don't know is true or false, and if AVX2 is different): https://forum.doom9.org/showthread.php?p=1852755#post1852755

I wrote that post. Dual encoding works perfectly so I doubt that AVX is a bottleneck on Threaripper when CPU usage is low - has to a scaling issue in general for whatever reason.

Can on really see a difference between encodes done in framethreads=3 and frame-threads=6 ?

[amichaelt]

Grain is always the hardest thing for encoders, since it really is random, spatially and temporally. Throwing some --nr-inter in can help smooth out some of the motion of grain, making it both less annoying and saving some bits.

The whole issue of creative intent with grain is quite complex. Battlestar Galactica was presumably mastered with relatively small CRT professional reference monitors. Grain just isn't as apparent on those as on a big LCD panel; CRT itself is a bit of a low-pass filter :sly:. That was the issue with a lot of the first wave of Blu-ray discs; they got approved on $30K professional HD CRT monitors, which didn't show all kinds of imperfections (particularly grain and low-luma blocking) that were glaring on a typical consumer 1080p panel of the era. There was a massive rush in Hollywood authoring studios to get consumer monitors into the rooms so that mastering and QA could be done on a professional AND consumer monitor at the same time.

Same with movies. Things more than 10-15 years old were absolutely approved in projection on a perf screen, which also obscures a lot of fine detail. So the director signed of on something that showed a lot less grain than can be projected by a modern 4K projector on a non-perf screen.

I'm all for preserving creative intent, but spending TONS of bits saving grain that the creatives never approved doesn't seem appropriate. Figuring out how much grain they would have picked is pretty speculative unless the original creatives have done a recent remaster.

Big picture, some well done degrain can actually make the picture MORE like it is meant to be, as well as simplifying encoding a bunch. But knowing how much is "right" is a complex question that will never yield a clear specific answer.

Unfortunately what we actually got in practice was a whole ton of crappy, plasticky-looking Blu-Rays where the studio went overboard with DNR because everyone whined that the picture wasn't perfectly "clean" on their HDTVs.

[brumsky]

Hi

I started simple with preset medium and:

no-sao:frame-threads=6:ctu=32:merange=27:deblock:-1,-1:no-strong-intra-smoothing - quality was pretty good. Visually a little different to my x264 encodes but I wouldn't really consider it any worse.

and then added: me=3:rd=4:qg-size=16:subme=4 - small bitrate increase and I didn't see any drop in quality here but neither any gain.


My goal with x265 is to either increase or stay at the same image quality but to reduce the file size/bitrate while maintaining a decent encoding speed - x264 speed is between 30 and 40fps. With x264 I was either able to increase compression by a mere 3-5% with a drop in encoding speed way below 20fps - so not worth it.
For x265 a try to maintain a encoding speed between 20 and 26fps - so close to mealtime an my 16c machine.


My x264 setting are a mixture of slow/slower and some modification that didn't reduce encoding time on my system but did slightly decrease file size:



I'm sure you've heard this before but you can pick 2 of the following 3 items.

Encode Speed
Encode Quality
Encode Size

In short x265 is more computationally intensive than x264. Therefore, x264 will in most cases beat x265 from a pure speed perspective.

If you want to decrease the size of your encode then you either have to sacrifice quality or accept that'll take longer to encode.

[blublub]

I want the same or better quality in x265 compared to x264 in tune film at the same or smaller file size - the x264 settings I used are posted above for comparison.

Speed is relative since my current CPU is about 3x to 4x as faster compared to 2016 and earlier (FX 8350).
The current x265 settings would be well below 10fps on my old rig ;-) - however I try stay at real time encoding with x265 and the current CPU.

This thread, including your suggestion, helped a lot and quality, at least for my eyes, is very good and I can't see a difference in the test encodes I did in the last days - only remaining question here is if there us anything in my settings that's just wrong.
Speed is also ok with 22 to 24 fps on average.

The only thing that could be better is CPU utilization with frame-threads=2 - only 60%.
But since you all mentioned that more threads degrade quality significantly I try to do 2 encodes at the at the same time.

[benwaggoner]

Unfortunately what we actually got in practice was a whole ton of crappy, plasticky-looking Blu-Rays where the studio went overboard with DNR because everyone whined that the picture wasn't perfectly "clean" on their HDTVs.
Yeah. Honestly, DNR should be integrated into the creative work of the film restoration and mastering process, and with as much consideration of creative intent as everything else in remastering.

Creative approval of a 35mm projection on a perf screen shouldn't be assumed to apply to an 8K wet gate scan of the same 35mm master which will be shown on >=4K direct emission displays.

[blublub]

Hi

I just stumbled upon a couple of dark scenes which were quite blocky and not very good looking - however still better than the old x264 encode.

Is there any option to improve this? I read to change aq-mode might help

Edit:
My CRF is already quite low with 17

[benwaggoner]

Hi

I just stumbled upon a couple of dark scenes which were quite blocky and not very good looking - however still better than the old x264 encode.

Is there any option to improve this? I read to change aq-mode might help

Edit:
My CRF is already quite low with 17



—aq-mode 3 is exactly for reducing blocking in dark scenes. It will increase bitrate at a given CRF, but will also allow you to increase your CRF without increasing blocking in black, so the net bitrate required for a given quality should be lower.

Testing aq-modes with 2-pass VBR encodes makes direct comparisons a lot simpler.


Sent from my iPad using Tapatalk

[blublub]

—aq-mode 3 is exactly for reducing blocking in dark scenes. It will increase bitrate at a given CRF, but will also allow you to increase your CRF without increasing blocking in black, so the net bitrate required for a given quality should be lower.

Testing aq-modes with 2-pass VBR encodes makes direct comparisons a lot simpler.


Sent from my iPad using TapatalkK thx. I will give it a try.

By the way is there any rule of thumb on which CRF produces similar quality for 1080p - x264 vs x264 CRF

I read for 4k CRF 28 for x275 should be similar to x264 CRF 23 - I once tried that and looked remarkably not identical hence I stick to CRF 17 for x265 just like in x264 - if you day CRF can be like +3 in x265 I might just up it to 18 as a compromise

[brumsky]

K thx. I will give it a try.

By the way is there any rule of thumb on which CRF produces similar quality for 1080p - x264 vs x264 CRF

I read for 4k CRF 28 for x275 should be similar to x264 CRF 23 - I once tried that and looked remarkably not identical hence I stick to CRF 17 for x265 just like in x264 - if you day CRF can be like +3 in x265 I might just up it to 18 as a compromise

No there isn't a rule of thumb for CRF. Now using bitrate it might be possible to come up with a highly generalized rule of thumb... It's mostly subjective. You'd find one range if you only played the video back and another range if you were a pixel peeper. :)

As for the aq-modes I've found that 3 can pump up the bitrate as Ben mentioned. I've found setting the aq-strength .75 - .95 to be beneficial controlling the bitrate a little better.

[benwaggoner]

K thx. I will give it a try.

By the way is there any rule of thumb on which CRF produces similar quality for 1080p - x264 vs x264 CRF
Er, maybe try 1 higher for x265 and iterate? It's quite content and bitrate contingent. CRF is basically a complexity offset to QP, these are quite different codecs where different QPs can be optimal for different content. Having CRF act the same in x265 as in x264 was never a design goal for x265.

That it is ballpark similar is probably due HEVC starting as a delta to H.264, and the traditional codec development model's heavy bias for constant QP maximizing both objective and subjective metrics.

I read for 4k CRF 28 for x275 should be similar to x264 CRF 23 - I once tried that and looked remarkably not identical hence I stick to CRF 17 for x265 just like in x264 - if you day CRF can be like +3 in x265 I might just up it to 18 as a compromise
CRF can definitely be higher for UHD resolutions, because each artifact is much smaller. People don't sit 2x closer to a 2x higher resolution display.

CRF 17 will generally look great in either codec.

[blublub]

No there isn't a rule of thumb for CRF. Now using bitrate it might be possible to come up with a highly generalized rule of thumb... It's mostly subjective. You'd find one range if you only played the video back and another range if you were a pixel peeper. :)

As for the aq-modes I've found that 3 can pump up the bitrate as Ben mentioned. I've found setting the aq-strength .75 - .95 to be beneficial controlling the bitrate a little better.

Yeah I noticed that. My test encodes with aq3 came out 30% larger.
Using CRF 18 instead of 17 reduced it too about 10% for the same files.

Mode aq=3 however reduced blockiness in the one dark scene, so I guess I will stick to it.
But then I am torn between CRF 17 and 18 - honestly with my eyes I can't see a difference but since my new TV is larger I see a lot more artifact on my old encodes than previously - so CRF 17 might be more "future proof" ;-)

Since benwaggoner suggested that x264's CRF +1 probably won't hurt I might just do a couple of encodes with CRF 17 and if sizes are too big just switch to CRF 18 - it will be a lot better in terms of quality than my 2+ years old encodes anyway so it will be ok.

[blublub]

deleted

[brumsky]

Yeah I noticed that. My test encodes with aq3 came out 30% larger.
Using CRF 18 instead of 17 reduced it too about 10% for the same files.

Mode aq=3 however reduced blockiness in the one dark scene, so I guess I will stick to it.
But then I am torn between CRF 17 and 18 - honestly with my eyes I can't see a difference but since my new TV is larger I see a lot more artifact on my old encodes than previously - so CRF 17 might be more "future proof" ;-)

Since benwaggoner suggested that x264's CRF +1 probably won't hurt I might just do a couple of encodes with CRF 17 and if sizes are too big just switch to CRF 18 - it will be a lot better in terms of quality than my 2+ years old encodes anyway so it will be ok.

Haha yeah when Benwaggoner speaks\types we listen\read! ;)

Can you post your full list of settings? I don't normally use CRF 17 except for very dark video. Just curious as to what you are running. Also, --rd 5 can make a big difference in quality. I have a 65 and 75in 4K TVs and I've been pretty content with a higher CRF value. For example, Avengers Infinity War has a CRF of 19.

Admittedly, a lot of that has to do with the settings and viewing distance from the TV. Due to my room sizes and furniture I sit about 18 feet away from my 65in and 15 ft away from the 75in.

[blublub]

Haha yeah when Benwaggoner speaks\types we listen\read! ;)

Can you post your full list of settings? I don't normally use CRF 17 except for very dark video. Just curious as to what you are running. Also, --rd 5 can make a big difference in quality. I have a 65 and 75in 4K TVs and I've been pretty content with a higher CRF value. For example, Avengers Infinity War has a CRF of 19.

Admittedly, a lot of that has to do with the settings and viewing distance from the TV. Due to my room sizes and furniture I sit about 18 feet away from my 65in and 15 ft away from the 75in.

I use CRF 17 / 18, preset medium and the following options:



no-sao:frame-threads=2:ctu=32:merange=27:me=3:subme=4:rd=4:deblock=-1;-1:no-strong-intra-smoothing:bframes=4:ref=4:psy-rd=3.0:qcomp=0.63:aq-mode=3


I have 65" and viewing distance is 2.8m

[brumsky]

I use CRF 17 / 18, preset medium and the following options:



no-sao:frame-threads=2:ctu=32:merange=27:me=3:subme=4:rd=4:deblock=-1;-1:no-strong-intra-smoothing:bframes=4:ref=4:psy-rd=3.0:qcomp=0.63:aq-mode=3


I have 65" and viewing distance is 2.8m

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

[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.