Turing GPU cards and 10 bit HEVC

[Sharc]

Originally Posted by NikosD

Let's play a little more the blind test game...

After the Reality Check of Atak, let's go up to the sky again:
(StaxRip v2.0.4.9 - NVEncC v4.50)


4Mbps


Simple Enhanced Quality (223fps, CPU ~24%, GPU ~55%)
https://www.mediafire.com/file/hop6r...4Mbps.mkv/file

Advanced Enhanced Quality (206fps, CPU ~19%, GPU ~51%)
https://www.mediafire.com/file/mfx63...4Mbps.mkv/file

Constant Enhanced Quality (206fps, CPU ~20%, GPU ~46%)
https://www.mediafire.com/file/6pw37...4Mbps.mkv/file


Waiting for your feedback for the differences between the three of them...

All details are lost in any of them. See for example the small stars up in the sky around frame number 220. All gone, and pictures are mashed and blurred.
What is your encoder commandline? Did you add some noise filters? NVEncC h264 or h265 can do much better, I am sure, even for 4Mbps.

[sneaker_ger]

Originally Posted by poisondeathray

Can you guys post the actual command lines used ?

I added the command-line to the last post. (But it was already in the MEGA folder as .bat along with the NVEncC logs.)

[Sharc]

Originally Posted by poisondeathray

Can you guys post the actual command lines used ?

FWIW my command line for constant quality AVC (can't do HEVC tests with B-frames with my GPU):
NVEncC64 --avhw -i "carter.mkv" --fps 23.976 --codec h264 --profile high --level auto --sar 1:1 --lookahead 24 --vbrhq 0 --vbr-quality 25.50 --aq --aq-strength 8 --gop-len 24 --ref 3 --nonrefp --bframes 3 --bref-mode middle --mv-precision Q-pel --cabac --deblock --preset quality --colormatrix bt709 --crop 0,140,0,140 --max-bitrate 40000 --bluray --output "Carter.264"

[NikosD]

Originally Posted by Sharc

All details are lost in any of them. See for example the small stars up in the sky around frame number 220. All gone, and pictures are mashed and blurred.
What is your encoder commandline? Did you add some noise filters? NVEncC h264 or h265 can do much better, I am sure, even for 4Mbps.

Yes, VPP is a dangerous thing.
I added strong de-noisers to all of the encodings.

Have faith to Turing's HEVC encoder, but maybe we are asking too much...
On the other hand, let's try again.

A few more encodings without de-noisers.


4Mbps

Simple -Enhanced Quality without de-noisers (224fps, CPU ~24%)
https://www.mediafire.com/file/90zfa...4Mbps.mkv/file

Advanced -Enhanced Quality without de-noisers (209fps, CPU ~19%)
https://www.mediafire.com/file/upu2w...4Mbps.mkv/file

Constant -Enhanced Quality without de-noisers (202fps, CPU ~17%)
https://www.mediafire.com/file/g76b3...4Mbps.mkv/file


Any precious feedback for the differences between the three of them, would be more than welcomed.

[Atak_Snajpera]

Have faith to Turing's HEVC encoder, but maybe we are asking too much...

Few days ago you were much more optimistic about Turing encoder. You were claiming that nvenc on turing is almost on par with x265 slow Truth is that old grandpa x264 veryslow + prefiltering with MDegrain2 gives the best quality with reasonable bitrate (~4Mbps).
Yes it will be probably 10-20 times slower than NVenc but at least you get great quality regardless of the scene complexity. Besides ,I knew that turing encoder would suck because it didn't pass park_joy test sample (strong detail loss).

[Sharc]

Originally Posted by NikosD

Yes, VPP is a dangerous thing.
I added strong de-noisers to all of the encodings.

Have faith to Turing's HEVC encoder, but maybe we are asking too much...
On the other hand, let's try again.

A few more encodings without de-noisers.


4Mbps

Simple -Enhanced Quality without de-noisers (224fps, CPU ~24%)
https://www.mediafire.com/file/90zfa...4Mbps.mkv/file

Advanced -Enhanced Quality without de-noisers (209fps, CPU ~19%)
https://www.mediafire.com/file/upu2w...4Mbps.mkv/file

Constant -Enhanced Quality without de-noisers (202fps, CPU ~17%)
https://www.mediafire.com/file/g76b3...4Mbps.mkv/file


Any precious feedback for the differences between the three of them, would be more than welcomed.

I don't have a clear preference for any of your 3 examples.
Depending on the frame, any of the 3 may win (details, artefacts).
IMO the quality is good enough for watching on TV (probably no viewer will complain), but for archiving or backup one may not tolerate the loss of details but invest in long encoding times, or switch to higher bitrates (8Mbps+).

[NikosD]

Originally Posted by Sharc

I don't have a clear preference for any of your 3 examples.
Depending on the frame, any of the 3 may win (details, artefacts).

Understood.

Time to reveal my "secret sauce" for the NVEncC parameters of John Carter's Challenge.

4Mbps

Simple Quality Enhanced:

NVEncC64.exe --avhw --vbrhq 4000 --codec h265 --preset quality --profile main10 --output-depth 10 --max-bitrate 20000 --aq-temporal --colormatrix bt709 --colorprim bt709 --transfer bt709 --vpp-edgelevel --vpp-deband --crop 0,140,0,140

Output Info of Simple Quality Enhanced:

H.265/HEVC main10 @ Level auto

1920x800p 1:1 23.976fps (24000/1001fps)

Encoder Preset quality

Rate Control VBRHQ

Bitrate 4000 kbps (Max: 20000 kbps)

Target Quality auto

Initial QP I:20 P:23 B:25

VBV buf size auto

Lookahead off

GOP length 240 frames

B frames 3 frames [ref mode: disabled]

Ref frames 3 frames, LTR: off

AQ on

CU max / min auto / auto

Others mv:auto

encoded 14405 frames, 223.98 fps, 3909.88 kbps, 280.03 MB

encode time 0:01:04,

CPU: 24.0, GPU: 15.2, VE: 95.9,

GPUClock: 1948MHz, VEClock: 1799MHz


Advanced Quality Enhanced:

NVEncC64.exe --avhw --vbrhq 4000 --codec h265 --preset quality --profile main10 --output-depth 10 --max-bitrate 20000 --aq-temporal --bref-mode middle --lookahead 32 --strict-gop --colormatrix bt709 --colorprim bt709 --transfer bt709 --vpp-edgelevel --vpp-deband --crop 0,140,0,140

Output info of Advanced Quality Enhanced:

H.265/HEVC main10 @ Level auto

1920x800p 1:1 23.976fps (24000/1001fps)

Encoder Preset quality

Rate Control VBRHQ

Bitrate 4000 kbps (Max: 20000 kbps)

Target Quality auto

Initial QP I:20 P:23 B:25

VBV buf size auto

Lookahead on, 32 frames, Adaptive I, B Insert

GOP length 240 frames

B frames 3 frames [ref mode: middle]

Ref frames 3 frames, LTR: off

AQ on

CU max / min auto / auto

Others mv:auto

encoded 14405 frames, 208.73 fps, 3922.46 kbps, 280.93 MB

encode time 0:01:09,

CPU: 18.9, GPU: 15.1, VE: 94.2,

GPUClock: 1956MHz, VEClock: 1806MHz


Constant Quality Enhanced:

NVEncC64.exe --avhw --vbrhq 0 --codec h265 --preset quality --profile main10 --output-depth 10 --max-bitrate 4000 --vbr-quality 0 --aq-temporal --lookahead 16 --colormatrix bt709 --colorprim bt709 --transfer bt709 --vpp-edgelevel --vpp-deband --crop 0,140,0,140

Output info of Constant Quality Enhanced:

H.265/HEVC main10 @ Level auto

1920x800p 1:1 23.976fps (24000/1001fps)

Encoder Preset quality

Rate Control VBRHQ

Bitrate 0 kbps (Max: 4000 kbps)

Target Quality auto

Initial QP I:20 P:23 B:25

VBV buf size auto

Lookahead on, 16 frames, Adaptive I, B Insert

GOP length 240 frames

B frames 3 frames [ref mode: disabled]

Ref frames 3 frames, LTR: off

AQ on

CU max / min auto / auto

Others mv:auto

encoded 14405 frames, 202.46 fps, 3919.61 kbps, 280.73 MB

encode time 0:01:11,

CPU: 16.6, GPU: 15.2, VE: 92.9,

GPUClock: 1960MHz, VEClock: 1810MHz


That's all folks!

[poisondeathray]

It definitely looks better at higher bitrates (obviously), and the speed is amazing . But even at 10Mb/s there is that characteristic high frequency detail loss . It similar to x265's blurring with SAO , or very early x264 development where it tended to blur everything like rmvb. There doesn't seem to be any other options for NVEnc to prevent that (besides much higher bitrate) ? I find x265 doesn't necessarily do so great on many movie/film type sources either, unless you adjust the settings from default

There were a bunch of tests results on the Nvidia forum and various gaming forums when Turing first came out. But nobody posted actual videos, just numbers. And only video games were tested. But still no samples of video games... (Probably not enough time, addicted to "Fortnite" or something ) . But that characteristic high frequency detail loss was in all the posted screenshots too. Fine textures and details would be blurred away . But you typically won't "see" that difference from a typical viewing distance and conditions

I'd still like to see more tests, different source types and varied settings .

[NikosD]

Originally Posted by poisondeathray

There doesn't seem to be any other options for NVEnc to prevent that (besides much higher bitrate) ?

Personally, I will come back to encoding tests when rigaya updates his app to SDK v9.1.

I emailed him yesterday, if he is interested in doing so.

An SDK update will help, but maybe we have to wait for the next generation of nVidia's HW encoder.

Unless Intel decides to catch up!

[sneaker_ger]

Originally Posted by poisondeathray

It similar to x265's blurring with SAO

Unfortunately, NVEncC does not seem to provide any option to turn off or tune SAO. Deblocking can only be turned on/off for AVC.

[excellentswordfight]

Originally Posted by NikosD

Yes, VPP is a dangerous thing.
I added strong de-noisers to all of the encodings..

Wow, and you didn't think that information was relevant before? Does this apply to park run as well? If thats the case, no wonder it stacked up to x265... Is this an built in denoiser part of the nvenc at least, or does it work like an pre-filter? Using one is very bad practice for encoder comparison, not disclosing this earlier seems very dishonest to me.

Advanced Quality Enhanced:

NVEncC64.exe --avhw --vbrhq 4000 --codec h265 --preset quality --profile main10 --output-depth 10 --max-bitrate 20000 --aq-temporal --bref-mode middle --lookahead 32 --strict-gop --colormatrix bt709 --colorprim bt709 --transfer bt709 --vpp-edgelevel --vpp-deband --crop 0,140,0,140

I'm confused on some of these settings, why would you set a strict-gop of 240frames? And if you want fixed gops for that preset why is lookahead used there and not for the non-fixed one? That doesnt sound that "Advanced Quality Enhanced" to me, and why is edgelevel and deband left without any parm or value? Do they do anything at all like that?

edit.had look at the NVEncC64 doc, and it seems like the vpp settings are not part of nvenc, so edgelevel and deband would be pre-filters as well.

[NikosD]

Originally Posted by excellentswordfight

Wow, and you didn't think that information was relevant before? Does this apply to park run as well?

Oh, please stop worry so much...
All of my three encodings of John Carter that had that blur and only them that had that huge GPU usage.

And I never encoded Park Run...

Crowd Run had very simple settings and probably I have to go back to them...But of course it had also 10 Mbps bitrate.

Originally Posted by excellentswordfight

I'm confused on some of these settings, why would you set a strict-gop of 240frames? And if you want fixed gops for that preset why is lookahead used there and not for the non-fixed one? That doesnt sound that "Advanced Quality Enhanced" to me, and why is edgelevel and deband left without any parm or value? Do they do anything at all like that?

I'm confused too.
Strict GOP changes nothing and lookahead changes almost nothing too.
Has been used here and there by me.

VPP settings (edge, deband, denoise etc) have default values from the Japanese genius called rigaya and they do show up in the log file, but I didn't include them.

Maybe next time if you are a good boy...

[excellentswordfight]

Originally Posted by NikosD

I'm confused too.
Strict GOP changes nothing and lookahead changes almost nothing too.

Well I guess that they change what they are design for.

So according to the doc:

--strict-gop

Force fixed GOP length.

and

--lookahead <int>

Enable lookahead, and specify its target range by the number of frames. (0 - 32)
This is useful to improve image quality, allowing adaptive insertion of I and B frames.

So I ask again, why do you set strict-gop? Lookahead enables adaptive I and B-frame placement, but you are using it together with a setting that is blocking it to inserting adaptive i-frames (or that is atleast how I interpret it).

That's exactly the reason I'm calling myself "blind"

In all my honesty I find both frames of Turing's HEVC encoder posted by you, a lot better than the one of x265 slow.

I almost can't believe that comparing those 3 frames you find the last frame of x265 better than the other two!

And I can see differences between the first two, I personally like the second (enhanced) more.

I think you missed the point, Both frame 1 and 2 are from the same encoded file, image 2 is the frame following image 1 and is showing the strobing/flicker/frame quailty issue. There are frames that is very different next to each other causing issues when watched in motion.

You can ofc find a smoother image "better", but x265 is much closer to the original in those samples and it does not suffer from temporal issues. But as long as there are pre-filters involved evaluating the encoder it self and making comparisons with others is pretty much out the window.

Oh, please stop worry so much...
...
Maybe next time if you are a good boy...

I think thats my cue.

[NikosD]

Originally Posted by excellentswordfight

I think thats my cue.

Vpp Filters used by my encodings (default values):

crop: 0,140,0,140/cspconv(nv12 -> yv12(16bit))

edgelevel: strength 5.0, threshold 20.0, black 0.0, white 0.0

deband: mode 1, range 15, threY 15, threCb 15, threCr 15

ditherY 15, ditherC 15, blurFirst no, randEachFrame no

cspconv(yv12(16bit) -> p010)


Also, as I posted yesterday, I asked Rigaya if he is going to update NVEncC to SDK v9.1 using multiple reference frames for Turing and he informed me that he released NVEncC v4.51 with exactly that support.

Download link:
https://github.com/rigaya/NVEnc/rele...cC_4.51_x64.7z

From nVidia's docs:

Multiple reference frames

Turing NVENC adds support for choosing the matching macroblock/CTB from multiple reference frames, which results to improvement to encoded quality.

The numbers of reference frames are decided inside NVIDIA’s display driver.

The current SDK exposes control to the client for specifying the number of reference frames which will override the values set inside NVIDIA’s display driver.

I will probably do a few more encodings using NVEncC v4.51

[Atak_Snajpera]

It is just insane how many fine details you lose on turing encoder vs x264 veryslow
TURING 4Mbps
https://i.imgsafe.org/b6/b63261e37e.png

x264 veryslow 4Mbps
https://i.imgsafe.org/b6/b633239470.png

x264 despite its age is still a sharpness king

Ps. x265 is still softer than x264

[NikosD]

Originally Posted by Atak_Snajpera

It is just insane how many fine details you lose on turing encoder vs x264 veryslow
TURING 4Mbps

From which of all Turing 4Mbps encodings is this frame taken ?

[poisondeathray]

Originally Posted by Atak_Snajpera

Ps. x265 is still softer than x264

In general yes, at default settings. SAO has a net blurring effect

Usually you need to adjust SAO or disable it, a bit of lower deblock (negative), psy-rd, psy-rdoq in order to "coax" x265 to behave more like x264 in terms of fine higher frequency detail retention . And there is some trade off in terms of more noise, edge artifacts.

But some people don't like those fine details. They prefer smoother for whatever reason. My opinion is if the source has those fine details and definition, so the encode should as well (in the "decent" bitrates, good quality encode scenario)

[Atak_Snajpera]

Originally Posted by NikosD

From which of all Turing 4Mbps encodings is this frame taken ?

John_carter_enhanced_quality_4Mbps.mkv

[NikosD]

Originally Posted by Atak_Snajpera

John_carter_enhanced_quality_4Mbps.mkv

Those first three encodings were a little "broken" I think.

Please, take a look at any of the last three encodings without denoising filtering.

[poisondeathray]

Originally Posted by Atak_Snajpera

It is just insane how many fine details you lose on turing encoder vs x264 veryslow
TURING 4Mbps
https://i.imgsafe.org/b6/b63261e37e.png

x264 veryslow 4Mbps
https://i.imgsafe.org/b6/b633239470.png

x264 despite its age is still a sharpness king

Ps. x265 is still softer than x264

Atak, your x264 screenshot does not match the x264-veryslow-4Mbps.mkv uploaded

How did you take the screenshot ? MadVR ? Was there some other filtering in the display chain ?