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.

[Hostile_18]

I went to town with all the different AQ, Rskip and no Rect combinations to try and find the sweet spot. Encoding time is in the file names.

In example 1 AQ1 & 2 files are roughly the same. AQ3 modes add roughly + 20mb.
In example 2 AQ1 & 3 files are roughly the same. AQ2 modes add roughly +15mb.


Forrest Gump (1 minute sample)
https://i.ibb.co/mrRnTtwS/Screenshot-2026-02-21-115102.png (https://ibb.co/SD6ky08J)

Beau is Afraid (1 minute sample)
https://i.ibb.co/Gf8kHbLc/Screenshot-2026-02-21-124012.png (https://ibb.co/MytpB34M)

[Z2697]

Not using 10bit?

[microchip8]

I think your CRF of 17 is too low, but that's just me. Keep in mind that the CRF values between x264 and x265 are not the same!. For x264, many have settled on 18 (I use 21) while for x265 it's somewhere between 19 and 21 (I use 20 for hdr and 23 for sdr). For Full HD content, try to stay at or below 10 Mbps. Above that, it's just going to waste bitrate with very diminishing returns wrt quality.

[Hostile_18]

Not using 10bit?

Yeah using 10bit x265.

I think your CRF of 17 is too low, but that's just me. Keep in mind that the CRF values between x264 and x265 are not the same!. For x264, many have settled on 18 (I use 21) while for x265 it's somewhere between 19 and 21 (I use 20 for hdr and 23 for sdr). For Full HD content, try to stay at or below 10 Mbps. Above that, it's just going to waste bitrate with very diminishing returns wrt quality.

Even with CRF17 movies are around 11-13gb, some though go as low as 4gb and 3gb etc... I couldn't rest easy if they went even smaller lol. Im currently hosting full remux files, so it's around a 60% reduction, which I find is decent.

AQ3 with no Rect seems like one of the best in terms of high fidelity plus fast encode times.

[microchip8]

Yeah using 10bit x265.



Even with CRF17 movies are around 11-13gb, some though go as low as 4gb and 3gb etc... I couldn't rest easy if they went even smaller lol. Im currently hosting full remux files, so it's around a 60% reduction, which I find is decent.

AQ3 with no Rect seems like one of the best in terms of high fidelity plus fast encode times.

I find that too big for FHD, but again it's just me. That's a range for x264, not x265 which is better at compression. IMHO, your files should be between 3 and 7GB, depending on content. 11-13GB is something x264-ish

[x264N00b]

AQ3 with no Rect seems like one of the best in terms of high fidelity plus fast encode times.
That's 100% as expected because it uses the same preset with almost the same settings with a ~25% higher bitrate. In case of comparing different settings it's better to set a target bitrate -> 2-pass encoding instead of CRF.
Personally I feel like AQ3 just pushes the overall bitrate, you can also lower CRF about 1.0 or maybe 1,5 and you will get the same result with AQ1. In my tests it never gave me a quality boost in dark scenes =(

A mean VMAF-score of 98 or 99 ist super high, I think 95-96 is about to be transparent quality. But keep in mind it's a average score, you should look for the min VMAF also.

[Z2697]

Yes, the "dark bias" is not directly proportional to the luma, AQ3 bias has a broader range of effect than just improve dark blocks.

[Hostile_18]

Good point about AQ3 adding more bit rate, that's better spent in crf value. AQ seems to be the most consistent, in my admittedly very small sample size of two movies. All the values are pretty similar, but the time saving could be quite substantial, so maybe that is what I will focus on.

[VoodooFX]

Like others said, I think too that CRF 17 is too low for x265, if you need such low CRF then you better use x264.

[Hostile_18]

Theoretically could a lower crf (i.e the one I have) but with faster settings be the best of both worlds? The higher bitrate cancelling out the faster settings? I have a 120TB nas so its not essential that the file is in the smallest compression, just that its good enough savings, that it is worth doing.

I haven't considered average bit rate too much, perhaps that's an option, or is CRF the better choice for quality?

EDIT: x264 would be alot faster, but I have no idea the settings I'd use and don't want to spend 20+ hours of experimentation lol.

[VoodooFX]

Usually, at such high bitrates [CRF 17], x264 gives better subjective quality and it's much faster.
IMO, if you want to use CRF for x265 lower that ~20-21, then go with x264.

x264 settings are basically similar to x265 [minus x265 overcomplication].

[Hostile_18]

Usually, at such high bitrates [CRF 17], x264 gives better subjective quality and it's much faster.
IMO, if you want to use CRF for x265 lower that ~20-21, then go with x264.

x264 settings are basically similar to x265 [minus x265 overcomplication].

x264 is super fast on my CPU, but the blur (likely the AQ) on the edges is terrible, really bad.

[VoodooFX]

x264 is super fast on my CPU, but the blur (likely the AQ) on the edges is terrible, really bad.

Do you mean the issue when black borders are not cropped? Just crop them.

[Hostile_18]

Do you mean the issue when black borders are not cropped? Just crop them.

I can't because then it changes the PGS subs, which are location based.

[Z2697]

I use x265 at CRF 14 quite a lot, LOL

[VoodooFX]

I can't because then it changes the PGS subs, which are location based.

I think there is some workaround adding "virtual" black borders. Maybe some mkv flags?

[GeoffreyA]

Theoretically could a lower crf (i.e the one I have) but with faster settings be the best of both worlds? The higher bitrate cancelling out the faster settings? I have a 120TB nas so its not essential that the file is in the smallest compression, just that its good enough savings, that it is worth doing.

I haven't considered average bit rate too much, perhaps that's an option, or is CRF the better choice for quality?

EDIT: x264 would be alot faster, but I have no idea the settings I'd use and don't want to spend 20+ hours of experimentation lol.

Bitrate is king, so yes, if there are enough bits, it will outweigh preset speed. However, for archival-grade encodings, you'll not want to use faster presets.

Stick with CRF for quality. Use two passes to target a certain bitrate or file size, the tradeoff being that, if the bitrate isn't big enough, quality will vary from film to film.

For x264, try:

-level 4.1 -preset veryslow -tune film -crf 18/21 -aq-mode 3

If acceptable from size, quality, and speed points of view, the settings can be further tuned.

[microchip8]

Om my overclocked 4 GHz Ryzen 9 5900X, I've maxed out all possible settings and it's still 2x faster than realtime encoding for FHD. This is 'cause H.264/x264 is not that demanding and complex like HEVC/x265 is. The latter was a big upgrade over x264 with a lot of computational-heavy options. It's possible that in 5-10 years from now (ruff estimate), you'd see the same for x265 as is now the case with x264.

I'd take 10-bit x264 over 10-bit x265 most of the time. The problem is compatibility. 10-bit H.264 is virtually unsupported by most platforms/devices

[GeoffreyA]

Yes, with x264 on contemporary computers, there's no need to adjust for speed.

[Hostile_18]

AV1 is really fast on my 9800x3D as well, very close to x264.

At the moment I have two file flow settings ready to apply to my library. One just cleans up files (Removes all but main audio and commentary tracks, all non English subtitles, all embedded metadata, renames remaining tracks in a standardized format, sets forced subtitle if present as default etc). This takes about 10 minutes per movie.

The other option is similar but encodes video and audio, largely with the settings I posted a while back. This takes about 2.5 hours a movie, though occasionally one will flag that takes 4 plus hours. I'd love to encode in x264 but the border issues make it a total no go. On my main screen it can be a cm top and bottom of distortion, with a grainy film, if borders are not cropped.

[microchip8]

Have you tried lossless encoding with x265 as I suggested a few posts back?

If you're that concerned with tiny imperfections in lossy encoding and nitpick a lot about how grain/noise looks, try lossless encoding. From what I gathered, you're not that concerned about file size much...

[Hostile_18]

Have you tried lossless encoding with x265 as I suggested a few posts back?

If you're that concerned with tiny imperfections in lossy encoding and nitpick a lot about how grain/noise looks, try lossless encoding. From what I gathered, you're not that concerned about file size much...

I am not familiar with lossless encoding. My understanding was that anything that could be encoded is lossy, and that past a certain point, you get bigger file sizes than source and still not as accurate?

[microchip8]

I am not familiar with lossless encoding. My understanding was that anything that could be encoded is lossy, and that past a certain point, you get bigger file sizes than source and still not as accurate?

It works similarly like in audio, eg FLAC is lossless. In other words, it compresses frequently repeating data only that can be reconstructed perfectly upon decoding. So upon decoding, you get a perfect 1:1 output as if you're looking at the original. It usually makes the output by maybe ~10 or so percent smaller.

As opposed to lossy encoding where it discards data and poef, it's forever gone and can't be reconstructed upon decoding.

[benwaggoner]

AV1 is really fast on my 9800x3D as well, very close to x264.
With which encoder and preset??? AV1 is typically more like 10x the speed of x264. And AV1 has more fragile psychovisual tuning if you want material bitrate savings (although is certainly is improving year-on-year).[/QUOTE]

[benwaggoner]

It works similarly like in audio, eg FLAC is lossless. In other words, it compresses frequently repeating data only that can be reconstructed perfectly upon decoding. So upon decoding, you get a perfect 1:1 output as if you're looking at the original. It usually makes the output by maybe ~10 or so percent smaller.
For video content you can often get >50% reduction with a well-tuned lossy encode, depending on how much noise there is. Something like grain-free CGI can be shrunk a lot more.

[GeoffreyA]

With which encoder and preset??? AV1 is typically more like 10x the speed of x264. And AV1 has more fragile psychovisual tuning if you want material bitrate savings (although is certainly is improving year-on-year).

SVT-AV1 can be pretty fast, depending on the preset. So for a certain level of speed, it might well achieve better compression than x264.

[RanmaCanada]

SVT-AV1 can be pretty fast, depending on the preset. So for a certain level of speed, it might well achieve better compression than x264.

Sure, if you like a blurry mess. It's sadly still a major work in progress and I can get much better results with x265 currently than I can with AV1. AV1 has it's place, but it's still not ready for primetime as there is still far too much branching and side projects that keep getting abandoned, or they get merged and all your switches change and values invert.

AV1 is a mess.

[GeoffreyA]

Sure, if you like a blurry mess. It's sadly still a major work in progress and I can get much better results with x265 currently than I can with AV1. AV1 has it's place, but it's still not ready for primetime as there is still far too much branching and side projects that keep getting abandoned, or they get merged and all your switches change and values invert.

AV1 is a mess.

No doubt, x264 and x265 are the gold standard in quality, and SVT-AV1 still suffers from loss of detail and, worse, temporal strobing on grainy content. But from a pure compression-per-speed point of view, it can beat x264 and retain serviceable quality.

Intel's hardware implementation of AV1 seems to be roughly on par with SVT-AV1, bringing further speed.

[excellentswordfight]

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!
O.T
Pretty sure those 700W was for PL4 (which we have to wait and see what that will mean in practice), I dont think much can be said about the efficiency based on that, PL1 was still 150W.

But what we do know, is that Phanter Lake is the most efficient x86 design available, which is good indicator that Nova Lake looks quite promising, as this is the first time in a long time were Intel has passed AMD in efficiency, especially efficiency for maximum compute loads (Intel has always been good at efficiency at lower power states). Its also a prmocessing indicator that Intel is back on track with their manufacturing, as Phanter Lake is back (for the compute die) on their own process node.

https://phoronix.com/benchmark/result/intel-core-ultra-x7-358h-linux-cpu-performance/x265-bosphorus-4k-2.svgz

[microchip8]

For video content you can often get >50% reduction with a well-tuned lossy encode, depending on how much noise there is. Something like grain-free CGI can be shrunk a lot more.

Indeed, but I mentioned lossless because he wasn't happy with the lossy results, nitpicking this or that doesn't look as good as the source...

[Hostile_18]

Indeed, but I mentioned lossless because he wasn't happy with the lossy results, nitpicking this or that doesn't look as good as the source...

I wouldn't say nit picking, just testing and refining before been applied to the whole library. It makes sense to do all that first, before rolling it out on a larger scale.

[microchip8]

I wouldn't say nit picking, just testing and refining before been applied to the whole library. It makes sense to do all that first, before rolling it out on a larger scale.

Sure, but at some point, with lossy compression, you have to realize that you'll get imperfections. And you'll come across content that doesn't look as good as you'd expect while others do. I don't think there's a magical formula that works on 100% of all content.

[Hostile_18]

Sure, but at some point, with lossy compression, you have to realize that you'll get imperfections. And you'll come across content that doesn't look as good as you'd expect while others do. I don't think there's a magical formula that works on 100% of all content.

Yeah that is fair. I've come along way since my OP post, but there probably isn't much more extra quality to extract.

Grain is the enemy of all mortal men, especially if you aim to preserve it to hold the detail.

[benwaggoner]

Yeah that is fair. I've come along way since my OP post, but there probably isn't much more extra quality to extract.

Grain is the enemy of all mortal men, especially if you aim to preserve it to hold the detail.
QFT!

At least until we can get a good grain synthesis technology in a codec. AV1's was a good start, and AVFG1 is better yet, although still has limitations from a maximum 64x64 synthesized grain map used for everything.

[microchip8]

Yes, grain is a very evil thing, especially when it's added artificially. I don't get why some mastering people do this. Along with judder which I hate with a passion (do you see juddery when looking at the world? No? Why should it be different for video?) grain is my second enemy!

[rwill]

Grain is an artistic style element and you can encode it just fine, it just takes some trial and error when starting out. No need to hate on it just because you cannot encode it well yet.

[Z2697]

Can't agree with the obviously fake grain in some modern movies.
Real / legit "grains" are more acceptable, whether it's film grain or "digital grain" (noises from sensor).

[jpsdr]

Grain and/or noise, but i'll talk more about grain, is very relative to people.
For me, i don't like it. And even more on old movies, when film deteriorate with age, making them look worse (and sometimes a loooooot) than when they were released decades ago.
So, there is people who are not bothered with it, or even more like it, and there is people who don't... :D
This i why, on my personnal encodes, i remove grain on old film movies.

[microchip8]

Grain is an artistic style element and you can encode it just fine, it just takes some trial and error when starting out. No need to hate on it just because you cannot encode it well yet.

I do not hate it because I can't encode it - I have main grainy movies. I hate it because when I look at the world, I do not see it grainy. You do? Why should it be any different in video? Artistic or not, I do not like/want grain

[GeoffreyA]

For my part, I like grain, but it's a curse to encode. Artificial grain is less defensible, like artificial flooring made to look like wood.

Dune, 2021, is an interesting case: shot digitally, it was printed onto film and scanned back, giving a fine, grainy texture. From what I can see, the scenes on rainy Caladan are smooth, but as soon as the setting moves to Arrakis, the desert, the grain kicks in, usually fine, but thick during the visions—again, fitting to the context.

[microchip8]

Regarding judder, I read a survey that most people prefer it. Of course they do! They've been babyfed and brainwashed by Hollywood and TV in general that judder is good and is part of the "cinematic" experience. I strongly disagree with that. It gives me a headache and "eye problems" when a movie is juddery. The biggest judder I've seen is in Star Wars: Attack Of the Clones, where Obi Wan walks around the clone cocoons with the two Camino aliens. It is totally unwatchable, ugly and "shocking" when the camera pans. Luckily my TV has motion smoothing that gets rid of most judder but it still needs improvements.

Grains I can tolerate a bit if it's not that strong/in your face. I sometimes add a bit of noise to very clean encodings to not introduce banding, but this noise is not visible from a distance like thick grain. Besides wasting bits and slowing down the encoding, I do not see any benefits in grain. It does not look more "authentic" than a clean picture.

[GeoffreyA]

Judder is indeed tortuous to watch, and a major defect. By the same token, I don't like high-fps video, which makes my head spin. Proper 23.976 fps, without judder, looks pleasing.

[x264N00b]

Worst judder I've seen is in Pulp Fiction when Travolta walks through Jack Rabbit Slims and the camera , right after the "all right", moves from the posters to the singer. That must have something to do with the camera shutter speed, right?

[Hostile_18]

I'm not a fan of grain, but I don't go out my way to remove it as it nearly always takes away detail with it. I don't like that they add in grain on modern movies, there's lots of different artistic ways to set mood and ambience without putting a noise filter over it. Some games often have this fake grain filter also (along with depth of field, chromatic aberration etc). It seems like light grain films encode fine, heavy grain films are fine, but it does seem like everyone's settings struggled on the Forrest Gump remaster in terms of maintaining 1:1 grain structure.

I tweaked my settings (mainly the maxrate and bufsize) and have done about 40 movies now. Average reduction is 33% of source, which I am happy with. I just focused on high quality steaming versions that are typically encoded in real time. I decided on 5.1 sound 640 Opus as that had a maximum compatibility with my client devices (increasing the bit rate past >700kbps caused issues, without work around). If a movie really needs it the max limit is 7.5 gb an hour.

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=16000:vbv-bufsize=64000:vbv-init=0.9:rskip=2:rskip-edge-threshold=1

[benwaggoner]

Grain and/or noise, but i'll talk more about grain, is very relative to people.
For me, i don't like it. And even more on old movies, when film deteriorate with age, making them look worse (and sometimes a loooooot) than when they were released decades ago.
This is actually a serious issue. Older movies were meant to be projected against a perforated high gain screen from a 35mm film projector that vibrated and projected through glass, at 14 foot-lamberts (and typically less in most theaters).

An 8K film scan of the negative will have ENORMOUSLY more grain than anyone ever saw in a movie theater until the last 20 years, including the creatives. And if you remaster for HDR, that grain can wind up getting color corrected in ways that real-world grain never could have been.

It isn't "creative intent" to include much more sharp fine grain than the creators ever saw when making the film, or after its release. And it is a failure of creative intent to leave it there, in my (strong and correct) opinion.

[benwaggoner]

Worst judder I've seen is in Pulp Fiction when Travolta walks through Jack Rabbit Slims and the camera , right after the "all right", moves from the posters to the singer. That must have something to do with the camera shutter speed, right?
Shutter speed has some impact on judder; slower shutters mean more motion blur which mediates judder some. But the default is already a 180 degree shutter; 1/48th of a second exposure at 24 fps.

The real problem is that 24 fps was chosen because it was the lowest frame rate where lip sync didn't look artificial, in an era of heavy fixed position cameras and dollies. Handling fast motion wasn't a design goal, and it's not good at it. Hence the "seven second rule" and all the other cinematographic tricks to have things seem to be moving fast while not introducing judder. Like having a close up on a moving item and tracking the item while the fast moving background is outside the depth of field and thus blurry. Look how basketball in a movie is shot versus watching a game on TV. Movies have all these close ups of hands and balls going into a fixed basket and such, because an actual basketball game looks terrible and is hard to even see what is happening at 24p.

The Nyquist limit is the fundamental issue. At 24 fps, any motion that happens or changes in 1/12th of a second or less gets lost. Basketballs teleport instead of dribble or fly. Train wheels stop moving then start turning backwards as they pass 12 rpm.

[excellentswordfight]

Shutter speed has some impact on judder; slower shutters mean more motion blur which mediates judder some. But the default is already a 180 degree shutter; 1/48th of a second exposure at 24 fps.

The real problem is that 24 fps was chosen because it was the lowest frame rate where lip sync didn't look artificial, in an era of heavy fixed position cameras and dollies. Handling fast motion wasn't a design goal, and it's not good at it. Hence the "seven second rule" and all the other cinematographic tricks to have things seem to be moving fast while not introducing judder. Like having a close up on a moving item and tracking the item while the fast moving background is outside the depth of field and thus blurry. Look how basketball in a movie is shot versus watching a game on TV. Movies have all these close ups of hands and balls going into a fixed basket and such, because an actual basketball game looks terrible and is hard to even see what is happening at 24p.

The Nyquist limit is the fundamental issue. At 24 fps, any motion that happens or changes in 1/12th of a second or less gets lost. Basketballs teleport instead of dribble or fly. Train wheels stop moving then start turning backwards as they pass 12 rpm.
It should also be noted that your TV will impact this quite a bit as well, especially in recent years. LCD:s/plasma has historically been quite slow, adding quite a bit of motionblur themself, smoothing over issues created low framerates. So modern pannels with faster pixels, and especially Oleds are way less forgiving when things like the the 7-second rule is broken, which can lead to stutter, even if they displaychain is setup in the correct way to display 23.976/24p content.

[benwaggoner]

It should also be noted that your TV will impact this quite a bit as well, especially in recent years. LCD:s/plasma has historically been quite slow, adding quite a bit of motionblur themself, smoothing over issues created low framerates. So modern pannels with faster pixels, and especially Oleds are way less forgiving when things like the the 7-second rule is broken, which can lead to stutter, even if they displaychain is setup in the correct way to display 23.976/24p content.
Indeed. Honestly, the more I learn about display panels and tone mapping and the whole display chain, the more it feels like some kind of dark alchemy. It only seemed straightforward before I was paying deep attention.

[Hostile_18]

I upgraded my server to a Ultra i7 270k Plus for $300. It beats out my 9800x3d in my gaming rig at encoding x265 by a massive 40%. Plus I wont have to have both my server and gaming rig on at the same time... although actually maybe I cohld have them both converting. Decisions.

I have a choice now between much faster than real time encoding or tweaking my settings to be even higher quality at the same speed. :D

[GeoffreyA]

The 270K and 250K have been getting good reviews and are disruptive for the price, particularly the latter. AMD needs to wake up, having grown greedy at the top.

[Hostile_18]

Just got up and running now. I am actually getting +80% speed increase from my 9800x3d. Very happy with that.

| 1 | AMD 9800X3D | 1:22 (82s) | Intel i7 Plus 270K | 0:44 (44s) | 1.86× | 86.4%
| 2 | AMD 9800X3D | 1:31 (91s) | Intel i7 Plus 270K | 0:52 (52s) | 1.75× | 75.0%
| 3 | AMD 9800X3D | 1:27 (87s) | Intel i7 Plus 270K | 0:49 (49s) | 1.78× | 77.6%
| 4 | AMD 9800X3D | 1:07 (67s) | Intel i7 Plus 270K | 0:37 (37s) | 1.81× | 81.1%

[RanmaCanada]

Just got up and running now. I am actually getting +80% speed increase from my 9800x3d. Very happy with that.

| 1 | AMD 9800X3D | 1:22 (82s) | Intel i7 Plus 12700K | 0:44 (44s) | 1.86× | 86.4%
| 2 | AMD 9800X3D | 1:31 (91s) | Intel i7 Plus 12700K | 0:52 (52s) | 1.75× | 75.0%
| 3 | AMD 9800X3D | 1:27 (87s) | Intel i7 Plus 12700K | 0:49 (49s) | 1.78× | 77.6%
| 4 | AMD 9800X3D | 1:07 (67s) | Intel i7 Plus 12700K | 0:37 (37s) | 1.81× | 81.1%

To be expected as it has considerably more cores. The Gracemont efficiency cores were basically Skylake cores so with the improvements on Skymount (32% IPC lift over Gracemont) they are now basically Alder Lake cores. The 9800x3d has a multi-core passmark score of 39978 while the 270k Plus has a passmark multi-core score of 68076. A whopping 41% difference. The single thread performance is also superior with the 270k plus at 5011 and the 9800x3d at 4425. And surprise it also uses double the power as the 9800x3d.

[Z2697]

12700k is a different thing and existing since long before 270k, confused?

[Hostile_18]

12700k is a different thing and existing since long before 270k, confused?

Oh crap that's me relying on good old faithful chat gpt for the table lol. I'll correct. It is the new 270k Plus results.

[RanmaCanada]

Oh crap that's me relying on good old faithful chat gpt for the table lol. I'll correct. It is the new 270k Plus results.

Just more proof as to why no one should be using AI..

Stop it, please.

[Hostile_18]

Almost ready to roll out my encodes with my new settings. Using a base of CRF17 as I don't want small encodes i.e Barbie been 5gb, Captain Marvel 3.5gb at CRF 18 etc. I do want to put a cap on it though to make the saving worthwhile on grain heavy films. Can't really decide between (incl audio) 12640, 13640, 14640,15640, 16640kbps.

I'll be encoding 1080p bluray TV and film. The highest values on the lowest gb shows with grain can "only" reduce by about one third if that makes a difference. Storage isn't a concern (100tb) but I do want to make it worthwhile, while preserving a "very good" level of quality (to be fair all bitrates are scoring at least 93 vmaf).

Any recommendations what bit rate cap I should go with? (Currently using double given bit rate as the buffer). Would a CRF of 17 + 12640kbps be bad with it hitting the limit more? Or would it not matter given the bit rate is still relatively high? In testing I saw no issues with any of the bit rates to my eyes.

[Hostile_18]

Ok so I am ready to roll now. I have an automated flow that pretty much handles everything. I am using CRF18 (no cap), with a fallback to CRF19 if a encode ends up being bigger than source. This may be obvious to most but just in case anyone doesn't know when I was experimenting with a cap, at the same bit rate, it doesn't allocate to scenes as well as it does unrestricted. It led to visual artifacts, although it was quite a small compromise given the quality to file size ratio. Also AQ2 though its scores higher with VMAF testing, isn't as good as AQ1 IMO. I had some clean content (smooth walls) in Beau is Afraid and AQ2 literally halved the bit rate, I guess because it thought it didn't need any more, but on visual inspection it too introduced artifacts.

So this is my 1080p Remux encode;

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=57:deblock=-3,-3:no-sao=1

Can anyone advise what a comparable 2160p encode would look like? I know enough to change CTU to 64, but not too much more. What profile level, what CRF is the 2160p equivalent? Do I need to do anything different for files that have both Dolby Vision and HDR10+ etc? :)

PS thank you so much, everyone that's helped, I've learned so much over the last few months.

[GeoffreyA]

With reference to the cap, rather set the IDC level, as you did; 4.1 puts quite a high cap of 50 Mbps. You'll notice that even with relatively low average bitrates, peak bitrate can shoot up into the tens of megabits for a frame or two.

[Hostile_18]

With reference to the cap, rather set the IDC level, as you did; 4.1 puts quite a high cap of 50 Mbps. You'll notice that even with relatively low average bitrates, peak bitrate can shoot up into the tens of megabits for a frame or two.

Good to know, thanks.

Does this look good for my 2160p string? (to match a similar quality to my 1080p one) :)

libx265 -pix_fmt yuv420p10le -crf 18 -preset slow -x265-params aq-mode=1:no-open-gop=1:high-tier=1:level-idc=5.1:bframes=6:subme=4:rc-lookahead=120:pbratio=1.25:ctu=64:merange=57:deblock=-3,-3:no-sao=1:hdr10=1:hdr10-opt=1:repeat-headers=1:aud=1:colorprim=bt2020:colormatrix=bt2020nc:transfer=smpte2084

[GeoffreyA]

To be honest, I don't have experience encoding BT.2020 content, so will let other forum members give the definitive answer. You might be able to raise the CRF further since the resolution is 2160p.

[Blue_MiSfit]

ctu 64 is the default on veryfast and anything slower so you can just omit that setting entirely :)

Such strong negative deblock values are not in line with what I've seen elsewhere and I typically keep the defaults.

As always, set CRF to your preference.

[Hostile_18]

My encoding is going very well thank you all. I have processed 500 films! Sticking with 1080p at the moment, but we shall see in the future.

Now I have moved on to my TV shows I am just wondering how to handle the odd 1080i content? Do I need to add or modify anything to my string or can I process the same as I have been doing? Also is there an easy way to identify 1080i content? I think it's just a few odd British TV shows.

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=57:deblock=-3,-3:no-sao=1

[GeoffreyA]

500 films! Impressive.

Since May, I've made it through only 13, having finalised my settings (until next time), and ended up using different codecs depending on the film:

Blade Runner: x265
Blade Runner 2049: x265
Cube: SVT-AV1-HDR
Dune: x264
Dune Part Two: x264
Interstellar: x264
Last Night in Soho: SVT-AV1-HDR
Lost Highway: x265
Mr. Nobody: SVT-AV1-HDR
Mulholland Drive: x264
The Cell: SVT-AV1-HDR
The Matrix: x264
The Substance: x264

SVT-AV1-HDR's tune=0 worked very well, and I considered it almost as "safe" as x264.

[Columbo]

500 films! Impressive. For sure! I once started a project to clean up and reencode every episode of Rocky and Bullwinkle. I ran out of energy to complete the job. :(

[Z2697]

My encoding is going very well thank you all. I have processed 500 films! Sticking with 1080p at the moment, but we shall see in the future.

Now I have moved on to my TV shows I am just wondering how to handle the odd 1080i content? Do I need to add or modify anything to my string or can I process the same as I have been doing? Also is there an easy way to identify 1080i content? I think it's just a few odd British TV shows.

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=57:deblock=-3,-3:no-sao=1

Interlacing + x265 is no-no.
Just deinterlace it or... use x264 MBAFF instead.

[GeoffreyA]

For sure! I once started a project to clean up and reencode every episode of Rocky and Bullwinkle. I ran out of energy to complete the job. :(

I'd need a few lifetimes to complete 500. I want to tackle Star Trek: Voyager. Someday...

[Hostile_18]

I'd need a few lifetimes to complete 500. I want to tackle Star Trek: Voyager. Someday...

Thank you all. Well it's all automated with Fileflows. It took a while to setup and a lot of testing but once that is done, everything it processed automatically 24/7. Only have to manually intervene very occasionally.

As for Voyager, I'll send you a PM.

@Z2697 I am not sure how to deinterlace something, but I'll look into it. :)

[excellentswordfight]

My encoding is going very well thank you all. I have processed 500 films! Sticking with 1080p at the moment, but we shall see in the future.

Now I have moved on to my TV shows I am just wondering how to handle the odd 1080i content? Do I need to add or modify anything to my string or can I process the same as I have been doing? Also is there an easy way to identify 1080i content? I think it's just a few odd British TV shows.

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=57:deblock=-3,-3:no-sao=1


500 films! Impressive.

Since May, I've made it through only 13, having finalised my settings (until next time), and ended up using different codecs depending on the film:

Blade Runner: x265
Blade Runner 2049: x265
Cube: SVT-AV1-HDR
Dune: x264
Dune Part Two: x264
Interstellar: x264
Last Night in Soho: SVT-AV1-HDR
Lost Highway: x265
Mr. Nobody: SVT-AV1-HDR
Mulholland Drive: x264
The Cell: SVT-AV1-HDR
The Matrix: x264
The Substance: x264

SVT-AV1-HDR's tune=0 worked very well, and I considered it almost as "safe" as x264.
Ive done about 400 titles (300 hd, 100 uhd) since 2022 for my plex server. I do x264 preset slower+custom settings crf16-19 for blurays and x265 preset slow+custom settings crf15-19 for uhd-bluray (I do a complexity pass to judge crf value as i try to stay under 15Mbps for hd and 30Mbps for uhd). AC3 384K for <5.1, AC3 640K for 5.1, EAC3 768K for >5.1 (and/or atmos) with english (non-sdh) srt subtitles, But im pretty much done now, I now have pretty much my dream movie libray on my plex, in a efficent and streamable format.

@Z2697 I am not sure how to deinterlace something, but I'll look into it. :)
If you dont wanna go into a very deep rabit hole, easiest is to just do it with bwdif in ffmpeg, especially if you already use ffmpeg in your workflow.

[Hostile_18]

Thanks!

So I've introduced a Interlaced content check into my work flow. It will test and confirm if it detects 10% of interlaced frames are present. Does this sound right? I can change the percentage of frames to whatever I like.

Once its detected it will deinterlace before encoding takes place. There are four deinterlace methods to select from and I have no idea what to select "Send Frame", "Send Field", "Send Frame No Spatial" and finally "Send Field no Spatial".

Is this process quite destructive to image quality? :)

[Z2697]

Is this process quite destructive to image quality? :)

It depends on the method... you can potentially throw out one half (of already halved) information.
But really, when it's interlaced, the damage is already done.

"Safe" option is send field.

[GeoffreyA]

As for Voyager, I'll send you a PM.


Many thanks.

Ive done about 400 titles (300 hd, 100 uhd) since 2022 for my plex server. I do x264 preset slower+custom settings crf16-19 for blurays and x265 preset slow+custom settings crf15-19 for uhd-bluray (I do a complexity pass to judge crf value as i try to stay under 15Mbps for hd and 30Mbps for uhd). AC3 384K for <5.1, AC3 640K for 5.1, EAC3 768K for >5.1 (and/or atmos) with english (non-sdh) srt subtitles, But im pretty much done now, I now have pretty much my dream movie libray on my plex, in a efficent and streamable format.

Solid work at 400 films. For audio, I use QAAC TVBR109.

[x264N00b]

Now I have moved on to my TV shows I am just wondering how to handle the odd 1080i content? Do I need to add or modify anything to my string or can I process the same as I have been doing? Also is there an easy way to identify 1080i content? I think it's just a few odd British TV shows.

Workflow depents on:
a.) video is nativ interlaced
b.) video is progressive but encoded as interlaced
c.) video is telecine
d.) video is field shifted
e.) weird mix of anything

I dunno how british TV shows are usually broadcasted. Good guide to analyse whether a video is interlaced or not can be found here:
https://forum.selur.net/thread-2183-post-14122.html#pid14122
First advice is to never trust what mediainfo says.

[Z2697]

Workflow depents on:
a.) video is nativ interlaced
b.) video is progressive but encoded as interlaced
c.) video is telecine
d.) video is field shifted
e.) weird mix of anything

I dunno how british TV shows are usually broadcasted. Good guide to analyse whether a video is interlaced or not can be found here:
https://forum.selur.net/thread-2183-post-14122.html#pid14122
First advice is to never trust what mediainfo says.

Interlacing is really an abomination!

[microchip8]

Interlacing is really an abomination!

In these days, yes. And whoever uses it for content is an idiot. But back in the days, it was a necessity. It's pity is has survived until today!

[Z2697]

In these days, yes. And whoever uses it for content is an idiot. But back in the days, it was a necessity. It's pity is has survived until today!

My hot take will be that maybe the interlaced scan is a necessity for CRT (or more like a compromise), but the true-interlaced content is a HACK upon this! :devil:

[x264N00b]

Needed for devices that max. support AVC level 4.1. 1080p50/60 ist not supported then, you can go interlaced or reduce the resolution to 720p or throw away half of the framerate.

[Z2697]

Needed for devices that max. support AVC level 4.1. 1080p50/60 ist not supported then, you can go interlaced or reduce the resolution to 720p or throw away half of the framerate.

The same/better can be achieved by just have 1920x540p...
I would even rather have 1280x720p than 1920x1080i.

Just a rant by someone who's not older than the MPEG-4.

[GeoffreyA]

I think it's the greatest curse in legacy video.