Banding problem

[Former user]

If you try to encode this (attached) video without using 10 bit depth, it has BIG banding issues.

http://webshare.cz/file/12G4eZ47o6/

[Pradeep Ramachandran]

Can you please provide a link to the video, and what is your command line?

[Former user]

That's my settings: wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=3 / subme=3 / merange=57 / rect / no-amp / max-merge=3 / temporal-mvp / no-early-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=240 / min-keyint=24 / scenecut=40 / rc-lookahead=60 / lookahead-slices=0 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=5 / limit-refs=3 / limit-modes / weightp / no-weightb / aq-mode=1 / qg-size=16 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=4 / psy-rd=2.00 / rdoq-level=2 / psy-rdoq=5.00 / signhide / deblock=-3:-3 / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=8 / ipratio=1.40 / pbratio=1.30

But it occurs with any 8 bit depth settings.

[Former user]

Issue #265 was marked as a duplicate of this issue.

[Mahesh Pittala]

I'm able to reproduce with your input sequence, we will fix it, Thanks.

[Mahesh Pittala]

Can you reduce the crf level and see.

you encoded with crf=20 and the achieved bitrate is 890kbps, seems very less bits used for 1080p.

To avoid banding issue we may have to compromise at bits, I verified.

at crf 17 little bit better

at crf 14 much better

at crf 10 no issues

[Former user]

If we have to rise the CRF that much, the result will be bigger than AVC (or equal at least). So where is the HEVC advantage and promised 50% bitrate with the same quality?

AND if we use 10 bit depth (without any other change), the result is only slightly bigger and there is no banding.

[Mahesh Pittala]

Yes I observed with 10 bit depth, will check it

[Deepthi Nandakumar]

The image has a classical banding problem - not enough bits per pixel. aq-mode 3, with higher aq-strength could help.

[Former user]

OK, I have tested the aq-mode 3 and aq-strength:

8 bit: 3,04MiB - banding
10 bit: 3,66MiB - no banding
8 bit aq-mode 3: 3,45MiB - banding
8 bit aq-mode 3 aq-strength 1,5: 6,63MiB - banding
8 bit aq-mode 3 aq-strength 2: 18MiB - banding

So, nandaku2, it did not help.

[Mahesh Pittala]

found very less banding with ABR at 3 Mbps, 3 Mbps bitrate is decent for 1080p. Please can you check with --bitrate 3000 --aq-strength 3 --aq-mode 3

[Former user]

ABR is not a solution. CRF have to work properly...

[Mahesh Pittala]

reduced banding with no-cutree & crf, at 3 Mpbs achieved bitrate

encoder log: http://pastie.org/10844730

[N Vijay Anand]

hi, can you tell from which frame number to which frame number issue is present. (x,y) coordinates too assuming (0,0) is bottom left

[N Vijay Anand]

Hi, Can you check if pbm solved. Attached output with x2652.0 exe and x265_2.0+Patch

[Mahesh Pittala]

compared both x265_2.0 and x265_2.0+patch, banding still exists.

you can find the banding in frames, 90 to 130 327 to 400

shared the frames and marked where banding occurs. https://postimg.org/gallery/1tm6lcahy/bad3b77b/

[N Vijay Anand]

Im unable to distinguish between reconstructed (both hevc2.0 and patch) and original source.yuv. Can you recheck by extracting frames 91 to 130 from source.mkv and see if bands present aprior.

[Mahesh Pittala]

Hope you are able to see the banding in frames which I shared, If not please increase the brightness & contrast of your machine to > 90%

I tried to decode the x265_2.0+patch bitstream using HM and found crash, please check it

POC 608 TId: 0 ( B-SLICE, QP 22 ) [DT 0.059] [L0 607 605 600 ] [L1 612 616 ] [ :,(unk)] POC 609 TId: 0 ( B-SLICE, QP 22 ) [DT 0.068] [L0 607 605 600 ] [L1 612 616 ] [ :,(unk)] POC 610 TId: 0 ( B-SLICE, QP 22 ) [DT 0.060] [L0 607 605 600 ] [L1 612 616 ] [ :,(unk)]

Assertion failed: m_fifo_idx + num_bytes_to_load < m_fifo->size(), file ....\so urce\Lib\TLibCommon\TComBitStream.cpp, line 279

[N Vijay Anand]

hi, my brightness level is 100%. My perceptions are poor :). What I'm concerned is the input source.yuv frames (extracted from source.mkv using ffmpeg decoder) also resembles with output of x265_2.0 and x265_2.0+Patch. That's why sought your inputs on same. I'm using HM-15.0 decoder to decode the generated hevc streams without crash. Which version of HM are you using ?

[Mahesh Pittala]

crash with both 15.0 & 16.8 HM decoders but decoded with ffmpeg.

HM software: Decoder Version [15.0_RExt8.0][Windows][VS 1600][32 bit]

HM software: Decoder Version [16.8] (including RExt)[Windows][VS 1600][64 bit]

banding more visible on x265_2.0, x265_2.0+patch recons compared to source yuv

FYI, x265_2.0+patch recon file size is 1.77Gb but source, x265_2.0 size is 2.2 Gb

[N Vijay Anand]

not all frames were encoded, thats the reason

[N Vijay Anand]

i must admit i can't see much of difference between frames #90 to #99 in source.yuv with corresponding frames in reconstructed .yuv.

The encode itself seems of high quality : 3331.45 kb/s, Avg QP:16.72, Global PSNR: 51.744, SSIM Mean Y: 0.9930607

[N Vijay Anand]

Isn't there an original source.yuv, rather than extracting from source.mkv ?

[N Vijay Anand]

I think proper input source.yuv is needed with clear resolution 10 bit or 8 bit. I get an impression a 10bit yuv seq was used for encoding using 8 bit settings;

Assume Pixel intensity is 0x100; I wonder how code assumes it for encoding using 8 bit setting. Ideally it should be clamped to 0xff.