Turing GPU cards and 10 bit HEVC [Archive] - Page 2

easy2Bcheesy

3rd October 2019, 19:42

Not sure if this is a thread hijack, but it is on topic! Our usual workflow is to edit video game footage in Premiere, export into ProRes then use x264/x265 to produce h.264/HEVC encodes. We use the fast HEVC preset, typically at CRF20.

We're finding that the time from export to final files is just too long.

We're looking at Voukoder that lets us export straight from the timeline, but the encode times are still too long. All of which brings us to Turing. Which doesn't have CRF. Any ideas on where to start in terms of getting similar quality? I'm OK with a bit of file bloat! I'm also OK with losing the h.264 version too...

NikosD

4th October 2019, 06:36

We use the fast HEVC preset, typically at CRF20.

...All of which brings us to Turing. Which doesn't have CRF. Any ideas on where to start in terms of getting similar quality? If your target is beating x265 fast using Turing's HEVC encoder, then I'm afraid you are setting your target too low.

Just buy a Turing card from 1660 and above and use it.

We eat x265 fast for breakfast here.

We can even beat x265 slow.

Sky is the limit...

Blue_MiSfit

4th October 2019, 08:03

What do you do with your HEVC encodes after you make them? Are they for direct distribution or do you upload them to some hosting platform like YouTube? If so, move up to superfast and target the higher bitrates. Maybe use x264 instead, no reason to spend all the compute for HEVC in that case. This is also a potential sweet spot for NVENC, as NikosD suggested above. Hardware encoding is great when you want to go fast and are willing to spend some additional bits to keep quality.

easy2Bcheesy

4th October 2019, 09:55

Direct distribution, though YouTube is also a concern and upload time is a factor. I've observed recently that YouTube processing time now relates closely with the size of the file you upload as opposed to any other factor - eg how long the video is. This is another reason why x264 is something I'm looking to stop doing because file sizes on 4K60 content are ginormous.

I've done a bunch of QP exports with Voukoder and weird stuff is happening. x265 medium produces a 93MB file. Here's how NvEnc medium works across a range of QP values:

QP20: 292MB
QP21: 250MB
QP22: 99MB (!)
QP23: 77MB
QP24: 64MB

As I said, I don't mind a bit of bloat vs x265, but I'm certainly curious why the difference between QP22 and QP21 is a reduction of 60 per cent!

poisondeathray

4th October 2019, 15:54

When someone has time can they post some Turing tests with some "typical" film/movie content? The earlier Meridian example is a bit atypical because it's "60p"

Specifically, I'm interested if it's possible to use decent bitrates and settings to preserve details and grain . Examples posted here and other forums show a lot of blurring and detail loss, but they were at lower bitrate ranges (relatively speaking, for the content)

Basically , can you encode a decent reproduction of the source? The context might be something like a good quality backup

Here is a 90 sec sample from another forum/thread
https://www.mediafire.com/file/7rt4lk38uvp9580/00023cut.mkv/file

Thanks

Atak_Snajpera

4th October 2019, 16:25

I've got something better - First ten minutes of John Carter Movie. It has everything. Noise,CGI,dynamic scenes, scenes with rain, dark scenes, close ups and so on
http://www.mediafire.com/file/dh86soca2m66n6b/video.mkv/file

Encode that file in three versions: 1Mbps,2Mbps,4Mbps

Do not forget to crop borders!
Crop(0,140,0,-140)

Sharc

4th October 2019, 18:41

Here is a 90 sec sample from another forum/thread
https://www.mediafire.com/file/7rt4lk38uvp9580/00023cut.mkv/file

I have some doubts whether the resolution of this source is truly 1920x1080. Looks more like an upscaled 1280x720 to me. I might be wrong though.

Edit:
I just noted it's VC-1 rather than AVC.

NikosD

4th October 2019, 19:14

poisondeathray

4th October 2019, 19:45

I have some doubts whether the resolution of this source is truly 1920x1080. Looks more like an upscaled 1280x720 to me. I might be wrong though.

Edit:
I just noted it's VC-1 rather than AVC.

IMO, the more tests, the merrier. Good to see some different variety of situations and content. That way you can learn where a given encoder is strong or weak, and you can help improve it with feedback to the developers

John Carter looks good , but it's not "truly 1920x1080" either , since it's not 16:9 AR

Personally, I'm less interested in very low bitrate ranges (in relation to a given source) - because you'd normally preprocess it / filter in the real world if encode for that scenario

excellentswordfight

4th October 2019, 19:49

My 3rd attempt in Crowd Run, but still you didn't tell me which one you prefer:
http://www.mediafire.com/file/fudbp1rfl0wtvab/crowd_run_1080p50_5.mkv/file

John Carter in a few minutes, still downloading...
Havnt had the time to analyze the two new ones that closly yet. But I just had a quick look at the latest one, and just quick still comparing on frame 200 showed that the new one had more artifacts and issues then the first one.

I'm as well is very interested in the john carter encode, mostly in the 4-6Mbps range. Which is in my experience the lower range were x265 can preserve enough detail for 1080p re-encodes to be considered high quality (crf19-20ish?). It is also in the bitrate range for the top of the ladder encodes for 1080p streaming.

NikosD

4th October 2019, 20:11

excellentswordfight

4th October 2019, 22:06

John Carter's challenge:
(I haven't registered to mediafire, so the files will be retained up to 14 days)

Two versions for every bitrate:
(Using StaxRip v2.0.4.8 and NVEncC v4.50)

4Mbps

Standard Quality: (~224 fps, CPU ~24%)
https://www.mediafire.com/file/huqus8s11esixoq/John_carter_std_quality_4Mbps.mkv/file

Enhanced Quality: (~205 fps, CPU ~19%)
https://www.mediafire.com/file/e8v1oq9nsc50p5t/John_carter_enhanced_quality_4Mbps.mkv/file

2Mbps

Standard Quality: (~224 fps, CPU ~24%)
https://www.mediafire.com/file/ojaak4ach4rm630/John_carter_std_quality_2Mbps.mkv/file

Enhanced Quality: (~206 fps, CPU ~19%)
https://www.mediafire.com/file/uf623w23y86its5/John_carter_enhanced_quality_2Mbps.mkv/file

1Mbps

Standard Quality: (~224 fps, CPU ~24%)
https://www.mediafire.com/file/0n3ut1aw4q1w6je/John_carter_std_quality_1Mbps.mkv/file

Enhanced Quality: (~207 fps, CPU ~19%)
https://www.mediafire.com/file/tayjol1k38vpxrc/John_carter_enhanced_quality_1Mbps.mkv/file
I wont bother with the 1 and 2Mbps ones, but both 4Mbps ones are pretty much awful. There is an very unflattering issue were detailed frames are alternating with a few frames interval with very flat frames causing a very nasty effect for complex sequences, there is usually two flat frames that also have some banding issues between the better ones (I would guess that there is an issue with the b-frames).

https://i.ibb.co/nCLcTbt/John-carter-enhanced-quality-4-Mbps-mkv-snapshot-02-01-2019-10-04-23-13-14.png
https://i.ibb.co/Z2mgk45/John-carter-enhanced-quality-4-Mbps-mkv-snapshot-02-01-2019-10-04-23-13-21.png

for reference this is the flat frame from an x265 encode @ 4Mbps with preset slow.
https://i.ibb.co/jM4BnXq/carter-mp4-snapshot-02-01-2019-10-04-23-27-51.png

NikosD

4th October 2019, 22:26

I wont bother with the 1 and 2Mbps ones, but both 4Mbps ones are pretty much awful. There is an very unflattering issue were detailed frames are alternating with a few frames interval with very flat frames causing a very nasty effect for complex sequences, there is usually two flat frames that also have some banding issues between the better ones (I would guess that there is an issue with the b-frames). Among other things/differences, the enhanced quality has B frames as Ref enabled and debanding enabled, which std quality obviously hasn't.
For both encodings B frames are 3.

But they shouldn't be the same.

I have a few things in mind to change.

What do you suggest ?

And if you had to choose one, which would it be ?

poisondeathray

4th October 2019, 22:29

Thanks for uploading those. Just looked at it quickly so far, but IMO not enough bitrate or incorrect settings. I wouldn't call this "high quality backup" or "similar to source".

They are watchable and clean, but details and objects like clouds, hair , etc.. are blurred away. It's like applying denoiser, lowpass, or blur filter. The whole point of HD, UHD(at least marketing wise) is "D" or "definition"

Not sure what "enhanced" is doing, on some frames more detail, but on others much less compared to "normal'.

Also - excellentswordfight metioned this above - frame quality strobing/flicker issues, more than on "normal" setting. Maybe some adjustment for I/B/P ratio needed

I know for the older NVENC AVC , there were CPU enhancements like AQ temporal and spatial , and it definitely helped in some scenarios - but they slowed down the encoding. It might help here, but a higher bitrate will definitely help

NO question it's fast . Other people are probably still encoding if using x265 LOL . Not sure how x265 stacks up at this bitrate range, or ideal settings to use, but it's something to look at in the next while

If you have the time , could you please upload some higher bitrate ones, maybe 6 ,8, 10 ?

excellentswordfight

4th October 2019, 22:53

Among other things/differences, the enhanced quality has B frames as Ref enabled and debanding enabled, which std quality obviously hasn't.
For both encodings B frames are 3.

But they shouldn't be the same.

I have a few things in mind to change.

What do you suggest ?

And if you had to choose one, which would it be ?
Well they are not the same, but they suffer from the same issues. I played back some of the sequences with issues side by side, and tbh I cant say that I preferred one over the other.
NO question it's fast . Other people are probably still encoding if using x265 LOL . Not sure how x265 stacks up at this bitrate range, or ideal settings to use, but it's something to look at in the next while

If you have the time , could you please upload some higher bitrate ones, maybe 6 ,8, 10 ?
Added an x265 sample as well for reference (an still image ofc doesn't tell the whole story though). But tbh, even if x265 struggles a bit at this bitrate given the grain, but I would say it actually looks pretty good, it's definitely passable. But the sample is very tough, so maybe a bump in bitrate would be interesting (but I find it more interesting keeping it in a rather tight bit budget). But even if its understandable that a encoder that fast struggle with that sample at that bitrate, the issues it displayed are very disappointing, HEVC is usually rather good at going low without falling apart like that, the frame strobing/flicker is very worrying.

poisondeathray

4th October 2019, 23:12

Added an x265 sample as well for reference (an still image ofc doesn't tell the whole story though). But tbh, even if x265 struggles a bit at this bitrate given the grain, but I would say it actually looks pretty good, it's definitely passable. Understandable though, it is a pretty rough sample since the start sequence is very tough.

For sure this one is tough, and that's why you need more bitrate if you want decent quality on this sample . For any encoder.

That's what I'm interested in. At what bitrate and settings can you achive a "good" similar to source encode with quality "Q" . Can encoder x,y or z do a better job achieving quality "Q" at a lower bitrate than another encoder ?

No doubt it's important to do the lower bitrate tests (relative for the source). But in real life, you'd probably use a proper denoiser rather than rely on the encoder to "denoise" or improve compressibility because you will get better results

Sharc

4th October 2019, 23:37

) But in real life, you'd probably use a proper denoiser rather than rely on the encoder to "denoise" or improve compressibility because you will get better results
Yes, but denoisers (avisynth) will spoil the speed advantage of HW encoders depending on CPU. NVEncC has its own denoisers btw. which may be worth to try.

gonca

4th October 2019, 23:42

@NikosD
I haven't seen your command line so try playing with
"C:\Program Files (Portable)\NVEncC\NVEncC64.exe" --vbrhq 38400 --codec h265 --preset quality --profile main10 --output-depth 10 --vbr-quality 20 --mv-precision q-pel --cabac
Or any of the settings to see if it helps

Sharc

4th October 2019, 23:49

I am usually using it with --vbrhq 0 --vbr-quality <float> which is NVEncC's constant quality mode.

gonca

4th October 2019, 23:57

I am usually using it with --vbrhq 0 --vbr-quality <float> which is NVEncC's constant quality mode.
Sorry I was editing as you posted

NikosD

4th October 2019, 23:59

For reference this is the flat frame from an x265 encode @ 4Mbps with preset slow. 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 know for the older NVENC AVC , there were CPU enhancements like AQ temporal and spatial , and it definitely helped in some scenarios - but they slowed down the encoding. No CPU was involved in any stage of the transcoding.
NVENC nowadays uses mainly fixed-function hardware and for the other uses like all modes of AQ, Lookahead and 2-pass (HQ) encoding, it uses GPU (CUDA cores)
I used both of them for all my encodings so far, but for the simple quality encodings below, I used AQ Temporal only.

Maybe using them together caused those problems ?

But I used them both on my first Crowd Run sample, too.
NO question it's fast . Other people are probably still encoding if using x265 LOL . Not sure how x265 stacks up at this bitrate range, or ideal settings to use, but it's something to look at in the next while Definitely, I would like to see some x265 encodings too, even if it takes a week to complete the encoding :D

Back to encodings:

4Mbps

Simple Quality: (~224 fps, CPU ~24%)
https://www.mediafire.com/file/kapz2y7tl8ceruo/John_carter_simple_quality_4Mbps.mkv/file

6Mbps

Simple Quality: (~224 fps, CPU ~24%)
https://www.mediafire.com/file/law6zs6sv6fyxch/John_carter_simple_quality_6Mbps.mkv/file

Little Enhanced Quality: (~224 fps, CPU ~24%)
https://www.mediafire.com/file/bjdrykbwgqexghf/John_carter_little_enhanced_quality_6Mbps.mkv/file

More than 6Mbps bitrate, results to a bigger file which takes time to upload and I prefer to avoid it.

It's very fast to produce it and very slow to upload it (5 Mbps upload)

IgorC

5th October 2019, 00:08

Sharc

5th October 2019, 10:19

P.S. I just have got a laptop with a GTX 1650 which has Volta NVENC.
GTX 1650 does not support B-frames in HEVC. If you want B-frames you could try h264 AVC instead.

Sharc

5th October 2019, 12:15

Back to encodings:

6Mbps

Little Enhanced Quality: (~224 fps, CPU ~24%)
https://www.mediafire.com/file/bjdrykbwgqexghf/John_carter_little_enhanced_quality_6Mbps.mkv/file

More details and better contrast in flat scenes - especially for B-frames - compared with 4Mbps, but still little banding.
By far good enough for normal viewing on TV IMHO. I doubt whether in blind tests 'uneducated' viewers would have a clear preference for x265 or NVEncC for bitrates above about 5Mbps.

Sharc

5th October 2019, 13:39

FWIW JohnCarter encoded with h264 8bit NVEncC, on Pascal 1050Ti, 350fps.
https://www.mediafire.com/file/eqyf4j6wdaqjl8n/JohnCarter_h264_NVEncC_6Mbps.mkv/file

NikosD

5th October 2019, 14:01

Basically, can you encode a decent reproduction of the source?
The context might be something like a good quality backup.

Here is a 90 sec sample from another forum/thread
https://www.mediafire.com/file/7rt4lk38uvp9580/00023cut.mkv/file I think it's easy if you increase bitrate enough to make the encoding extremely close to the source.

I prefer something more difficult, at low 5Mbps bitrate.

Two versions for your clip:

5Mbps

Little More Enhanced Quality: (~153 fps, CPU ~17%)
https://www.mediafire.com/file/kehzjcq6j6deh2n/00023_little_more_enhanced_5Mbps.mkv/file

Constant Quality Enhanced: (~152 fps, CPU ~17%)
https://www.mediafire.com/file/6suo0vany3f1rlq/00023_Constant_Quality_Enhanced_5Mbps.mkv/file

Atak_Snajpera

5th October 2019, 18:27

Reality check...
NVENC TURING 4Mbps
https://i.imgsafe.org/8c/8c9b91493e.png

x265-medium-4Mbps
https://i.imgsafe.org/8b/8bfd362f53.png

x264-veryslow-4Mbps
https://i.imgsafe.org/8b/8bf6f96df3.png

x264-veryslow-MDegrain2-4Mbps
https://i.imgsafe.org/8b/8bf4b6b607.png

Encoded files
x264
https://www.mediafire.com/file/iwlxgtvum01eszc/x264-veryslow-1Mbps.mkv/file
https://www.mediafire.com/file/6piveuinvruj1fc/x264-veryslow-2Mbps.mkv/file
https://www.mediafire.com/file/kd4p3crayht19xx/x264-veryslow-4Mbps.mkv/file
https://www.mediafire.com/file/94ldr0r3dfiq6sn/x264-veryslow-MDegrain2-4Mbps.mkv/file

x265
https://www.mediafire.com/file/zobmxvj6c7sniz5/x265-medium-1Mbps.mkv/file
https://www.mediafire.com/file/5onbpleywnhxdyf/x265-medium-2Mbps.mkv/file
https://www.mediafire.com/file/s0c79c7gng9nhdo/x265-medium-4Mbps.mkv/file

sneaker_ger

5th October 2019, 22:43

I know for the older NVENC AVC , there were CPU enhancements like AQ temporal and spatial , and it definitely helped in some scenarios
I added --aq and --aq-temporal. They are no magic fix.

https://abload.de/img/2906_sourcedmjxb.png
https://abload.de/img/2906_1660tizxjxz.png (4 Mbps)
https://abload.de/img/2906_1660ti_10.3mbps_dpjtq.png (10.3 Mbps)

https://abload.de/img/4201_sourcebukul.png
https://abload.de/img/4201_1660ti7ojag.png (4 Mbps)
https://abload.de/img/4201_1660ti_10.3mbps_77k80.png (10.3 Mbps)

nvencc64 -c hevc --vbrhq 0 --vbr-quality [20-26] --max-bitrate 100000 -u quality --output-depth 10 --lookahead 32 -b 5 --ref 7 --nonrefp --aq --aq-temporal --bref-mode middle --mv-precision q-pel --fps 24000/1001 --crop 0,140,0,140 --sar 1:1 --log 1660ti_carter_[20-26].txt --avhw -i "video.mkv" -o 1660ti_carter_[20-26].265
(NVEncC logs in the MEGA folder)

If you have the time , could you please upload some higher bitrate ones, maybe 6 ,8, 10 ?
I added some higher bitrates. Results improve. Of course you end up wondering where the sweet spot for NVENC is, i.e. at which point does it make more sense than a very fast preset x264.
https://mega.nz/#F!Rl9E0AgT!cDKsRO4g0Mxo5TIGR06FSw

poisondeathray

5th October 2019, 23:57

Thanks for the new encodes, keep it coming. The more the merrier, this is how you learn about an encoder strengths/weaknesses and possibly how to improve them too

@ sneaker - Curiously that frame strobing quality issue is less prevalent in your NVEnc Meridian example compared to here. Yet you would expect it there because of the grain

Can you guys post the actual command lines used ?

NikosD

6th October 2019, 08:13

Thanks for the new encodes, keep it coming. The more the merrier, this is how you learn about an encoder strengths/weaknesses and possibly how to improve them too

Can you guys post the actual command lines used ? 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/hop6rb2ciuqqv07/John_carter_simple_enhanced_quality_4Mbps.mkv/file

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

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

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

Sharc

6th October 2019, 10:36

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/hop6rb2ciuqqv07/John_carter_simple_enhanced_quality_4Mbps.mkv/file

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

Constant Enhanced Quality (206fps, CPU ~20%, GPU ~46%)
https://www.mediafire.com/file/6pw3733cyty5ad0/John_carter_constant_enhanced_quality_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

6th October 2019, 11:11

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

6th October 2019, 11:38

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

6th October 2019, 13:11

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/90zfam8qps4xwz5/John_carter_simple_enhanced_quality_wo_denoisers_4Mbps.mkv/file

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

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

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

Atak_Snajpera

6th October 2019, 14:25

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

6th October 2019, 15:08

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/90zfam8qps4xwz5/John_carter_simple_enhanced_quality_wo_denoisers_4Mbps.mkv/file

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

Constant -Enhanced Quality without de-noisers (202fps, CPU ~17%)
https://www.mediafire.com/file/g76b3a8p7242qmj/John_carter_constant_enhanced_quality_wo_denoisers_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

6th October 2019, 15:30

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

6th October 2019, 15:53

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

6th October 2019, 16:23

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

6th October 2019, 16:28

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

6th October 2019, 18:45

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

6th October 2019, 20:11

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.

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

7th October 2019, 09:19

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

7th October 2019, 16:32

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/releases/download/4.51/NVEncC_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

7th October 2019, 17:11

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

7th October 2019, 17:37

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

7th October 2019, 17:38

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)