Banding problem
If you try to encode this (attached) video without using 10 bit depth, it has BIG banding issues.
Comments (24)
-
Account Deactivated -
Account Deleted reporter - edited description
-
Account Deleted reporter 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.
-
Account Deleted reporter Issue
#265was marked as a duplicate of this issue. -
I'm able to reproduce with your input sequence, we will fix it, Thanks.
-
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
-
Account Deleted reporter 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.
-
Yes I observed with 10 bit depth, will check it
-
The image has a classical banding problem - not enough bits per pixel. aq-mode 3, with higher aq-strength could help.
-
Account Deleted reporter 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.
-
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
-
Account Deleted reporter ABR is not a solution. CRF have to work properly...
-
reduced banding with no-cutree & crf, at 3 Mpbs achieved bitrate
encoder log: http://pastie.org/10844730
-
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
-
- attached x265_2.0+Patch.hevc
- attached x265_2.0.hevc
Hi, Can you check if pbm solved. Attached output with x2652.0 exe and x265_2.0+Patch
-
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/
-
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.
-
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
-
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 ?
-
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
-
not all frames were encoded, thats the reason
-
-
Isn't there an original source.yuv, rather than extracting from source.mkv ?
-
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.
- Log in to comment
Can you please provide a link to the video, and what is your command line?