Severe Blocking in fades when using --nr option.

[SquallMX]

I was trying to reduce noise a little bit in a recent 4K movie, but even a low amount on "--nr" value creates awful blocking during fade-ins:

https://i.imgur.com/an3SgCS.jpg

https://1drv.ms/u/s!AiCgDguh7E_OgakrNW2mjKIfggDKGA?e=wWhYIP

x265 3.5+36-1f2c8da77:[Windows][GCC 11.2.0][64 bit] 10bit

cpuid=1111039 / frame-threads=4 / numa-pools=16 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x1632 / interlace=0 / total-frames=153558 / level-idc=50 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / repeat-headers / annexb / aud / no-eob / no-eos / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=6 / keyint=60 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=24 / lookahead-slices=8 / scenecut=40 / no-hist-scenecut / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-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=100 / no-constrained-intra / no-strong-intra-smoothing / max-merge=3 / limit-refs=1 / limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=-1:-1 / sao / sao-non-deblock / rd=3 / selective-sao=2 / early-skip / rskip / rskip-edge-threshold=0.030000 / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=1.00 / psy-rdoq=1.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=22.5 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=54000 / vbv-bufsize=46000 / vbv-init=0.9 / min-vbv-fullness=50.0 / max-vbv-fullness=80.0 / crf-max=0.0 / crf-min=0.0 / ipratio=1.40 / pbratio=1.30 / aq-mode=3 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=9 / transfer=16 / colormatrix=9 / chromaloc=1 / chromaloc-top=2 / chromaloc-bottom=2 / display-window=0 / master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50) / cll=668,337 / 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 / hist-threshold=0.03 / no-opt-cu-delta-qp / no-aq-motion / hdr10 / 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 / limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / 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

Removing "--nr" fixes the issue completely:

https://i.imgur.com/aBPc1cL.jpg

https://1drv.ms/u/s!AiCgDguh7E_OgakqaWhBNvC-WMbrCw?e=NpCRdX

x265 3.5+36-1f2c8da77:[Windows][GCC 11.2.0][64 bit] 10bit

cpuid=1111039 / frame-threads=4 / numa-pools=16 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x1632 / interlace=0 / total-frames=153558 / level-idc=50 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / repeat-headers / annexb / aud / no-eob / no-eos / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=6 / keyint=60 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=24 / lookahead-slices=8 / scenecut=40 / no-hist-scenecut / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-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 / no-strong-intra-smoothing / max-merge=3 / limit-refs=1 / limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=-1:-1 / sao / sao-non-deblock / rd=3 / selective-sao=2 / early-skip / rskip / rskip-edge-threshold=0.030000 / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=1.00 / psy-rdoq=1.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=22.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=54000 / vbv-bufsize=46000 / vbv-init=0.9 / min-vbv-fullness=50.0 / max-vbv-fullness=80.0 / crf-max=0.0 / crf-min=0.0 / ipratio=1.40 / pbratio=1.30 / aq-mode=3 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=9 / transfer=16 / colormatrix=9 / chromaloc=1 / chromaloc-top=2 / chromaloc-bottom=2 / display-window=0 / master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50) / cll=668,337 / 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 / hist-threshold=0.03 / no-opt-cu-delta-qp / no-aq-motion / hdr10 / 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 / limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / 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

Any workaround?

[RanmaCanada]

The source is probably too dirty for you to do anything with it. It's possible the 1080p version might be better, at least from the reviews it had being that it was crisp and clean. No reviews on the 4k version of this movie, yet. It is possible they screwed up the mastering and upscale by not going back to the original film and rescanning it, and just used tech.

[SquallMX]

Even if thats the case, --NR should not produce that kind of blocking, looks like some bug on the --NR algorithm.

[rwill]

Any workaround?

Hm, "rc=crf / crf=22.5 / vbv-maxrate=54000 / vbv-bufsize=46000".

How large is the offending frame in bytes with and without --nr ?

Different mechanics could cause this, I think the best would be to create a small sample and command line that is able to reproduce the problem and send it to a x265 developer.

[SquallMX]

Hm, "rc=crf / crf=22.5 / vbv-maxrate=54000 / vbv-bufsize=46000".

How large is the offending frame in bytes with and without --nr ?

Different mechanics could cause this, I think the best would be to create a small sample and command line that is able to reproduce the problem and send it to a x265 developer.

Is there a tool to analize a H265 bitstream?, removing "vbv-maxrate" and "vbv-bufsize" does nothing.

[rwill]

Is there a tool to analize a H265 bitstream?, removing "vbv-maxrate" and "vbv-bufsize" does nothing.

Well x265 has --csv <filename> and --csv-log-level <integer> for per frame stats.

[excellentswordfight]

From a quick look it seems like you have quite a few custom settings, do you get the same issue when just using something like --preset slow --crf 22 --hdr-opt + the hdr flags together with those --nr settings? Just to see if there is something with nr or if its nr in combination with some other setting.

[Selur]

In case of Avisynth or Vapoursynth were used, I would suspect this is related to some issue with the used source filter not properly seekable.
But this might also be some bug in x265 or your system.
Share a sample of the source, the settings you used in which program. Others, then, can try and see whether they can reproduce the problem.

[SquallMX]

In case of Avisynth or Vapoursynth were used, I would suspect this is related to some issue with the used source filter not properly seekable.
But this might also be some bug in x265 or your system.
Share a sample of the source, the settings you used in which program. Others, then, can try and see whether they can reproduce the problem.

Hi, here is the sample:
https://1drv.ms/u/s!AiCgDguh7E_OgakudMsfoCrje4AZrg?e=s4HdK8

Today I found that only happens if using "--rskip 2" and "nr-inter" at the same time, "nr-intra" is not causing problems.

These are my settings:

"D:\RipBot264\Tools\ffmpeg\bin\ffmpeg.exe" -loglevel panic -i "E:\Temp\RipBot264temp\job3\job3.avs" -strict -1 -f yuv4mpegpipe - | "D:\RipBot264\tools\x265\x265_x64.exe" --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)" --max-cll "668,337" --crf 22 --fps 24000/1001 --frames 94 --sar 1:1 --profile main10 --output-depth 10 --no-strong-intra-smoothing --no-rect --aud --limit-modes --aq-mode 3 --hdr10 --no-opt-ref-list-length-pps --hdr10-opt --no-opt-qp-pps --no-sao --chromaloc 2 --rskip 2 --rdoq-level 2 --rskip-edge-threshold 3 --keyint 60 --min-keyint 6 --log2-max-poc-lsb 8 --dynamic-refine --rc-lookahead 24 --level-idc 5 --psy-rdoq 1.00 --psy-rd 1.00 --vbv-maxrate 54000 --vbv-bufsize 46000 --deblock -1 --nr-inter 100 --ctu 64 --merange 57 --y4m --output "E:\Temp\RipBot264temp\job3\video.265" -


Interestingly if I use Loop(10) in my Avisynth script, blocking only happens in the first loop.

[benwaggoner]

I don't recommend using --nr, as that just sets --nr-intra and --nr-inter to the same values. In my experience, --nr-intra should only be 25-50% of --nr-inter so as not to reduce too much intra-coded detail. That could well be what's happening here. x264's --nr maps to x265's --nr-inter only, FWIW. x264 doesn't have any --nr-intra equivalent.

The --nr modes are essentially adaptive deadzones for high frequency components. The higher the values, the softer and less accurately really high frequencies get encoded, in a more compression-friendly way than a preprocessed denoising (although the core algorithm is much less sophisticated, so using a good temporal noise reduction preprocesor can still yield better net results). They can improve quality on net by lowering QPs because the content is easier to compress, and the improved quality of lower frequency components can more than make up for some missing high frequency detail.

--nr-intra only applies to intra-coded TUs. So all an IDR or I-frame, and the intra-coded parts of P, B, and b frames. This will soften the original reference for every inter-coded TU, which is a pretty brute force way to lower bitrates or QPs. It also can't distinguish between what is very detailed static texture (which can be efficiently encoded from an intra reference) and random noise (which can make encoding much harder and can really drive down quality or drive up bitrates).

--nr-inter only applies to inter-coded TUs, so everything that references another frame. For normal content, high frequency components that would be residual are for the most part random noise, like grain. Raising --nr-inter will eliminate some of those, which can save a lot of bits, and actually improve quality. --nr-inter can damp down grain "swirlies" and grain enhancement seen when QPs get too high.

I find most of the value from --nr-inter, and plenty of times I'll use it without any --nr-intra at all. I use --nr-intra when --nr-inter is doing what I want, but there's some perceptible difference between inter and intra coded elements that becomes visible. So I raise --nr-intra up to where I'm not seeing keyframe strobing or mixed detail within a frame. If --nr-intra is too high, like the same as nr-inter, the detail loss is a lot bigger than bit savings, and counterproductive. With a higher --nr-inter, some of the grain is preserved in intra, and then the higher --nr-inter won't try to code the differences in the residual, so the grain texture will be preserved a lot better, just without randomly changing every frame as much.

[SquallMX]

I don't recommend using --nr, as that just sets --nr-intra and --nr-inter to the same values. In my experience, --nr-intra should only be 25-50% of --nr-inter so as not to reduce too much intra-coded detail. That could well be what's happening here. x264's --nr maps to x265's --nr-inter only, FWIW. x264 doesn't have any --nr-intra equivalent.

The --nr modes are essentially adaptive deadzones for high frequency components. The higher the values, the softer and less accurately really high frequencies get encoded, in a more compression-friendly way than a preprocessed denoising (although the core algorithm is much less sophisticated, so using a good temporal noise reduction preprocesor can still yield better net results). They can improve quality on net by lowering QPs because the content is easier to compress, and the improved quality of lower frequency components can more than make up for some missing high frequency detail.

--nr-intra only applies to intra-coded TUs. So all an IDR or I-frame, and the intra-coded parts of P, B, and b frames. This will soften the original reference for every inter-coded TU, which is a pretty brute force way to lower bitrates or QPs. It also can't distinguish between what is very detailed static texture (which can be efficiently encoded from an intra reference) and random noise (which can make encoding much harder and can really drive down quality or drive up bitrates).

--nr-inter only applies to inter-coded TUs, so everything that references another frame. For normal content, high frequency components that would be residual are for the most part random noise, like grain. Raising --nr-inter will eliminate some of those, which can save a lot of bits, and actually improve quality. --nr-inter can damp down grain "swirlies" and grain enhancement seen when QPs get too high.

I find most of the value from --nr-inter, and plenty of times I'll use it without any --nr-intra at all. I use --nr-intra when --nr-inter is doing what I want, but there's some perceptible difference between inter and intra coded elements that becomes visible. So I raise --nr-intra up to where I'm not seeing keyframe strobing or mixed detail within a frame. If --nr-intra is too high, like the same as nr-inter, the detail loss is a lot bigger than bit savings, and counterproductive. With a higher --nr-inter, some of the grain is preserved in intra, and then the higher --nr-inter won't try to code the differences in the residual, so the grain texture will be preserved a lot better, just without randomly changing every frame as much.

Yes, I know your recomendations, and follow them, you provide great advice :),

I was using only --nr-inter exactly because of that, but seems that using "--rskip 2" and "--nr-inter anyvalue" at the same time causes that awful blocking.

[SquallMX]

I don't recommend using --nr, as that just sets --nr-intra and --nr-inter to the same values. In my experience, --nr-intra should only be 25-50% of --nr-inter so as not to reduce too much intra-coded detail. That could well be what's happening here. x264's --nr maps to x265's --nr-inter only, FWIW. x264 doesn't have any --nr-intra equivalent.

The --nr modes are essentially adaptive deadzones for high frequency components. The higher the values, the softer and less accurately really high frequencies get encoded, in a more compression-friendly way than a preprocessed denoising (although the core algorithm is much less sophisticated, so using a good temporal noise reduction preprocesor can still yield better net results). They can improve quality on net by lowering QPs because the content is easier to compress, and the improved quality of lower frequency components can more than make up for some missing high frequency detail.

--nr-intra only applies to intra-coded TUs. So all an IDR or I-frame, and the intra-coded parts of P, B, and b frames. This will soften the original reference for every inter-coded TU, which is a pretty brute force way to lower bitrates or QPs. It also can't distinguish between what is very detailed static texture (which can be efficiently encoded from an intra reference) and random noise (which can make encoding much harder and can really drive down quality or drive up bitrates).

--nr-inter only applies to inter-coded TUs, so everything that references another frame. For normal content, high frequency components that would be residual are for the most part random noise, like grain. Raising --nr-inter will eliminate some of those, which can save a lot of bits, and actually improve quality. --nr-inter can damp down grain "swirlies" and grain enhancement seen when QPs get too high.

I find most of the value from --nr-inter, and plenty of times I'll use it without any --nr-intra at all. I use --nr-intra when --nr-inter is doing what I want, but there's some perceptible difference between inter and intra coded elements that becomes visible. So I raise --nr-intra up to where I'm not seeing keyframe strobing or mixed detail within a frame. If --nr-intra is too high, like the same as nr-inter, the detail loss is a lot bigger than bit savings, and counterproductive. With a higher --nr-inter, some of the grain is preserved in intra, and then the higher --nr-inter won't try to code the differences in the residual, so the grain texture will be preserved a lot better, just without randomly changing every frame as much.

Yes, I know your recomendations, and follow them, you provide great advice :),

I was using only --nr-inter exactly because of that, but seems that using "--rskip 2" and "--nr-inter anyvalue" at the same time causes that awful blocking.

PD: Why did you guys capped the max bitrate of 1080p content on Prime?, I was waching some new L&O episodes, and found awful macroblocking in some noisy scenes, analising the stream looks like your team is using CBR 10 Mbps or something very close to it, when a few years back it was VBR with a max bitrate of 15 Mbps.

[benwaggoner]

I use that combination by default, and don't get that sort of artifacts. I do use them with a lot more complex command line than it seems you have here.

Two things you could try are --preset slower and/or --frame-threads 1. Slower kicks in a bunch of quality improvements, and sometimes weird things happen with frame threading.

I don't even have a theory as to why --nr-inter would cause that sort of problem. And --nr-inter 100 is a pretty low value for it too. Sounds like you're hitting a bug. Have you filed and issue with repro with MultiCoreWare.

PD: Why did you guys capped the max bitrate of 1080p content on Prime?, I was waching some new L&O episodes, and found awful macroblocking in some noisy scenes, analising the stream looks like your team is using CBR 10 Mbps or something very close to it, when a few years back it was VBR with a max bitrate of 15 Mbps.

You are seeing a quality regression on the same content and device compared to several years ago? Can you share me what device(s) were used, and what Title(s) you've seen this with?

What streams, codecs, and rate control modes you get depend on the player capabilities. I can't think of any devices that regressed like you described, although plenty go in the other direction with quality upgrades.

[SquallMX]

I don't even have a theory as to why --nr-inter would cause that sort of problem. And --nr-inter 100 is a pretty low value for it too. Sounds like you're hitting a bug. Have you filed and issue with repro with MultiCoreWare.

I will do that. Thanks. Meanwhile I will stop using --rskip 2 if I have to use --nr-inter.

[benwaggoner]

Oh, also, try:
--rd 4
--ctu 32

I've seen those help sometimes with that kind of artifact with 4K.