Turing GPU cards and 10 bit HEVC

[Atak_Snajpera]

Originally Posted by excellentswordfight

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]

Originally Posted by gonca

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]

Originally Posted by excellentswordfight

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/ble...ofsteel_4k.mov

[excellentswordfight]

Originally Posted by sneaker_ger

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

Source file:
http://ftp.nluug.nl/pub/graphics/ble...ofsteel_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



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]

Originally Posted by 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.)

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]

Originally Posted by sneaker_ger

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]

Originally Posted by excellentswordfight

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]

Originally Posted by sneaker_ger

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]

Originally Posted by 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)

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]

Originally Posted by sneaker_ger

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]

Originally Posted by excellentswordfight

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.

Originally Posted by NikosD

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]

Originally Posted by poisondeathray

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]

Originally Posted by Atak_Snajpera

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/yj8xdg...80p50.mkv/file