Struggling with my x265 settings

[Hostile_18]

Hi all. Great to be here.

I am using fileflows and have been perfecting my settings over the last few weeks. I am converting my blu ray 1080p remuxs to x265 at settings that a) can be universally applied, b) take roughly real time to encode with my 9800x3d c) maintain a high quality.

So far I have dialed in settings that is really faithful with heavy grain and clean content. The problem has been with middle ground content, where it seems to be applying some denoise, which is taking away detail? I can't for the life of me find out what to adjust to make my encodes more faithful with this type of content. My settings are:

libx265 -pix_fmt yuv420p10le -crf 20 -preset slow -x265-params sao=0:aq-mode=1:deblock=-1,-1:ctu=32:

Here you will see the grain/detail removed, especially on the wall, dirt on the steps.
https://imgsli.com/NDQ4NDE4

That's not a huge deal, but it's also taking away detail in the wallpaper, especially at the edges.
https://imgsli.com/NDQ4NDE3

What's odd is that with very heavy grain films, with these settings I'm not seeing any of these issues, nor on clean content. I am a little out of my depth, so after hours and hours of changing things through trial and error I thought I'd ask the experts. I haven't got too much room to play with as very grainy content can go up to 80% of source with these settings, but the majority of my discs go to 30-35% of source (including this one I'm having trouble with).

Any help would be greatly appreciated. :)

[Emulgator]

At 30..35% H.264 bitrate I would expect that.
Given H.265 I would aim at 60% BD-rate, not less, or prepare to accept smudged areas.
To avoid that I would suggest to force --aq-mode 0, (any aq>0 eats grain from smoother areas), lower CRF to maybe 16, restrict qpmax, etc.

[Hostile_18]

At 30..35% H.264 bitrate I would expect that.
Given H.265 I would aim at 60% BD-rate, not less, or prepare to accept smudged areas.
To avoid that I would suggest to force --aq-mode 0, (any aq>0 eats grain from smoother areas), lower CRF to maybe 16, restrict qpmax, etc.

Thank you for reply. I didn't think to try turning off AQ but I had tried modes 1-4 as part of my testing. Putting it to 0 did lower file size quite a bit so gave me room to add a better quality CRF (16).

However problem is still pretty much the same, wall is smoothed even with those settings. This is a strange one given clean and complex (heavy grain) content is pixel perfect in my comparisons. I mean the wall arguably looks more pleasing to the eye like this, but unfortunately it will usually take away fine detail in other areas on this type of content only.

https://imgsli.com/NDQ4NDI3

[hellgauss]

Sometimes I noticed weird behaviour when turning off features which are on by default. Perhaps it depends on the build:

- Has sao really been removed? Eventually try no-sao=1.

Other suggestions:
- try no-strong-intrasmoothing

There are other stuff to do to deal with grain, but unfortunatelly they are time consuming:
- preset slower (at least). Below slower x265 loose most of its power
- rskip=2 + rskip-edge-threshold=1 ; even better rskip=0

[Z2697]

FYI imgsli compresses image to lossy WebP so it might not be the best place to post "pixel peeping" comparisons.
The difference did manage to come through though. (through? though? through though? though through?)

[Hostile_18]

Thank you both I tried those suggestions. SAO was definitely off (I used that alternative command).

So the good news is I have fixed it by adding "no-cutree=1". The bad news is that doubles the encode size. (EDIT: Mind that was at CRF16 still, back to CRF20 with that command, file size isnt so bad, extra 18mb a minute).

Does this help troubleshoot what the problem might be at all? Is there a half way house I could meet that doesn't increase the size so dramatically? :)

[GeoffreyA]

Try x264 with -preset veryslow, -tune film, and CRF 18 or so on that scene, and see if the detail is restored.

[Hostile_18]

Try x264 with -preset veryslow, -tune film, and CRF 18 or so on that scene, and see if the detail is restored.

So soluton wise it looks like x264 the answer is AQ Mode =0, x265 the answer is "no-cutree=1".

I'll do comparisons between each and see which format I want to go with.

Thank you everyone. :)

[GeoffreyA]

Before disabling cu-tree, try raising qcomp to 0.7 or 0.8, and psy-rd and psy-rdoq.

[Hostile_18]

Before disabling cu-tree, try raising qcomp to 0.7 or 0.8, and psy-rd and psy-rdoq.

qcomp at 0.8-1.0 gives very similar results to cu-tree off, so would that be preferred over the latter?

I haven't got much knowledge at all about psy-rd and psy-rdog, like what they do, what values do you recommend for them? :)

[Z2697]

Do you want to improve the grain at similar bitrate, or you just want some setting to cause the increase in bitrate in the right amount?
Why not just, increase the bitrate, like, directly?
Deciding something is better without normalizing for bitrate is not what I'd say a good practice.
Or looking at bitrate without assessing quality, is the same, you need to know BOTH.

You won't get much from the same bitrate level because the bitrate is not enough for the level of detail you want.
The "dynamics" of grain is lost to the lack of bits to code inter residual, so adjusting aq-mode or go higher preset won't give you much.

[Hostile_18]

Do you want to improve the grain at similar bitrate, or you just want some setting to cause the increase in bitrate in the right amount?
Why not just, increase the bitrate, like, directly?
Deciding something is better without normalizing for bitrate is not what I'd say a good practice.
Or looking at bitrate without assessing quality, is the same, you need to know BOTH.

You won't get much from the same bitrate level because the bitrate is not enough for the level of detail you want.
The "dynamics" of grain is lost to the lack of bits to code inter residual, so adjusting aq-mode or go higher preset won't give you much.

Im happy to increase the bit rate, when ive taken it from 20 to 16 though it hasn't solved the issues. I guess I didnt think it was bit rate related because heavier grain films were fine (albeit in a larger size, with same settings). If I did increase the bit rate how would I limit the top end if crf 20 is taking me to say 80% on something like Black Swan or Wishmaster 3 etc where grain is intense?

I must have messed about with settings for 12 hours yesterday and just couldnt get it to look right for this type of content. I looked at a streaming version and it was handling the scenes fine, so am on the edge of wondering if its just better to keep my remuxes today. Its a shame as I think I nailed clean and heavy content, its just this middle ground thats causing me issues. :)

[Z2697]

It's all the same.
Don't you think what other options that increase bitrate for this film will also increase bitrate for heavy grain films?
Don't you need to limit that as well?

You don't usually get an universal solution with CRF.
You have 2-pass ABR as your friend. (maybe even single pass)
Online streaming services use it, if they use x264/5. In fact, logically I think they would use it for any encoders that support it.

[Hostile_18]

It's all the same.
Don't you think what other options that increase bitrate for this film will also increase bitrate for heavy grain films?
Don't you need to limit that as well?

You don't usually get an universal solution with CRF.
You have 2-pass ABR as your friend. (maybe even single pass)
Online streaming services use it, if they use x264/5. In fact, logically I think they would use it for any encoders that support it.

Thats true, most things I do to make this movie look good i.e cutree=0 make all files bigger. On Handbrake subreddit they are largely (like 95% against abr) when I asked about it, which is strange given its preferred by most "groups".

I have nothing to lose trying it out. Also I think FileFlows has a premium option where it analyses the video and makes quality adjustments based on content. Ill look at both.

I ideally wanted one setting so it dosnt need human judgment for all my (large) collection. Thank you for the advice.

[Z2697]

Maybe they are specifically against single pass ABR.
2-pass ABR is usually considered to be on par with the CRF that will end up in similar bitrate.
If you think it's too slow, you can use --no-slow-first-pass.

Some "groups" use 2-pass for some historical/mystical/mythical reason, but as I mentioned, it's considered on par with CRF, even by x264 developers.
(And many are shifting toward CRF nowadays...?)
Of course, there's always a catch, they are not exactly the same, just similar enough.

[GeoffreyA]

qcomp at 0.8-1.0 gives very similar results to cu-tree off, so would that be preferred over the latter?

I haven't got much knowledge at all about psy-rd and psy-rdog, like what they do, what values do you recommend for them? :)

As I understand it, a higher qcomp will cause quality to be more consistent frame to frame. CU- and MB-tree lower the quality of blocks that are less important temporally; for example, those that will disappear in the near future. A good idea for the most part because those saved bits can go elsewhere. If you can get quality you're happy with by raising qcomp, leaving CU-tree on, I would choose that. But, as Z2697 notes, it might be all the same: we're just shifting the bits around.

psy-rd and psy-rdoq can help restore lost detail.

If x264 can achieve transparency at similar sizes you're getting with x265, it's also an option.

[x264N00b]

Rate Factor 20 is simply not enough to maintain high quality for many cases. You can also tweak your settings a bit.
-x265-params "aq-mode=1:no-open-gop=1:high-tier=1:level-idc=4.1:bframes=6:subme=4:rc-lookahead=120:pbratio=1.25:ctu=32:merange=26:deblock=-3,-3"
Maybe add "no-rskip=1" but it will slow down the speed noticeable. I usually don't turn SAO off, because it gives me only a better quality at very low bitrates. Also pay attantion for the frame types when taking/comparing sceenshorts. (comparing b-frames will give you a better feedback about the compression)

You can check out the "x265 settings for re-encoding 4K BD near-losslessly" thread too.

qcomp at 0.8-1.0 gives very similar results to cu-tree off, so would that be preferred over the latter?)
Qcomp above 0,8 or even 0,7 is a way too high, if you ask me. I think the default value is fine.

[Z2697]

I'd rather use hex with larger range than star with small range. (you don't have to agree with me)
SAO in x265 is just broken, especially with grains.
qcomp with cutree enabled actually turns into controlling the strength of cutree. (bigger qcomp, lower cutree strength)

[Hostile_18]

Thank you everyone I am going to be looking and testing with what everyone has suggested. Going to take me a bit of time to work it all out and apply it!

Rate Factor 20 is simply not enough to maintain high quality for many cases. You can also tweak your settings a bit.
-x265-params "aq-mode=1:no-open-gop=1:high-tier=1:level-idc=4.1:bframes=6:subme=4:rc-lookahead=120:pbratio=1.25:ctu=32:merange=26:deblock=-3,-3"
Maybe add "no-rskip=1" but it will slow down the speed noticeable. I usually don't turn SAO off, because it gives me only a better quality at very low bitrates. Also pay attantion for the frame types when taking/comparing sceenshorts. (comparing b-frames will give you a better feedback about the compression)

You can check out the "x265 settings for re-encoding 4K BD near-losslessly" thread too.


Qcomp above 0,8 or even 0,7 is a way too high, if you ask me. I think the default value is fine.

I tried those settings and they look really good. The downside is it went from real time encoding to 6 times real time (edit: Ignore me here, I was using slower, not slow).

If I keep using CRF and settings that create a bigger file, is there a way that I can stop it going over source at the top end without manual intervention/judgement?

[x264N00b]

I'd rather use hex with larger range than star with small range. (you don't have to agree with me)
Never tried this, what will be the benefits?


SAO in x265 is just broken, especially with grains.
It was "broken". I never had quality issues with newer x265 builds related to SAO, let say >v3.5? Can't tell exactly when the issue with the detail loss und blurring got fixed.

[Hostile_18]

I'm getting really good results with these settings now. The bit rate limits are kind of arbitrary according to chat gpt, so if they need tweaking please let me know (roughly min 40% of source, max 75% of source). I'll experiment with SAO as well, but all my main problems are sorted.

libx265 -pix_fmt yuv420p10le -crf 18 -preset slow -x265-params aq-mode=1:no-open-gop=1:high-tier=1:level-idc=4.1:bframes=6:subme=4:rc-lookahead=120:pbratio=1.25:ctu=32:merange=26:deblock=-3,-3:vbv-maxrate=20000:vbv-bufsize=40000:


Regarding audio I'm converting the lossless tracks to EAC3, is there a bit rate where it will be virtually no difference? Currently set to 960kbps (not each channel).

[Z2697]

x265 SAO + grain = no

vbv-maxrate and vbv-bufsize don't mean "min/max".
Think encoding as draining water (bits) from a bucket, the size of the bucket is the vbv-bufsize, the speed the bucket gets refilled is vbv-maxrate.
(This is why a bitrate overshoot is called vbv underflow)

Using Opus (libopus) for audio would be more efficient (unless you are making E-AC-3 JOC).

[GeoffreyA]

Regarding audio, I like Apple AAC-LC (QAAC). TVBR91 or 109 will give excellent results.

[Hostile_18]

x265 SAO + grain = no

vbv-maxrate and vbv-bufsize don't mean "min/max".
Think encoding as draining water (bits) from a bucket, the size of the bucket is the vbv-bufsize, the speed the bucket gets refilled is vbv-maxrate.
(This is why a bitrate overshoot is called vbv underflow)

Using Opus (libopus) for audio would be more efficient (unless you are making E-AC-3 JOC).

Ah I see, I mean it has left most films unaffected but the top end its reduced the file size, while showing no problems to my eyes with the quality. Do those values chat gpt came up with seem reasonable?

I was going to say Opus doesn't work with VLC player, but I've just seen an update for the software and now its working. What bit rate for Opus would be good where only an audiophile might be able to hear a difference? (compared to trueHD and DTS).

Edit: Just read Opus isn't supported well on LG OS TV's, I'll have to double check on that.

[Hostile_18]

I went with Opus in the end, everything can direct play no issues. My settings below are doing really well. Roughly about 2 and a half hours per disc. Someone on reddit thought I might be doing alot of complex maths and not using it with my settings, so was recommending faster presets? When I've looked into it compared to the medium preset the only setting I've got that adds a lot of time is "rect" If I turn it off one 60 second test video goes from 2.16 to encode to 1.30, with my slow preset settings below. Is Rect essential to my video quality or can I safely turn it off and save a lot of time? File size was roughly the same.

Star to Hex saved 8 seconds per 1 min test video, so not as dramatic, but again not to sure the visual cost.

libx265 -pix_fmt yuv420p10le -crf 17 -preset slow -x265-params aq-mode=1:no-open-gop=1:high-tier=1:level-idc=4.1:bframes=6:subme=4:rc-lookahead=120:pbratio=1.25:ctu=32:merange=26:deblock=-3,-3:no-sao=1:vbv-maxrate=20000:vbv-bufsize=80000:vbv-init=0.9

[microchip8]

I went with Opus in the end, everything can direct play no issues. My settings below are doing really well. Roughly about 2 and a half hours per disc. Someone on reddit thought I might be doing alot of complex maths and not using it with my settings, so was recommending faster presets? When I've looked into it compared to the medium preset the only setting I've got that adds a lot of time is "rect" If I turn it off one 60 second test video goes from 2.16 to encode to 1.30, with my slow preset settings below. Is Rect essential to my video quality or can I safely turn it off and save a lot of time? File size was roughly the same.

Star to Hex saved 8 seconds per 1 min test video, so not as dramatic, but again not to sure the visual cost.

libx265 -pix_fmt yuv420p10le -crf 17 -preset slow -x265-params aq-mode=1:no-open-gop=1:high-tier=1:level-idc=4.1:bframes=6:subme=4:rc-lookahead=120:pbratio=1.25:ctu=32:merange=26:deblock=-3,-3:no-sao=1:vbv-maxrate=20000:vbv-bufsize=80000:vbv-init=0.9

rect can be pretty beneficial. To speed it up, use limit-modes=1 which uses some magic to decide which partitions are unlikely to be selected as (best) candidates. If you use limit-modes=1 you might want to turn amp too (which depends on rect being on), although that one is not as beneficial as rect but virtually never hurts.

Might also want to turn off strong-intra-smoothing

[Hostile_18]

rect can be pretty beneficial. To speed it up, use limit-modes=1 which uses some magic to decide which partitions are unlikely to be selected as (best) candidates. If you use limit-modes=1 you might want to turn amp too (which depends on rect being on), although that one is not as beneficial as rect but virtually never hurts.

Might also want to turn off strong-intra-smoothing

I think Limit Mode=1 is on by default on Slow preset, at least according to this table; (I highlighted it to see what changed from the Slow Preset I was already on, and what didn't).

https://i.ibb.co/4wLnbpBK/Screenshot-2026-02-14-141003-Copy.jpg (https://ibb.co/mrKVn4Qb)

I could add "rskip=2" that saves a bit or time, but its been hard to distinguish if it has a noticeable effect on quality. It saves around as much time as turning rect=0, so that's a possibility.

I'll look into Strong Intra Smoothing, I did research here a while ago and there seemed to be some debate here if it actually made the image worse or not. :)

[microchip8]

I use rskip=2 with a threshold of 1 (which translates to 0.01, lowest possible = best quality) and it does speed up things. I have not noticed any issues with it and I've done around 100 encodes thus far with it.

[Z2697]

rskip=2 usually have more quality cost than rect=0.
strong-intra-smoothing is only effective on 32x32 intra blocks (max PU/TU size for intra), if the partitioning part of the default encoding process is not altered, the large blocks are usually smooth areas.
And, the smoothing only applies to reference pixels (reconstructed neighbors).

[microchip8]

I don't like anything with smoothing in its name or softening the image like SAO, and also find the deblocker at defaults to soften too much so I set it to -3:-3. Along with some other micro-optimizations I get a very detailed picture. I don't do 4k encodes as PC is too slow for that (around 2 fps speed) so scale down to Full HD using a Spline64 scaler from zimg. My Ryzen 9 5900X (stock max speed 3.7 GHz, overclocked by me to 4 GHz on all cores), I get between 6.5 and 8 fps speed, sometimes higher if source is very clean and compressible.

[GeoffreyA]

These are the settings I've settled on; though in terms of sharpness, it still loses to x264 if comparing frame for frame. No doubt, more could be squeezed out of it.

-preset slow -crf %crf% -x265-params level-idc=41:no-sao=1:deblock=-1,-1:aq-mode=1:cbqpoffs=-3:crqpoffs=-3:
ctu=32:tu-intra-depth=3:tu-inter-depth=3:limit-tu=4:
rd=4:rskip=2:rskip-edge-threshold=1:ref=4:limit-refs=3:subme=4:max-merge=4:
no-open-gop=1:keyint=240:min-keyint=24:rc-lookahead=240:bframes=8:b-intra=0:weightb=1:fades=1:no-amp=1

[microchip8]

And these are mine :)


ref=4:me=umh:merange=52:subme=7:bframes=6:rd=4:rd-refine=0:qcomp=0.60:fades=1:strong-intra-smoothing=0:ctu=32:qg-size=16:sao=0:selective-sao=0:cu-lossless=0:cutree=1:tu-inter-depth=4:tu-intra-depth=4:max-merge=5:rskip=2:rskip-edge-threshold=1:rc-lookahead=80:lookahead-slices=0:aq-mode=1:aq-strength=1.1:rdoq-level=1:psy-rd=3.0:psy-rdoq=3.5:limit-modes=1:limit-refs=0:limit-tu=0:deblock=-3,-3:weightb=1:weightp=1:rect=1:amp=1:wpp=1:b-intra=1:b-adapt=2:b-pyramid=1:tskip=0:tskip-fast=0:fast-intra=0:early-skip=0:splitrd-skip=0:refine-mv=3:refine-intra=4:refine-inter=1:min-keyint=24:keyint=240


I've used in the past subme=5 but find subme=7 to subjectively provide a slightly more sharper image. It's not a sharpening filter in the classical sense but what it does is find more precisely the best possible estimation at subpixel level, thus providing more precise/better detail preservation which leads to the impression as if the image has been slightly sharpened like with a filter. It's a micro-optimization and since my CPU can take it, why not use it?

I also disable all lookahead-slices since I vaguely recall it has a negative impact on AQ?

[Hostile_18]

Thank you everyone, a lot to drive into and experiment with. I will report back my findings. :)

Has anyone found a good cpu between performance and power use? i.e the efficiency sweet spot. I am currently using a 9800x3d which is great, but it's attached to my gaming PC, so it's both my gaming pc and nas on 24/7. I may upgrade my i3 14gen server cpu if the time saving is worth it.

[Hostile_18]

One thing I have noticed is everyone's settings struggle with the OP screenshots from the first 10 minutes of Forest Gump Remaster. The grain on the wall in the corridor and the fine detail on the beige wallpaper at the table looks different on all our settings to the source.

I think that's a rare case though.

[Z2697]

If the retail price is considered, I'd go with previous gen, for pure power efficiency though, the latest gen is almost always the best.
You can even try ARM! It's efficiency has been better than x86(x86_64/x64) for years, and the performance side has lots of improvement in recent years, but I never used any, except -- of course -- my phones.

[Hostile_18]

If the retail price is considered, I'd go with previous gen, for pure power efficiency though, the latest gen is almost always the best.
You can even try ARM! It's efficiency has been better than x86(x86_64/x64) for years, and the performance side has lots of improvement in recent years, but I never used any, except -- of course -- my phones.


Tech Powerup has some relevant charts. Gets a bit complicated price wise when I factor in already having a 9800x3d but having to run it on a secondary system, or that I already have an 1700 motherboard socket in my NAS. Still the graphs are interesting.

https://i.ibb.co/XxyXwSVP/efficiency-multithread.png (https://ibb.co/RTh25z7K)
https://i.ibb.co/cSzyvCxk/encode-h265.png (https://ibb.co/bMp6327Q)

[microchip8]

A few days ago, I read an article that the upcoming Intel Nova Lake desktop CPUs can draw up to 700 Watts!!! under full load! Jesus! Intel has totally lost it and has surpassed the power hungry Pentium 4 joke of many, many moons ago.

I would definitely NOT consider an Intel system for encoding. I'm on Linux, but their hybrid architecture still gives problems on Windows that the majority of people use.

What is the point of this hybrid E, LP and P cores? It's fine if the E/LP cores can significantly reduce power draw at idle, but once you start using the P cores for an extended period like during encoding, you might get a big surprise on your next power bill! :)

Yeah, AMD it is for the (near) future!

[microchip8]

One thing I have noticed is everyone's settings struggle with the OP screenshots from the first 10 minutes of Forest Gump Remaster. The grain on the wall in the corridor and the fine detail on the beige wallpaper at the table looks different on all our settings to the source.

I think that's a rare case though.

I'm not very sure, and this can go the other way, but x265 has a grain-optimized ratecontrol option --rc-grain - and also a --tune grain tuning. I have never used it myself but have read a few negative comments on here that it actually makes things worse. You might want to try it out on that problematic clip and see how it goes.

All in all, there's still a lot of improvements possible in x265, but it seems MultiCoreWare has (semi)-abandoned it :(

[Z2697]

rc-grain was designed for tune grain, or vice versa, whatever.
They aim for "homogeneous" of the QP in one frame so the grain won't look "blotchy".

[x264N00b]

One thing I have noticed is everyone's settings struggle with the OP screenshots from the first 10 minutes of Forest Gump Remaster. The grain on the wall in the corridor and the fine detail on the beige wallpaper at the table looks different on all our settings to the source.

I think that's a rare case though.
That's not very rare, it's a issue you have to deal with when it comes to high compression. It's about finding the right quality balance for the whole film where the bitrate for grainy content dosn't get bloated and flat and/or dark scenes with low contrast still remain with enough detail. So usually aq-mode 1 with CRF16 und preset slow delivers a overall very solid quality but sometimes it's just not enough. (bitrate)

What exactly is the bitrate in this encoded opening scene? You can analyze it with the tool ffbitrateviewer (second based view) or show it in MPC-HC. (view -> statistics -> current video bitrate)

I don't know how to solve the problem without overall decreasing the rate-factor even more or disabling cu-tree (usaually you chose a less low rate-factor then) or using x265 zones (https://x265.readthedocs.io/en/stable/cli.html#cmdoption-zones) for this specific scene. Or try x264 :)

[Z2697]

Random signal is random signal bro, you want better reconstruction you gonna need those bits. Period.
Or you fake it. Here comes Film Grain Synthesis! Try it out using SVT-AV1 --film-grain!

[GeoffreyA]

I also disable all lookahead-slices since I vaguely recall it has a negative impact on AQ?

It's supposed to be less efficient; but on my system, the performance gain is worth it.

Has anyone found a good cpu between performance and power use? i.e the efficiency sweet spot. I am currently using a 9800x3d which is great, but it's attached to my gaming PC, so it's both my gaming pc and nas on 24/7. I may upgrade my i3 14gen server cpu if the time saving is worth it.

On the x86 side, AMD has had higher performance per watt for the last few generations, though Intel has been closing the gap.

You can even try ARM! It's efficiency has been better than x86(x86_64/x64) for years, and the performance side has lots of improvement in recent years, but I never used any, except -- of course -- my phones.

Indeed, and Apple Silicon.

What is the point of this hybrid E, LP and P cores? It's fine if the E/LP cores can significantly reduce power draw at idle, but once you start using the P cores for an extended period like during encoding, you might get a big surprise on your next power bill! :)

When Intel was drowning in exorbitant power use, the E cores were a roundabout way of tackling efficiency, instead of just scrapping the P6-descended microarchitecture and starting from scratch. Complexity and sweeping the problem under the carpet by obfuscation was Intel's strategy.

Regarding the Pentium 4, Prescott was a disaster of power and heat with its 31-stage pipeline, but Northwood wasn't all that bad, and gave the Athlon stiff competition.

[microchip8]

It's supposed to be less efficient; but on my system, the performance gain is worth it.

It's not about AQ. I re-read the docs and it's about the precision of deciding when and where to place B-frames - the more slices used in lookahead, the less precise the encoder will be in deciding when to use B-frames. I thought it was about AQ :/

[Hostile_18]

I must admit I am kind of tempted to just encode the audio to Opus 768kbps (5.1/7.1) or 256kbps (Stereo), remove all other tracks/none English Subs, clean metadata and leave the video untouched as part of my flow process. Bad idea, good idea? I know audio trans-codes easily on Plex/Jellyfin but it will direct play on everything but Firefox and reduce file size, but I won't have to worry about losing quality.

Audio should be transparent at those settings shouldn't it? Just an idea I am mulling over. :)

[microchip8]

You can try lossless encoding with x265. If you go for lossy compression, which most of us do here, there's always something to nitpick about. As is always the case, lossy compression "loses" things and it will never represent the original input as 1:1 - after all, it discards stuff and the result looks slightly different. I'm not a perfectionist and also don't do "pixel peeping", but do value good, well done lossy encodes. I've spent many hours testing and tweaking settings before I came up with my current ones, and I'm very happy with them.

Also, most people look at films from a distance. When the encoding is decently done, you won't be able to spot much (if at all) difference from the original.

[Hostile_18]

You can try lossless encoding with x265. If you go for lossy compression, which most of us do here, there's always something to nitpick about. As is always the case, lossy compression "loses" things and it will never represent the original input as 1:1 - after all, it discards stuff and the result looks slightly different. I'm not a perfectionist and also don't do "pixel peeping", but do value good, well done lossy encodes. I've spent many hours testing and tweaking settings before I came up with my current ones, and I'm very happy with them.

Also, most people look at films from a distance. When the encoding is decently done, you won't be able to spot much (if at all) difference from the original.

Thanks for the information. What bit rate do you use? And that's true about quality. In my experience the only person that really cares about quality, is the server admin, the end users couldn't care less lol.

[GeoffreyA]

I must admit I am kind of tempted to just encode the audio to Opus 768kbps (5.1/7.1) or 256kbps (Stereo), remove all other tracks/none English Subs, clean metadata and leave the video untouched as part of my flow process. Bad idea, good idea? I know audio trans-codes easily on Plex/Jellyfin but it will direct play on everything but Firefox and reduce file size, but I won't have to worry about losing quality.

Audio should be transparent at those settings shouldn't it? Just an idea I am mulling over. :)

Over 192 kbps, for stereo, is generally transparent for Opus and AAC-LC. There should be no worry at 256 kbps.

[Hostile_18]

Over 192 kbps, for stereo, is generally transparent for Opus and AAC-LC. There should be no worry at 256 kbps.

I thought so from my testing, I presume in that case 768kbps will be the same for even 7.1 :)

[microchip8]

Thanks for the information. What bit rate do you use? And that's true about quality. In my experience the only person that really cares about quality, is the server admin, the end users couldn't care less lol.

I use CRF 23 for SDR and CRF 20 for HDR. When encoding Full HD and scaled-down 4k content to Full HD, the bitrate never exceeds 10 Mbps. It usually hovers between 3 and 6 Mbps

I don't use bitrate-based encoding like 1/2 pass do as estimating the correct bitrate upfront for a specific content is very, very difficult. I target a specific quality with CRF so all my encodes have more or less the same quality

[GeoffreyA]

I thought so from my testing, I presume in that case 768kbps will be the same for even 7.1 :)

I would think so. I encode film as stereo using QAAC TVBR109, generally yielding an average bitrate between 192 and 256 kbps. That's the most painless part of encoding; it's the video that's the bloody curse :)

In audio, my trouble has been the classic soft-dialogue problem after downmixing. The solution I found was using the loudnorm filter in two passes, aiming for an LRA of 14. Recently, though, I've been testing higher LRA values with Dune 2021.