HEVC test samples

[xxxxx12345]

Hi,
I just made some test with x265, the result is amazing in 98-99% of the video, but in some scenes i see horrible banding, even if i double/triple the bitrate (1000kbps to 3000kbps, 1080p). There is no banding if i use x264. I tested x265 16bpp as well and not see the banding but the overall quality is much worse than 8bpp (and much slower the encoding of course). Any idea?

[LigH.de]

Please help us to help you: Exact x265 version, complete command line options, screenshot with highlighted issue, brief cut scene if possible (often the surrounding scene is more important than only one frame alone).

[xxxxx12345]

I use latest mediacoder with x265 1.3.240

x265 --preset faster --no-open-gop --keyint 250 --scenecut 40 --wpp --lft --sao --crf 25 --threads 8 - "$(DestFile)"
2screenshots: at the first the left side too, i forgt to hightlight



Edit:another, cfr20, source BD50

[LigH.de]

Unfortunately, single screenshots only ... so one can only guess. It may be important to know if a scene cut is close (but they seem to be mostly steady). If not, I would wonder about quantization pumping (different base quantizers between I/P/B frames, rate control fluctuations). A brief video cut would be more useful than screenshots only.

Plus, I doubt that this is related to MinGW builds specifically. It may have been placed better in the generic x265 thread; can a moderator move this part?

[xxxxx12345]

here is the sample including 1st 2 picture above.
I can try cut the scene from SW1 if necessary
EDIT: here is the SW scene, i quickly did it because this is a very representative/annoying example. Some of these scene makes the whole movie unwatchable

[LigH.de]

OK, as far as I can see, this seems to be simply accumulated quality loss due to coarse quantization in combination with little de-redundancy efforts (fast preset). Too little bitrate to preserve enough quality, artefacts appear to develop after each scene cut. In scenes where a little (Pulfrich type) panning is present, you see the artefacts in the blurry background being dragged along with the sharp foreground edge, quite typical for a lack of better matching motion vectors (due to the brief search in fast presets).

Disclaimer: The statement above is my personal opinion; other people may know better than me, though.
__

Watch the scene around second 28 in this cut. There is something bright and blurry in front of the actor's right shoulder. The first frame after the scene cut (certainly an I frame) is satisfyingly grainy. All following frames turn the grain to a pattern, like leather, and the right outer part which fades to black gets more blocky; but now and then, probably with a P frame, some detail returns.
__

Similar observation for the SW scene. Watch the reflection below the door while it closes. And watch the shadow in the lower left corner while the coat approaches. Such are signs of a "desperate" encoder which doesn't find any better reference, due to both a lack of efforts to search for a better match, and a lack of bitrate to intra-code what did not yet match anything good enough.

[xxxxx12345]

What i don't understand, seems the algorithm "want" this artefacts, if i double/triple the bitrate (up to 4000kbps) its's still there...
Seems while x264 has problem with fast moving scene x265 have problem with static scenes...what a pity...

[sneaker]

@xxxxx12345

I'm really interested in seeing how 10 bit did worse than 8 bit. Are they both the same size? (CRF is not the same between 8 bit and 10 bit - use 2pass at same bitrate for comparisons)
Can you upload both of them (+ the source file so I can reproduce it)? Maybe show me what you don't like about the 10 bit encode?

As for the banding in the 8 bit encode, I would try psy, for example:
--psy-rd 1.0 --psy-rdoq 1.0

Unfortunately, psy-rd needs at least --rd 3 (preset medium), psy-rdoq at least --rd 4 (preset slow)

Here's x265 8 bit encode without and with psy:
http://abload.de/img/290_5_tmszr.png
http://abload.de/img/290_5psy_d9sl3.png

x264 uses psy by default.

[vhelp]

this is rediculous. i was going to suggest the same thing.....

@xxxxx12345, please upload the original sources of those segments that are exibiting the artifacts so that we can test them to see if they produce the same or similar artifacts on our system. you can upload up to 100MB size on this forum, please don't use those other free hosting sites because they house tracking and other such nonsense, thank you.

[xxxxx12345]

original sources

[LigH.de]

SW1 already has a too hard quantization in the reflection below the closing round door.

The other film is very grainy (hard to compress without Film Grain Modelling), and also quite hard quantized, which is rather obvious in the already mentioned 28th second (right after the "F.U." curse).

For both, CRF 25 is probably a lot too coarse.

[Baldrick]

xxxxx12345: I moved you to a separate thread instead of the hevc builds.

[sneaker]

I tested x265 16bpp as well and not see the banding but the overall quality is much worse than 8bpp

Can't really say I find the 10 bit encoding much worse. What do you dislike specifically? Maybe you're expecting too much given the encoding speed, bitrate and status of x265 development? (Also, I find x264 is often better than x265 for typical hollywood movies.)

P.S.: It appears like you are using an experimental and deprecated build of mkvmerge (from DivX). This may produce incompatible/broken files. I recommend upgrading to the latest official version (7.2.0).

[xxxxx12345]

Can't really say I find the 10 bit encoding much worse.

I find at the same bitrate 10 bit a little brurry and needs more bitrate at fast moving scenes but i have to admit i not make intense test. Defenetly better in banding...

Maybe you're expecting too much given the encoding speed, bitrate and status of x265 development?

Absolutely. I made tests with very low bitrate.The quality is good (sometimes very good) but the overall quality far from perfect. Also x264 has been huge development in the last few years. I made the whole SW1 movie with x264 @5000kbps with perfect result.
So my conclusion: i use x265 for TV series where the size is the priority and use x264 for movies to watch on projector.

[somespirit]

i think that crf25 is very bad to use, with crf25 you just telling the encoder to encode the frames with low quality (and you will get low bitrate), try to use at least crf17 for nice looking video

[Atak_Snajpera]

Try these --preset medium --rd 4 --psy-rd 1.5 --psy-rdoq 2.5 --aq-strength 1.5

[Gravitator]

The problem here is the lack of bitrate (10,12 bit will not help).

[xxxxx12345]

I just read the documentation, i find --aq-mode, --aq-strength is the solution.
With --aq-mode 1 --aq-strength 1.8-2.0 there is no banding/blocking even at very low bitrate (1000kbps).
This setting raises the bitrate 10-30% but i think it's worth.

[El Heggunte]

With --aq-mode 1 --aq-strength 1.8-2.0 there is no banding/blocking even at very low bitrate (1000kbps).
This setting raises the bitrate 10-30% but i think it's worth.

Well, if you desperately want super-ultra-hyper-LOW bitrate + acceptable quality at the same time,

prepare yourself to create a video format even more CPU-hungry than H.265

[Gravitator]

I just read the documentation, i find --aq-mode, --aq-strength is the solution.
With --aq-mode 1 --aq-strength 1.8-2.0 there is no banding/blocking even at very low bitrate (1000kbps).
This setting raises the bitrate 10-30% but i think it's worth.

For 1000kb looks quite acceptable
More still help method recovery of noise (the developer cunningly silent) > cliсk

[El Heggunte]

It looks like --aq-mode 2 sucks alot. No idea why devs decided to use mode 2 as default.

source: http://forum.doom9.org/showthread.php?p=1695076#post1695076

[ezcapper]

I just read the documentation, i find --aq-mode, --aq-strength is the solution.
With --aq-mode 1 --aq-strength 1.8-2.0 there is no banding/blocking even at very low bitrate (1000kbps).
This setting raises the bitrate 10-30% but i think it's worth.

Can you post the full command so we can copy and paste it. Is it I was about to give up on HVEC because I was getting that banding even at 7000kbps, but this looks great. Is it:
x265 --preset faster --aq-mode 1 --aq-strength 2 --no-open-gop --keyint 250 --scenecut 40 --wpp --lft --sao --crf 25 - "$(DestFile)"

edit: In mediacoder, if you check aqvariance for the aqmode, but in the extra options input --aq-mode 1, will the extra options override the other setting?

[xxxxx12345]

Is it:
x265 --preset faster --aq-mode 1 --aq-strength 2 --no-open-gop --keyint 250 --scenecut 40 --wpp --lft --sao --crf 25 - "$(DestFile)"

edit: In mediacoder, if you check aqvariance for the aqmode, but in the extra options input --aq-mode 1, will the extra options override the other setting?

Yes, and yes

I made some more tests and seems --aq-mode 1 --aq-strength 1.8 enough.
Unfortunately this solves the banding but has side effect, seems it's bad for slowly motion fine details. I made a test with an episode of big bang theory and small faces looks awful when moving. Seems --aq-mode 1 --aq-strength 1.8 vaste too many bits for static part...

[xxxxx12345]

Half year passed, i checked x265 again but unfortunatelly nothing improved in banding issue...

[newpball]

Hi,
I just made some test with x265, the result is amazing in 98-99% of the video, but in some scenes i see horrible banding, even if i double/triple the bitrate (1000kbps to 3000kbps, 1080p). There is no banding if i use x264. I tested x265 16bpp as well and not see the banding but the overall quality is much worse than 8bpp (and much slower the encoding of course). Any idea?

Let's just get some things clear.

With sub 8-bit video banding is a fact of life. Often it has nothing to do with the encoding.

10 bits pretty much assures banding will disappear (assuming the source is 10 bit or if an 8 bit source is properly dithered to 10 bit) however it would only go away visibly if you can actually display 10 bit video.

[xxxxx12345]

Theoretically you right. But in real life x264 does the job very well, even divx265 does. Of course x265 far better overall than divx265 but the banding/blocking makes it completelly useless for me. 10 bit really has no banding but it's far more CPU hungry and needs slightly bigger bitrate... I'll check again half year later ...

[Jamaika]

It will have to think about the codec VP9.
Examples:
http://www.sendspace.com/filegroup/OhMm3eySptHMftdJSAwsFFiimZ1YVRHN
Photo for gamma 5, bt709, range limited, bitrate 3000kbps 1280x720 8bit:
DivX265 1.4.0.21

VP9 1.3.0.571

[Gravitator]

The DivX could be improved is the result of higher "adaptive quantization strength" .

[xxxxx12345]

I think x264 is perfet at 720p 3000kbps, absolutelly pointless to use VP9, divx or x265

[Jamaika]

Everything depends on the quality of the recorded material. In another forum recently struggled out how to help to get the best quality on Youtube for sports camera SJ4000.

Output Quality flimsy, an array of moves, poor lighting. Final Effect on youtube - junk with artifacts 1280x720 / 30p 2500kbps.

Examples coding which lately I used:

vpxenc_1.3.0.5712.exe -v --i420 --threads=4 --passes=1 --pass=1 --good --codec=vp9 --fps=24000/1001 --cpu-used=4 -w 1280 -h 720 --target-bitrate=4000 --kf-max-dist=24 --aq-mode=3 --color-space=unknown - -o vp9_420p08le.webm

divx265_1.4.0.21.exe -v -i - --format yuv420p -s 1280x720 -br 3000 -fps 24000/1001 -n 24 -aqo 5 --colour-primaries unspec --transfer-characteristics unspec --matrix-coefficients unspec -o divx265_420p08le.265

x265_1.5+380.exe - --no-open-gop --aq-mode 1 --aq-strength 2 --input-depth 8 --input-res 1280x720 --input-csp i420 --bitrate 3000 --vbv-bufsize 10000 --vbv-maxrate 10000 --preset slow --colormatrix undef --colorprim undef --transfer undef --range limited --keyint 24 --min-keyint 1 --me dia --bframes 0 --ref 1 --fps 24000/1001 --output x265_420p08le.265

Note:
Divx265 not work BT709
VPXenc missing an intermediate option between --good and --best
X265 version better terms on the GTS 450. No strands.
Options overstate X265, DivX265 HD and FHD for about 1000kbps bitrate.