Log in

View Full Version : x264 vs x265 shimmering


valnar
29th November 2024, 22:26
I've noticed that with sensible parameters, I seem to gain more shimmering or grain in x265 encoded videos vs x264.

Original source (https://www.dropbox.com/scl/fi/0261j4fu5jpqkkbqchrke/original-source.mkv?rlkey=9iytyvlcf2fimzxmftpgkbylw&dl=1)

x264 example (https://www.dropbox.com/scl/fi/5sllwfq5456ud1sz4wc48/Galactica.1980.S01e09.x264.mkv?rlkey=imm949eihxvnu4340fjt4jbaw&dl=1)

x265 example (https://www.dropbox.com/scl/fi/qqhztvz3uj431l02jin4r/Galactica.1980.S01e09.x265.mkv?rlkey=513qverky06009o6vk3zav4yn&dl=1)

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
29th November 2024, 23:15
The x264 example is more like the original source

So where's the original source?

valnar
29th November 2024, 23:42
I snipped it and updated my OP. It's slightly longer.

rwill
30th November 2024, 06:47
Have you tried lowering CRF for x265 ?

microchip8
30th November 2024, 09:13
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
30th November 2024, 13:47
Have you tried lowering CRF for x265 ?
Yep, all the way to CRF 17 and no changes.

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
30th November 2024, 13:58
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
30th November 2024, 15:31
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
30th November 2024, 16:45
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
30th November 2024, 17:00
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
30th November 2024, 17:33
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
30th November 2024, 18:00
Try --aq-mode 1

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

That's normal for plebbit. :D

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

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

Z2697
30th November 2024, 18:32
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
30th November 2024, 18:37
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
30th November 2024, 19:40
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
30th November 2024, 19:55
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
30th November 2024, 23:04
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.

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


So its the typical garbage in -> garbage out.


Agreed, they look equally bad to me.

valnar
30th November 2024, 23:11
Also look at the hood of the car when it starts. Original & x264 look smoother; x265 looks like it added more "sparkling".

rwill
30th November 2024, 23:52
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
1st December 2024, 00:08
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.

rwill
1st December 2024, 00:27
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.

You suggest you hold on to that Blu-ray.

valnar
2nd December 2024, 04:09
FWIW, I do not see that negative effect with 8-bit x265. I wonder if its my monitor.

benwaggoner
11th December 2024, 18:41
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.
Yeah, that would be 35mm 4:3 that had VFX laid back to film. Still the creators never imagined it would be played at anything beyond 480i analog broadcast, so grain and other fine details only visible at 1080p wouldn't have been a concern.

Doing a show of that age well requires a lot of remastering, redoing of VFX, etcetera.

buddha9
17th December 2024, 22:32
to compare 2 video I use https://github.com/pixop/video-compare.
also you can integrate on windows (read at bottom of the page)
I can't live without it :) (zoom, pan, play, ecc..)

https://i.imgur.com/VhQDOVG.png