x265 HEVC Encoder

[Kill3rWolf]

Originally Posted by Boulder

Use --ctu 32. Rskip 2 is useful for retaining details, CTU 64 much less (if at all) so.

Originally Posted by microchip8

use rskip 1 and ctu 32

Got confusion. (Boulder) Rskip 2 & (microchip8) rskip 1. Same topic, but with a different value.

[Kill3rWolf]

Could you tell me perfect vbv-maxrate= & vbv-bufsize= value for Level 4.1 Main tier (Blu-ray encoding)?
Should I set 20,000 for both?
Can I do vbv-maxrate=12000 & vbv-bufsize=20000 without any error?

I saw that an encoder did vbv-maxrate=18000 & vbv-bufsize=24000 for Main 10@L5.1@Main.

[Boulder]

Originally Posted by Kill3rWolf

Got confusion. (Boulder) Rskip 2 & (microchip8) rskip 1. Same topic, but with a different value.

--rskip 2 is better for detail retention. --rskip 1 is the same as the old --rskip. I recommend using --ctu 32 regardless of the rskip setting.

[_kermit]

Originally Posted by Boulder

--rskip 2 is better for detail retention. --rskip 1 is the same as the old --rskip. I recommend using --ctu 32 regardless of the rskip setting.

with --rskip 2 I had tearing, not using that anymore.

[rwill]

Originally Posted by _kermit

with --rskip 2 I had tearing, not using that anymore.

Tearing ? You mean what you reported here ?:
https://forum.doom9.org/showthread.p...19#post1960919

You had quite a lot of parameters. By that logic you don't set any of these now ?

[Kill3rWolf]

Guys, need help regarding HEVC Level, Tier vbv-maxrate= & vbv-bufsize= value.

[Gravitator]

Originally Posted by _kermit

Massive tearing, at least I think that's what it's called: https://ibb.co/fSYXTQ0

it's a specific scene of Mission Impossible - Rogue Nation starting at 1.09.56 (original: https://ibb.co/9GhV3wx)

any ideas how to prevent that?
are my params the reason (hence the question above)?

Can you provide a sample (30 sec)?

[excellentswordfight]

Originally Posted by Kill3rWolf

[url=https://ibb.co/B4yKnNp]
Could you tell me perfect vbv-maxrate= & vbv-bufsize= value for Level 4.1 Main tier (Blu-ray encoding)?

The "perfect" values depends on your target device & playback variables.

Should I set 20,000 for both?

You could, that is also what the encoder sets if you specify that level.

Can I do vbv-maxrate=12000 & vbv-bufsize=20000 without any error?

As long as its not above the max value of the level you want to use, yes.

I saw that an encoder did vbv-maxrate=18000 & vbv-bufsize=24000 for Main 10@L5.1@Main.

Ok?

[_kermit]

Originally Posted by rwill

Tearing ? You mean what you reported here ?:
https://forum.doom9.org/showthread.p...19#post1960919

You had quite a lot of parameters. By that logic you don't set any of these now ?

yes, that screen (btw how is that called properly?)

and I kept everything just skipped --rskip 2 (which I'm still wondering if that is a good thing, but those I collected over time. I'd prefer to keep it more simple or better ones if possible)

that above went away, I try now with --rskip 1 to get more FPS.

[_kermit]

Originally Posted by Gravitator

Can you provide a sample (30 sec)?

the first screenshot shows it (if still online). That specific scene is all like that, while there is like "doublevision" of her (screen two) in the original.

[rwill]

Originally Posted by _kermit

yes, that screen (btw how is that called properly?)

and I kept everything just skipped --rskip 2 (which I'm still wondering if that is a good thing, but those I collected over time. I'd prefer to keep it more simple or better ones if possible)

that above went away, I try now with --rskip 1 to get more FPS.

If the screen is covered with tiny blocks or garbage that do not fit the bitrate like in this case I would call it encoding or decoding error or encoder/decoder mismatch. Its an error that is caused by the encoder trying to do one thing and writing it out but the decoder is doing another thing upon reading it in, leading to complete disaster. Once broken by such an error the encoding/decoding process most likely does not recover until the next random access point. In simpler terms it is a miscommunication of picture contents between encoder and decoder.

This can be caused by some bug or out of spec behavior in the encoder or decoder where the standard ( here h.265 ) is not followed correctly. If you used hardware decoding to produce that output the most possible cause lies in the encoder because hardware decoders are tested very thoroughly before being cast in silicon.

These type of problems can be debugged by cutting the source down to some small sample which triggers the effect every time it is decoded with one specific or all decoders. So to fix it one needs the small input sample, the encoder in a specific version in source form, the encoder configuration and the decoder in source form in a specific version. Oh and the H.265 standard. Then you can see at which point the encoder and decoder start to differ in the encoding/decoding process. Large samples where things start to happen one hour in are useless because their are very cumbersome to debug.

Could be that the rskip 2 codepath triggers some problem but it might also be that due to all the dependencies a bitstream and encoder / decoder state has a very rare condition somewhere else in the encoder or decoder is triggered by pure chance.

Then again maybe just some frame is too large or the decoder application is feeding DXVA2 wrong at your 160MBit rate.

[benwaggoner]

Originally Posted by _kermit

with --rskip 2 I had tearing, not using that anymore.

Turning down the --rskip-edge-threshold some should fix the tearing while still preserving some of the speed improvements. I find 2-3 works pretty well with the content I've tested with it.

[rwill]

Originally Posted by benwaggoner

Turning down the --rskip-edge-threshold some should fix the tearing while still preserving some of the speed improvements. I find 2-3 works pretty well with the content I've tested with it.

Have you seen the screenshot he provided ?

[Kill3rWolf]

I have a question, Which one is better, max-luma=255 or max-luma=1023? or depend on the source?

Which one provides bad quality, I mean incorrect colors & too much unacceptable brightness.

[GEfS]

Originally Posted by Kill3rWolf

I have a question, Which one is better, max-luma=255 or max-luma=1023? or depend on the source?

Which one provides bad quality, I mean incorrect colors & too much unacceptable brightness.

the value already tells the reason, 255 (0-255, 256 values, 2^8) is 8 bit, 1023 (0-1023, 1024 value, 2^10) is 10bit, it depends on your in and output

[Kill3rWolf]

https://ibb.co/2NRL0P9

@Ben Waggoner, Should I use aq-mode=4 only for 4k HDR content? What about 1080p SDR content? aq-mode=4, Is it still unstable? Can be used for almost all content?

https://iopscience.iop.org/article/1.../1/012029/meta

[FranceBB]

Originally Posted by Kill3rWolf

I have a question, Which one is better, max-luma=255 or max-luma=1023? or depend on the source?

Which one provides bad quality, I mean incorrect colors & too much unacceptable brightness.

That's full range, though.
for 10bit Limited TV Range I use:

--min-luma 64 --max-luma 940

[Kill3rWolf]

Originally Posted by FranceBB

That's full range, though.
for 10bit Limited TV Range I use:

--min-luma 64 --max-luma 940

What's the actual benefit of doing it? I mean behind the reasons.

[excellentswordfight]

Originally Posted by Kill3rWolf

What's the actual benefit of doing it? I mean behind the reasons.

It sets what values the encoder excepts for the incomming signal, values above/below are clipped. I.e. if you set this incorrectly you will mess upp the luma values of your encode.

It's very unlikely that you need to specify this manually unless you have good reason for it.

[Kill3rWolf]

Originally Posted by excellentswordfight

It's very unlikely that you need to specify this manually unless you have good reason for it.

Yeah, that's why ain't gonna touch it.