x264 vs x265 shimmering

[valnar]

I've noticed that with sensible parameters, I seem to gain more shimmering or grain in x265 encoded videos vs x264.

Original source

x264 example

x265 example

Right after the video starts, look at the barn redwood. It has a bit of flicker on the x265 video. The x264 example is more like the original source, which is more "stable".

Yes there is some slight handheld camera movement going on, but nevertheless x264 handles it better.

I've played with many smoothing/non-smoothing parameters in the x265 lexicon and cannot seem to stop this. Any ideas?

edit: I just realized my source cut is slightly longer than the encode examples, so sizes are slightly off.

[Z2697]

Originally Posted by valnar

The x264 example is more like the original source

So where's the original source?

[valnar]

I snipped it and updated my OP. It's slightly longer.

[rwill]

Have you tried lowering CRF for x265 ?

[microchip8]

You should really use rc-grain ratecontrol in x265 in cases there's (a bit of) film grain. And also -tune grain as a tuning. These are designed to prevent pulsating of grain stuff

[valnar]

Originally Posted by rwill

Have you tried lowering CRF for x265 ?

Yep, all the way to CRF 17 and no changes.

Originally Posted by microchip8

You should really use rc-grain ratecontrol in x265 in cases there's (a bit of) film grain. And also -tune grain as a tuning. These are designed to prevent pulsating of grain stuff

I tried --tune grain and it blew up the size of the video encode, but no changes to the shimmering. I verified that enabled rc-grain (whereas normally it is off). This example isn't grain anyway.

Here is the encode parameters with simply the slow preset and tune grain. Has anyone else tried it to see what I'm talking about?

x265 3.6+1-aa7f602f7:[Windows][GCC 13.2.0][64 bit] 10bit
Encoding settings     : cpuid=1111039 / frame-threads=4 / numa-pools=20 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1466x1080 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-eob / no-eos / no-hrd / info / hash=0 / temporal-layers=0 / open-gop / min-keyint=24 / keyint=240 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=4 / scenecut=40 / no-hist-scenecut / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / no-sao / no-sao-non-deblock / rd=4 / selective-sao=0 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=4.00 / psy-rdoq=10.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=22.0 / qcomp=0.60 / qpstep=1 / stats-write=0 / stats-read=0 / ipratio=1.10 / pbratio=1.00 / aq-mode=0 / aq-strength=0.00 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=64 / rc-grain / qpmax=69 / qpmin=0 / const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=1 / chromaloc-top=0 / chromaloc-bottom=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass / no-mcstf / no-sbrc

[valnar]

original source.........= 63,079 KB
x265 CRF 17.............= 39,980 KB
x265 CRF 22 tune-grain..= 28,135 KB
x265 CRF 22.............= 15,181 KB
x264 CRF 22.............= 18,931 KB

Now granted all these have a compressed AAC audio track, but it's the same one. If that's what tune-grain does, I might as well keep it in x264, perhaps even going up to CRF 21.

All presets are slow.

[microchip8]

disable SAO, lower deblock to -3,-3, lower CTU size from 64 to 32, set intra & inter depth to 4, enable intra & inter refine and set refine-mv to 3... try again

[valnar]

Originally Posted by microchip8

disable SAO, lower deblock to -3,-3, lower CTU size from 64 to 32, set intra & inter depth to 4, enable intra & inter refine and set refine-mv to 3... try again

Did you try it? That didn't seem to help. It also increased the size up to 21,817KB which pushed it bigger than the (better looking) x264 encode.

I always thought deblock -3,-3 was a no-no in all instances?

[microchip8]

the deblocker in x265 washes out too much at its default values as does sao. if you want to preserve detail (inc. noise), it's recommended to lower it and disable sao and go from there. Not sure who told you that -3,-3 is a no-go - I use i all the time. That's simply not true. Unfortunately, x265 cannot match the detail and preservation of x264, no matter how much you tweak and play with the setting.

It increased the size because these settings are meant to preserve as much detail as possible in x265, which naturally increases the bitrate for obvious reasons. You can increase CRF a bit to lower it. I don't think you'll notice much difference. In the end, if you want best preservation of detail (and noise is seen as a form of detail even though all encoders hate it), you will have to stick to x264 and give up on x265. The latter simply can't match x264

[valnar]

Originally Posted by microchip8

In the end, if you want best preservation of detail (and noise is seen as a form of detail even though all encoders hate it), you will have to stick to x264 and give up on x265. The latter simply can't match x264

Thanks for that. I always thought so too. You can't dare mention that on Reddit without getting downvoted. I always felt that x264 looked better at normal CRF ranges, but couldn't put my finger on it until I saw a sample like this.

I've also tried everything I can do with x265 and Band of Brothers, but nothing helps. Finally decided on x264 and bigger files.

[VoodooFX]

Try --aq-mode 1

Originally Posted by valnar

...on Reddit... ..downvoted.

That's normal for plebbit.

Originally Posted by valnar

I always felt that x264 looked better at normal CRF ranges.

I think at CRF 22-23 x265 should be better than x264.

[Z2697]

Put a real "pixel-to-pixel" source, or just tell us your cropping and trimming parameters. Not gonna figure that out myself.
On top of that, I think we are not sure about what is the shimmering you are talking. Be more specific.
Thus the advises so far are at best educated guesses, I presume.

But well, I think I've heard enough of x264 is better at preserving details than x265 theory. Bye.

[Z2697]

tune grain is some crazy parameters for extremely special cases. (IMHO)
sao is already disabled in you examples.

Now think how good these guesses are, when he told you to do crazy thing, or to do what you've already done.

Until you make you question a good question, you won't get any good answers, or at least good guesses.

[rwill]

The 'source' seems to have problems with shutter speed effects and the source encode pictures, at least on the barn, go "grain,blur,blur,blur,grain,blur,blur,blur,grain,blur...".

So its the typical garbage in -> garbage out.

x264 seems to not spend bits enough bits to remove some grain introduced by the grain frames and the thread starter seems to like that.

[valnar]

Originally Posted by Z2697

Put a real "pixel-to-pixel" source, or just tell us your cropping and trimming parameters. Not gonna figure that out myself.
On top of that, I think we are not sure about what is the shimmering you are talking. Be more specific.
Thus the advises so far are at best educated guesses, I presume.

But well, I think I've heard enough of x264 is better at preserving details than x265 theory. Bye.

I couldn't have been more specific(?). The cropping is automatic though.

[Z2697]

Originally Posted by valnar

I couldn't have been more specific(?). The cropping is automatic though.

Apart from not being able to identify the shimmering because the source is already flickring liek a hell, I also can't be sure that we interpret the word "shimmering" the same.

Originally Posted by rwill

The 'source' seems to have problems with shutter speed effects and the source encode pictures, at least on the barn, go "grain,blur,blur,blur,grain,blur,blur,blur,grain,blur...".

This is what being specific looks like

Originally Posted by rwill

So its the typical garbage in -> garbage out.

Agreed, they look equally bad to me.

[valnar]

Also look at the hood of the car when it starts. Original & x264 look smoother; x265 looks like it added more "sparkling".

[rwill]

I looked at the original 'source' .mkv that was provided and noticed that it starts with a 'blur' picture followed by a 'grain' picture. I would have expected it to start with a 'grain' keyframe if its encoded from a clean mezzanine. So encoding wise the 'source' most likely already has moderate to heavy generational loss.

Just don't bother.

[valnar]

Galactica 1980 Blu-ray. It’s an older TV show, but the point is I don’t wanna have anything extra added that’s not there.