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. :)