Turing GPU cards and 10 bit HEVC

[johnvick]

Hi,

I encode 1080 TV rips using Handbrake and a Ryzen 2400G - CPU averages 12 fps, using the GPU 70 fps but bigger files and lesser quality (and no 10 bit encoding).

On a Surface Book 2 laptop using Intel Core i5 I get 30 fps using GPU and better quality than the Ryzen GPU for similar files size.

I am wondering if the NVIDIA Turing graphics cards are likely to be able to match CPU quality and file size - anyone tried this?

John

[sauvage78]

Yes, they do. I recently bought an RTX card to test it by myself after reading this https://unrealaussies.com/tech/nvenc-x264-quicksync-qsv-vp9-av1/ & I got the same result, Turing HEVC is very, very good for its awesome speed.

[RanmaCanada]

Basically, as long as you’re not starving for bitrate, Turing is on par with x265 Slow <-- Hardware needs more bitrate to compare to CPU. Current ASICS can not compare to x265 slow when you are going for the smallest file size possible. But the fact that you are getting 12fps on a 2400G means you aren't doing "quality" encodes, as on my 2700 I get 7-8 fps doing 1080p TV rips on slow.

The longer the encoding process, the better the end results.

[johnvick]

Thanks for the advice, helps with the buying decision. What sort of fps do you get with the turing card?

[Atak_Snajpera]

Can somebody encode parkjoy.y4m using turing encoder? Let's say 2pass 10 Mbps.

[Asmodian]

Can you provide a link so we start with the right encode? :)

Edit:
I assume: https://media.xiph.org/video/derf/ is the right source.

I used this command line on my 2080 Ti:
C:\Tools\ffmpeg\bin\ffmpeg -loglevel debug -threads 1 -i %1 -c:v hevc_nvenc -b:v 10M -maxrate:v 15M -bufsize:v 12M -preset slow -profile:v main10 -rc vbr_hq -rc-lookahead:v 32 -spatial_aq:v 1 -aq-strength:v 8 -c:a none -pix_fmt yuv420p10le -f mp4 "D:\encode\output.mp4"

Park_Joy_3840x2160_NVEnc_HEVC_yuv420p10le.mp4 (https://www.mediafire.com/file/dthzulhve6k3cig/Park_Joy_3840x2160_NVEnc_HEVC_yuv420p10le.mp4/file)

[sneaker_ger]

GTX 1660 Ti 1080p and 2160p "Park Joy".
ffmpeg -i "park_joy_1080p50.y4m" -f yuv4mpegpipe -strict -1 - | nvencc64 -c hevc --vbrhq 0 --vbr-quality 31 -u quality --output-depth 10 --lookahead 32 -b 5 --ref 7 --nonrefp --aq --aq-temporal --bref-mode middle --mv-precision q-pel -i - -o "park_joy_1080p50_31.mkv"
ffmpeg -i "park_joy_2160p50.y4m" -f yuv4mpegpipe -strict -1 - | nvencc64 -c hevc --vbrhq 0 --vbr-quality 40.5 -u quality --output-depth 10 --lookahead 32 -b 5 --ref 7 --nonrefp --aq --aq-temporal --bref-mode middle --mv-precision q-pel -i - -o "park_joy_2160p50_40.5.mkv"
x264 "park_joy_1080p50.y4m" --preset veryslow --tune film --pass 1 --bitrate 10000 -o "park_joy_1080p50_x264.264"
x264 "park_joy_1080p50.y4m" --preset veryslow --tune film --pass 2 --bitrate 10000 -o "park_joy_1080p50_x264.264"

Output files:
https://mega.nz/#F!gs9XkKbY!e6AqQ0Vi6m1PAGQMJu0zZQ

[Atak_Snajpera]

GTX 1660 Ti 1080p and 2160p "Park Joy".
ffmpeg -i "park_joy_1080p50.y4m" -f yuv4mpegpipe -strict -1 - | nvencc64 -c hevc --vbrhq 0 --vbr-quality 31 -u quality --output-depth 10 --lookahead 32 -b 5 --ref 7 --nonrefp --aq --aq-temporal --bref-mode middle --mv-precision q-pel -i - -o "park_joy_1080p50_31.mkv"
ffmpeg -i "park_joy_2160p50.y4m" -f yuv4mpegpipe -strict -1 - | nvencc64 -c hevc --vbrhq 0 --vbr-quality 40.5 -u quality --output-depth 10 --lookahead 32 -b 5 --ref 7 --nonrefp --aq --aq-temporal --bref-mode middle --mv-precision q-pel -i - -o "park_joy_2160p50_40.5.mkv"
x264 "park_joy_1080p50.y4m" --preset veryslow --tune film --pass 1 --bitrate 10000 -o "park_joy_1080p50_x264.264"
x264 "park_joy_1080p50.y4m" --preset veryslow --tune film --pass 2 --bitrate 10000 -o "park_joy_1080p50_x264.264"

Output files:
https://mega.nz/#F!gs9XkKbY!e6AqQ0Vi6m1PAGQMJu0zZQ

Thanks!
Looks like old good x264 is still in higher league ;)
x264 (AVC)
https://i.imgsafe.org/f6/f6fe9758cb.png

NVidia Turing (HEVC)
https://i.imgsafe.org/f6/f6fe71322c.png

[sneaker_ger]

x264 does much better on the textures, yes. But to be fair: park joy is a killer sample and x264 shows some heavy artifacts. x264 --preset veryslow --tune film --crf 20 ends up using 48733.96 kbps. Above we only used 1/5 of that.

[Atak_Snajpera]

x264 does much better on the textures, yes. But to be fair: park joy is a killer sample and x264 shows some heavy artifacts. x264 --preset veryslow --tune film --crf 20 ends up using 48733.96 kbps. Above we only used 1/5 of that.

That sample separates men from boys ;) Crowd run is also a killer sample...

[poisondeathray]

It's nice to see different types of samples and something other than video game tests. More tests please

[RanmaCanada]

Why are you using quality in one and bitrate in another? If we are going to do apples to apples, it should be quality vs crf (as GPU has no CRF) and the resulting file size, as that is as close as we can come to not using a strict bitrate limit to see the difference. Am I right in assuming this, or so wrong that I'm dumb for even stating it?

[Atak_Snajpera]

Why are you using quality in one and bitrate in another? If we are going to do apples to apples, it should be quality vs crf (as GPU has no CRF) and the resulting file size, as that is as close as we can come to not using a strict bitrate limit to see the difference. Am I right in assuming this, or so wrong that I'm dumb for even stating it?

x264 at the same file size looks noticeable better. If nvenc does not support 2-pass mode then it sucks even more. End of story.

[sneaker_ger]

FWIW: I added encodes at ~20 and ~50 Mbps to the MEGA folder.

Here (https://forum.doom9.org/showpost.php?p=1881067&postcount=331) you can find a short test I did on a sample that's more like your typical Hollywood movie/show. I believe there the difference isn't that much. x264 with its usual better keeping of the graininess and sharpness in exchange for some more uglier artifacts here and there. I think the x264 artifacts are best seen in motion and not so much in the screenshots.

[RanmaCanada]

But the whole point of x265 is to have smaller files with a given trade off for visuals. The idea is to have the smallest files possible with the best visuals. GPU requires much more bitrate than CPU does. Take the same samples and bring the bitrate down to 1000, 1500, 2000 and you would see that CPU destroys GPU. At 10mbit, even divx/xvid would look fantastic.

10mbit is extremely high for x265, at least in my experience.

[Atak_Snajpera]

We are taking about x264 vs nvenc h.265 not x265! If you think that 10mbps is alot then encode parkjoy or crowdrun sample with that xvid and then show us what mess you got.

[poisondeathray]

FWIW: I added encodes at ~20 and ~50 Mbps to the MEGA folder.

Here (https://forum.doom9.org/showpost.php?p=1881067&postcount=331) you can find a short test I did on a sample that's more like your typical Hollywood movie/show. I believe there the difference isn't that much. x264 with its usual better keeping of the graininess and sharpness in exchange for some more uglier artifacts here and there. I think the x264 artifacts are best seen in motion and not so much in the screenshots.


Thanks sneaker,

Can you add x264 10bit , x264 10bit encodes as well ?

As you know ,x265 is highly adjustable- if you're going for smoother, cleaner vs. detail retention , vs. whatever

And what about Turing? Is there some set of settings that enables it to retain more details vs. smoothing trade off ?

[gonca]

How about testing x264 vs NVEnc H264
Keep it closer to apples to apples
Maybe even x265 to NVEnc HEVC
Maybe even try NVEncC (instead of ffmpeg) in case there are some differences

[benwaggoner]

x264 at the same file size looks noticeable better. If nvenc does not support 2-pass mode then it sucks even more. End of story.
Well, we are talking independent and dependent variables here. We care on net about quality @ perf @ bitrate. If encoding time isn't that big a concern, one wouldn't use the GPU HW anyway.

There are certainly encode times where Turing HEVC will outperform x264. Also, Turing encodes can happen in parallel to CPU tasks. So on GPU encoding is very nice for things like Twitch where gaming performance can't be impacted much during real-time encoding.

[excellentswordfight]

How about testing x264 vs NVEnc H264
Keep it closer to apples to apples
Maybe even x265 to NVEnc HEVC
Maybe even try NVEncC (instead of ffmpeg) in case there are some differences
Speaking of apples to apples, I'm more interested in speed, if encoder A is 4x slower then encoder B, I might not care if its 20% more effective.

I would like to see Tears of Steal @ 1080p encoded in the 4-8Mbps range, and tune x264 at the same speed as nvenc. I havnt actually seen how turing HEVC perform in the "rip" scenario so it would be interesting to see how it performs for more "real" movie content.

[Atak_Snajpera]

Speaking of apples to apples, I'm more interested in speed, if encoder A is 4x slower then encoder B, I might not care if its 20% more effective.

I would like to see Tears of Steal @ 1080p encoded in the 4-8Mbps range, and tune x264 at the same speed as nvenc. I havnt actually seen how turing HEVC perform in the "rip" scenario so it would be interesting to see how it performs for more "real" movie content.

You do realize that we have cpus with many cores? You will have different results on 32 core and on 4 core. For example epyc 2 64c/128t can encode 8k at 79 FPS using x265

[sneaker_ger]

How about testing
[...]
Maybe even x265 to NVEnc HEVC
No one is stopping you from testing this. We have provided the source files and NVENC encodes necessary. You only have to contribute the x265 encodes.

[sneaker_ger]

I would like to see Tears of Steal @ 1080p encoded in the 4-8Mbps range
Here you go (from 1332 to 9015 kbps):
https://mega.nz/#F!MoVWDQBZ!nj8PkYm8Kf0hnF0-3EU-aA

Source file:
http://ftp.nluug.nl/pub/graphics/blender/demo/movies/ToS/tearsofsteel_4k.mov

[excellentswordfight]

Here you go (from 1332 to 9015 kbps):
https://mega.nz/#F!MoVWDQBZ!nj8PkYm8Kf0hnF0-3EU-aA

Source file:
http://ftp.nluug.nl/pub/graphics/blender/demo/movies/ToS/tearsofsteel_4k.mov
Wow, thank you!

I was very impressed at first, given the performance on a pretty cheap mid range card. And quality seemed to be good enough when I first looked at it, but when I started to compare it against x264 at faster presets I saw some extremely bad artifacts. there are blocks of texture, that transitions very harshly with smooth areas.

This is from the 5mpbs one

https://i.imgur.com/rIReIon.png

x264 with faster preset and tune film is by no means visually transparent at 5Mbps, and it smooths quite a bit, but it contains far less artifacts.

[sneaker_ger]

What frame numbers are those from? I would like to test some more settings to see if that problem can be solved. I'm new to NVENC myself. (NVENCC --aq-strength setting doesn't seem to do anything at all with HEVC.)

[excellentswordfight]

What frame numbers are those from? I would like to test some more settings to see if that problem can be solved. I'm new to NVENC myself. (NVENCC --aq-strength setting doesn't seem to do anything at all with HEVC.)
f9296 give or take 2-3f.

I looked at the 9Mbps one as well, while not as bad, it has the same issue that areas with noise and a lot of detail is divided by blocks.

[gonca]

No one is stopping you from testing this. We have provided the source files and NVENC encodes necessary. You only have to contribute the x265 encodes.
No Turing card is stopping me

[sneaker_ger]

Asmodian and I already provided the Turing encodes. You only need to add your x265 encode to compare.

[sneaker_ger]

I was very impressed at first, given the performance on a pretty cheap mid range card. And quality seemed to be good enough when I first looked at it, but when I started to compare it against x264 at faster presets I saw some extremely bad artifacts. there are blocks of texture, that transitions very harshly with smooth areas.
Intererstingly, it looks like there is some kind of slice-like division (though there are no multiple slices in the HEVC/AVC sense). The borders are at the same height on the left as they are on the right side. So maybe this is from parallel processing in the chip and the bits aren't distributed fairly.
https://i.imgur.com/f2U62am.jpg

I can even reproduce it when encoding a single frame. This has to be a bug, right?

[Atak_Snajpera]

Intererstingly, it looks like there is some kind of slice-like division (though there are no multiple slices in the HEVC/AVC sense). The borders are at the same height on the left as they are on the right side. So maybe this is from parallel processing in the chip and the bits aren't distributed fairly.
https://i.imgur.com/f2U62am.jpg

I can even reproduce it when encoding a single frame. This has to be a bug, right?

...or trick to achieve high speed on GPU.

[sneaker_ger]

Good news: if I resize in AviSynth instead of using NVENCC resizing the borders are gone.
Bad news: now everything is blurry (and slow...)

https://abload.de/img/redo235qmkp2.png
(nvenc_hevc_23.5redo.mp4 in MEGA folder)

[excellentswordfight]

Good news: if I resize in AviSynth instead of using NVENCC resizing the borders are gone.
Bad news: now everything is blurry (and slow...)

https://abload.de/img/redo235qmkp2.png
(nvenc_hevc_23.5redo.mp4 in MEGA folder)
It also seem to have a big impact on vbr quality value and bitrate (redo has same size as the old q 26).

Seems very odd, do you know if the previous method of resize is done in HW or SW? I can see that spline is defined in the script, is this supported in hw?

I also noted that you specify ref 7 in the encoder, but the encoded file is still reported as level 4. Isnt this out of specc for that frame size? But I guess that this is no different as when a high ref value is used for x264/x265.

edit. Yes I looks a bit soft, but its very artifact free. And the x264 encode at faster isnt that much sharper.

[NikosD]

Good news: if I resize in AviSynth instead of using NVENCC resizing the borders are gone.
I would suggest trying also NVencC from rigaya, directly as a command-line tool (like ffmpeg) or using a GUI like StaxRip.

I'm also new to NVENC but I'll try to encode ParkJoy using my 1660 and upload a few samples during weekend.

My main issue is that I can barely see differences between various encodings, so it's difficult for me to improve quality trying different settings.

[poisondeathray]

Seems very odd, do you know if the previous method of resize is done in HW or SW? I can see that spline is defined in the script, is this supported in hw?


Previously used NVEnc --vpp so HW resizing. That' s probably why it was so much faster too

But strictly speaking, "resize" should be excluded from an encoder comparison, because the variable you are testing is the encoder. A lossless intermediate should be used that uses the same resize method to control variables (e.g. Nvidia's spline16 might be slightly different from avisynths' spline16 implementation, qualitatively). And hopefully from SSD or ramdrive to eliminiate I/O bottlenecks . This way the encoder's full "speed" can be measured as well. Otherwise you are polluting the test data with the speed penalty of avisynth or whatever processing. Avisynth resizing on the fly is probably bottlenecking NVEnc speed. (BTW - This is not a knock against sneaker ; he knows this stuff for sure, I'm sure he just quickly posted some results)

But if you want to design separate tests, factoring in resizing speed, filtering speed start to finish, that's appropriate too - but you could not apply those conclusions strictly speaking to just a specific encoder . You have to be careful on what conclusions are made from those specific tests.




I would suggest trying also NVencC from rigaya, directly as a command-line tool (like ffmpeg) or using a GUI like StaxRip.


Sneaker did use NVEncC ...

[NikosD]

Sneaker did use NVEncC ... For the encoding part only, of the whole pipeline of transcoding and at the second try he changed to Avisynth.

Maybe trying StaxRip's decoding/ pre-post processing methods and NVencC's native decoding (if I remember correctly that it has)

[Asmodian]

Native decoding is not going to change the quality..... and if you are comparing x264/5 v.s. NVenc why would you preprocess the video only for NVenc?

[sneaker_ger]

Yeah, sorry folks, I got lazy. Though I'm kinda glad to find this.

Test:
nvencc64 --lossless --output-res 1920x858 --sar 1:1 --vpp-resize spline16 --avhw -i tearsofsteel_4k.mov -o lossless.mp4
nvencc64 -c hevc --vbrhq 0 --vbr-quality 23.5 -u quality --max-bitrate 100000 --output-depth 10 --lookahead 32 -b 5 --ref 7 --nonrefp --aq --aq-temporal --bref-mode middle --mv-precision q-pel --fps 24 --sar 1:1 --log nvenc_hevc_235redoll.txt -i lossless.mp4 -o "nvenc_hevc_23.5redoll.265"
ffmpeg -hwaccel nvdec -i lossless.mp4 -pix_fmt yuv420p -f yuv4mpegpipe - | nvencc64 -c hevc --vbrhq 0 --vbr-quality 23.5 -u quality --max-bitrate 100000 --output-depth 10 --lookahead 32 -b 5 --ref 7 --nonrefp --aq --aq-temporal --bref-mode middle --mv-precision q-pel --fps 24 --sar 1:1 --log nvenc_hevc_235redoll.txt -i - -o "nvenc_hevc_23.5redollff.265"
nvencc64 -c hevc --vbrhq 0 --vbr-quality 23.5 -u quality --max-bitrate 100000 --output-depth 10 --lookahead 32 -b 5 --ref 7 --nonrefp --aq --aq-temporal --bref-mode middle --mv-precision q-pel --output-res 1920x858 --vpp-resize spline16 --fps 24 --sar 1:1 --log nvenc_hevc_235redollres.txt -i tearsofsteel_4k.mov -o "nvenc_hevc_23.5redollres.265"

Results:
md5sum *.265
3fc06fa71b9296a8d02615cbc1120266 *nvenc_hevc_23.5redoll.265 (679,960,787 Bytes)
3fc06fa71b9296a8d02615cbc1120266 *nvenc_hevc_23.5redollff.265 (679,960,787 Bytes)
8c235b6c4b781a9d78c0149d18e9ea76 *nvenc_hevc_23.5redollres.265 (677,089,067 Bytes)
(Results are deterministic.)

Maybe I made some mistakes in the tests the other day.

[sneaker_ger]

Ok, the "slicing" issue seems to be from the resizer, not the encoding. Even the lossless intermediate has it. The "blurry" re-encode is actually more true to the source. The resizing adds sharpening on every other "slice"?

https://abload.de/img/madvrh0krn.png (source via madvr)
https://abload.de/img/lossless_intermediatenzk2i.png (lossless intermediate resized by nvencc spline16)

/edit:
Rigaya fixed the Spline16 resizing bug with NVEncC 4.50.

[sneaker_ger]

What's new with Turing GPUs and Video Codec SDK 9.1
NEW to 9.1- Encode: CUStream support in NVENC for enhanced parallelism between CUDA pre-processing and NVENC encoding
NEW to 9.1- Encode: Filler NALU insertion for achieving true CBR
NEW to 9.1- Encode: Control the number of reference frames used by NVENC (Turing GPUs only)
NEW to 9.1- Decode: Memory optimizations in sample applications
-----

[NikosD]

That sample separates men from boys ;) Crowd run is also a killer sample... For my friend Atak_Snajpera and the Original Poster (@johnvic) ...

In just a few seconds using StaxRip and NVEncC with a speed of ~160 fps, you can take a source of 1.5GB size (crowd_run_1080p50.y4m) and convert it to an ~12MB size H.265 file of ~10 Mb/s average bitrate.

Please, give me a better x264/x265 transcode and tell me how many hours you needed for that:
http://www.mediafire.com/file/yj8xdg8p4u3m7a4/crowd_run_1080p50.mkv/file

[RanmaCanada]

For my friend Atak_Snajpera and the Original Poster (@johnvic) ...

In just a few seconds using StaxRip and NVEncC with a speed of ~160 fps, you can take a source of 1.5GB size (crowd_run_1080p50.y4m) and convert it to an ~12MB size H.265 file of ~10 Mb/s average bitrate.

Please, give me a better x264/x265 transcode and tell me how many hours you needed for that:
http://www.mediafire.com/file/yj8xdg8p4u3m7a4/crowd_run_1080p50.mkv/file

Except the point of x265 is to get the same appreciable visual quality with the least possible bitrate. Bloating it to 10mbps is insane. How about you try the same encode at 2mbps and see what one is better.

We get it, you like the speed, but more of us are concerned with quality.

I would personally do the 2mbps x265 encode, but I am currently encoding at my system will be in use for another 12 hours or so, and there are other users here who are far more versed in x265 than I.

[NikosD]

Except the point of x265 is to get the same appreciable visual quality with the least possible bitrate. Bloating it to 10mbps is insane. How about you try the same encode at 2mbps and see what one is better.



We get it, you like the speed, but more of us are concerned with quality.



I would personally do the 2mbps x265 encode, but I am currently encoding at my system will be in use for another 12 hours or so, and there are other users here who are far more versed in x265 than I. I just replied to a challenge of 10Mbps by Atak.

Your challenge is different and I'm ready to reply to that too, after you provide a x265 encoding at 2Mbps of the Crowd Run sample.

I know less of H.264/H.265 encodings than you or other encoding experts here, so the "Turing effect" is even more valuable.

I can wait one, two days, one week or more to extract as much quality as you possibly can, using your CPU and x265 to produce the 2Mbps encoding.

But for that sample, 2Mbps bitrate is more insane than 10Mbps bitrate, I think.

[excellentswordfight]

Bloating it to 10mbps is insane. How about you try the same encode at 2mbps and see what one is better.
Do you know what sample you are talking about? That bitrate is by no means bloated or insane for that sample. For example I need to increase the crf value to over 30 to be able to hit that bitrate with x265 at preset slow. Neither nvenc and x265 can handle that sample @ 10Mbps with good quality, they both struggle.
I just replied to a challenge of 10Mbps by Atak.

Your challenge is different and I'm ready to reply to that too, after you provide a x265 encoding at 2Mbps of the Crowd Run sample.

I know less of H.264/H.265 encodings than you or other encoding experts here, so the "Turing effect" is even more valuable.

I can wait one, two days, one week or more to extract as much quality as you possibly can, using your CPU and x265 to produce the 2Mbps encoding.

But for that sample, 2Mbps bitrate is more insane than 10Mbps bitrate, I think.
I had a look at that encode, and tbh it's very impressive. I compared a bit to x265 preset slow, and it actually looks better in some areas! Its a bit of an mixed bag though, but in general I would say that x265 is sharper/more detailed but has more artifacts. My subjective opinion under normal playback is that they are comparable in terms of quality, they both have strengths and weaknesses. But with that say, I woudlnt say that either of them looked good.

[NikosD]

Does anyone have access to latest PDF of nVidia regarding NVENC API Programming guide ?

It seems that nVidia keeps this top secret information hidden from public eyes.

[videoh]

It's in the doc folder of the Video Codec SDK.

[NikosD]

It's in the doc folder of the Video Codec SDK. Which requires membership of the nVidia developer program, in order to download it.

Is it possible to upload the PDF somewhere more easily accessible ?

Thanks.

[videoh]

Send me a PM with an email address and I'll get it to you.

I'd recommend joining the program too.

[Taurus]

@NikosD
In just a few seconds using StaxRip and NVEncC with a speed of ~160 fps,
you can take a source of 1.5GB size (crowd_run_1080p50.y4m)
and convert it to an ~12MB size H.265 file of ~10 Mb/s average bitrate.
Is this done with: Win 10 x64 (18362.356) - Core i3-9100F - nVidia 1660 (436.15) from you signature?
What settings on NVEncC did you use? Defaults?
I have a NVidia 1660 at hands and like to duplicate your attempts.
Thank you!

[DJATOM]

> Which requires membership of the nVidia developer program, in order to download it.
You can get it for free. It didn't cost me anything to sign for that membership. I just wanted to compile some stuff and needed SDK files for it in the past.

[NikosD]

@NikosD

Is this done with: from you signature?
What settings on NVEncC did you use? Defaults?
I have a NVidia 1660 at hands and like to duplicate your attempts.
Thank you! Yes, my signature system is the encoding system.

The encoding parameters are still a moving target.

When we agree what is the best, I will give them in public. I had a look at that encode, and tbh it's very impressive. I compared a bit to x265 preset slow, and it actually looks better in some areas! Its a bit of an mixed bag though, but in general I would say that x265 is sharper/more detailed but has more artifacts. My subjective opinion under normal playback is that they are comparable in terms of quality, they both have strengths and weaknesses. But with that say, I woudlnt say that either of them looked good. Can you take a look at my second try ?

I read in just a few minutes the NVENC API guide by nVidia (thanks Don -videoh) and changed a few parameters dropping a lot the encoding speed from ~160fps to ~55fps, I hope the quality to have been raised proportionally.

Second encoding of Crowd Run using Turing's HEVC encoder:
http://www.mediafire.com/file/m2jb63pysakkpnp/crowd_run_1080p50_2.mkv/file

Please, give me your feedback compared to the first encoding.

Update:
It was probably a random/non systematic/instant issue of my system, regarding that drop in encoding speed.
I can't reproduce that low speed, even with the most taxing encoding parameters.

The speed is always ~150fps to 155fps during all my "high-quality" tests.