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.

[easy2Bcheesy]

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]

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]

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]

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]

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]

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]

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]

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...

[poisondeathray]

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]

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]

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

[excellentswordfight]

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]

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]

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]

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]

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]

) 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]

@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]

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

[gonca]

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]

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]

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
Is there x265 file to compare?

P.S. I just have got a laptop with a GTX 1650 which has Volta NVENC. If I just knew that 1660 is that good and fast for HEVC encoding.

[Sharc]

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]

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]

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

[NikosD]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

John_carter_enhanced_quality_4Mbps.mkv

[NikosD]

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]

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 ?

[Atak_Snajpera]

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

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

It is frame 2077 so now you can check on your own.

Was there some other filtering in the display chain ?
It is my recent Enhanced x264 encode with pre-denoising and my own sharpening technique.

Loadplugin("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\AviSynth plugins\mvtools\mvtools2.dll")
super=MSuper(video,pel=2)
fv1=MAnalyse(super,isb=false,delta=1,overlap=4)
bv1=MAnalyse(super,isb=true,delta=1,overlap=4)
fv2=MAnalyse(super,isb=false,delta=2,overlap=4)
bv2=MAnalyse(super,isb=true,delta=2,overlap=4)
video=MDegrain2(video,super,bv1,fv1,bv2,fv2,thSAD=400)

LoadPlugin("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\AviSynth plugins\Plugins_JPSDR\Plugins_JPSDR.dll")
IntensityMask=ConvertToY8(video).Levels(0,2,255,0,255,coring=false)
EdgeMask=aSobel(IntensityMask,chroma=0,thresh=255,SetAffinity=false).invert.Levels(0,2,255,0,255,coring=false).Blur(1)
SharpMask=Overlay(IntensityMask,EdgeMask,mode="Multiply",opacity=1.0)
SharpenedVideo=Sharpen(video,1)
video=Overlay(video,SharpenedVideo,mask=SharpMask,opacity=1.0)

[NikosD]

It is frame 2077 so now you can check on your own. Ok, but just keep in mind that Turing's HEVC encoder best settings is a work in progress, it's not like x264/x265.

So, let's try to follow the progress and post the best cases of both worlds.

In the next few days or weekend I'm going to post lots of different encoding using latest NVEncC in order to find the best - if there is such thing - encoding parameters for Turing.

[poisondeathray]

Come on... I shouldn't have to say this, but you guys should mention if what you did if it's relevant, and if it's not already obviously clear

Filtering is very relevant

Even if you weren't trying to be purposefully misleading, it's still misleading

The point is to measure the encoder quality (and perhaps speed) , not the effect of x,y,z filters on the encode.

[Atak_Snajpera]

Come on... I shouldn't have to say this, but you guys should mention if what you did if it's relevant, and if it's not already obviously clear

Filtering is very relevant

Even if you weren't trying to be purposefully misleading, it's still misleading

The point is to measure the encoder quality (and perhaps speed) , not the effect of x,y,z filters on the encode.

He can use my script and then we can compare how good is turing in encoding those fine details. x264 veryslow at 4Mbps still has no problems with them. I will soon upload that enhanced version...

https://www.mediafire.com/file/zx3u0y5z84oitnd/x264-veryslow-MDegrain2-EnhanceFineDetails-4Mbps.mkv/file

[NikosD]

I confirmed with rigaya that the VPP filters are not part of NVENC but his accomplishment.

I asked him for quality settings for Turing's HEVC encoder and he suggested this:

-u quality -c hevc --output-depth 10 --vbrhq 0 --vbr-quality 25 --qp-init 20:23:25 --lookahead 32 --aq --aq-temporal --bref-mode each

I tried once both --aq with --aq-temporal on Crowd Run but I think they can't be used together.

Also, for specific average bitrate someone should add a max bitrate and not leave it unconstrained.

I always used --vbr-quality 0 and never used --qp-init.

For --bref-mode I used middle.

So, for anyone with a Turing card he could try the above.

I will, but not today.

[NikosD]

Another three encodings of John Carter's movie, this time with no vpp filtering and following some specific quality rules.
(look at the NVEncC switches)


4Mbps - No VPP/ No Enhancements


1) JC_quality_4Mbps

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

https://www.mediafire.com/file/t8mrt3heow4eysc/JC_quality_4Mbps.mkv/file


2) JC_const_quality_4Mbps

NVEncC64.exe --avhw --vbrhq 0 --codec h265 --preset quality --profile main10 --output-depth 10 --vbr-quality 26 --aq --aq-temporal --lookahead 32 --colormatrix bt709 --colorprim bt709 --transfer bt709 --crop 0,140,0,140

https://www.mediafire.com/file/qhumc1hpqpw1qjs/JC_const_quality_4Mbps.mkv/file


3) JC_rigaya_quality_4Mbps

NVEncC64.exe --avhw --vbrhq 0 --codec h265 --preset quality --profile main10 --output-depth 10 --vbr-quality 26 --aq --aq-temporal --bref-mode each --lookahead 32 --colormatrix bt709 --colorprim bt709 --transfer bt709 --qp-init 20:23:25 --crop 0,140,0,140

https://www.mediafire.com/file/8i9got4w8klpbvn/JC_rigaya_4Mbps.mkv/file


The community is waiting for your feedback!

[NikosD]

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.mkvTest:
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"You seem to prefer to alter the default settings of Ref (--ref) and B Frames (-b) from three to seven and five (max) respectfully.

I think for hardware encoding, changing --ref doesn't play a significant role and as for B frames all the tests point that more than three degrade quality.

You could try the same encodings leaving --ref and -b at default values (3)

Also, did you manage to take a look at the new reference settings of SDK v9.1 ?

What is the meaning of L0/L1 parameters and how could someone use them ?

[NikosD]

Using the excellent embedded tool of "Video Comparison" inside StaxRip, I managed to compare frame 2077 of all my 4Mbps encodings (12 in total) posted here.

If we exclude the three encodings using de-noising filters, I think all the others are close.

In order to preserve a little more detail, I would use --vpp-edgelevel and probably I would keep it simple in adding more switches that doesn't seem to change something significantly.

I'll post later my encodings of Park Run 1080p/2160p at 10Mbps.

[Atak_Snajpera]

Last frame...

x264-veryslow-4Mbps.mkv
https://i.imgsafe.org/5c/5c404285ef.png

JC_rigaya_4Mbps.mkv
https://i.imgsafe.org/5c/5c40bb8ff6.png

NVEnc still blurs dark areas like a boss ;)

[NikosD]

Last frame...

x264-veryslow-4Mbps.mkv
https://i.imgsafe.org/5c/5c404285ef.png

JC_rigaya_4Mbps.mkv
https://i.imgsafe.org/5c/5c40bb8ff6.png

NVEnc still blurs dark areas like a boss ;)But you keep comparing NVEnc HEVC with x264 and not x265, while you have said that x264 is the king of "dirtiness" with too much grain.

Maybe it's time to post NVEnc HEVC vs x265 comparison frames, although I kind of disagree comparing still images as we actually watch a video and not still frames, while decoding the file.

Anyway here they are my Park Joy encodings at 1080p and 2160p


Park Joy 10Mbps:


1080p (~160fps, CPU ~20%)
NVEncC64.exe --vbrhq 10000 --codec h265 --preset quality --profile main10 --output-depth 10 --max-bitrate 30000 --aq --aq-temporal --vpp-edgelevel

https://www.mediafire.com/file/1jy7nn8bz3d3d2u/park_joy_10Mbps.mkv/file



2160p (~75fps, CPU ~22%)
NVEncC64.exe --vbrhq 10000 --codec h265 --preset quality --profile main10 --output-depth 10 --max-bitrate 30000 --aq --aq-temporal --vpp-edgelevel

https://www.mediafire.com/file/t5qdzttrfit1tia/park_joy_2160p_10Mbps.mkv/file


Guys, do you have any better x265 encodings of Park Joy at 10Mbps ?

[Atak_Snajpera]

But you keep comparing NVEnc HEVC with x264 and not x265, while you have said that x264 is the king of "dirtiness" with too much grain.

Maybe it's time to post NVEnc HEVC vs x265 comparison frames, although I kind of disagree comparing still images as we actually watch a video and not still frames, while decoding the file.
It is not my fault that older compression technology is better than new one. Besides I do notice that blurriness in dark areas while watching. For my eyes it looks (artificially) too smooth.

[Atak_Snajpera]

Guys, do you have any better x265 encodings of Park Joy at 10Mbps ?
Even x265 medium is better than NVENC (Frame 125)

NVenc
https://i.imgsafe.org/5f/5f7ea6a728.png

x265 medium
https://i.imgsafe.org/5f/5f80fbaaef.png

x265 veryslow
https://i.imgsafe.org/5f/5fe574aa0d.png

x264 veryslow
https://i.imgsafe.org/5f/5f7f098893.png

[NikosD]

Even x265 medium is better than NVENC (Frame 125)

NVenc

x265 medium

x265 veryslow

x264 veryslow Can you post the whole videos of those frames ?

Also, is it 1080p or 2160p ?

And from what video did you take NVEnc frame ?

Thanks.

[Atak_Snajpera]

And from what video did you take NVEnc frame ?
https://www.mediafire.com/file/1jy7nn8bz3d3d2u/park_joy_10Mbps.mkv/file

Can you post the whole videos of those frames ?
Why can't you just do that on your own pc? It is just 500 frames...

[NikosD]

Why can't you just do that on your own pc? It is just 500 frames... No problem, I would like to see my speed on x264/x265, but I have no idea regarding the x264/x265 switches.

Can you post the command line of x264/x265 encodings that produced those frames ?

thanks!

[Atak_Snajpera]

Nothing special, just preset medium/veryslow

[NikosD]

OK, here we are:


Park Joy 10Mbps


Core i3 9100F (4C/4T) - All core turbo 4.0 GHz

x264 v2969 - Preset = very slow
x264.exe --pass 1 --bitrate 10000 --preset veryslow --output-depth 10 --demuxer y4m --frames 500
1st pass ~32 fps
2nd pass ~ 4 fps

Total encoding time = 133,78s
Avg FPS = 3,7 fps

https://www.mediafire.com/file/lr8ht15jvp42a6n/park_joy_1080p_x264_veryslow_10Mbps.mkv/file


x265 3.2+5-gfbe9fef31 - Preset = medium
x265.exe --pass 1 --bitrate 10000 --output-depth 10 --frames 500 --y4mx265.exe --pass 2 --bitrate 10000 --output-depth 10 --frames 500 --y4m
1st pass ~16fps
2nd pass ~19fps

Total encoding time = 58,09s
Avg FPS = 8,6 fps

https://www.mediafire.com/file/ff0bxwoparnhlkk/park_joy_1080p_x265_medium_10Mbps.mkv/file


x265 3.2+5-gfbe9fef31 - Preset = very slow

It started at 0,6 fps, so I left it because I had to go to work...

[NikosD]

Testing frame 125 of Park Joy and looking at x265 Medium, I see no joy.

Please, take a look at the clothes of men and women, it makes me sick, it's disgusting.

x264 Very Slow is better than x265 Medium, but NVEnc is better than both especially x265 medium


Park Joy 10Mbps 1080p
Frame 125 (still image test)


x265 medium:
https://i.postimg.cc/pTLXxZz5/125-park-joy-1080p-x265-medium-10-Mbps.png

x264 very slow:
https://i.postimg.cc/zXsBWTZ4/125-park-joy-1080p-x264-veryslow-10-Mbps.png

NVEnc quality:
https://i.postimg.cc/MT3ZGQmP/125-park-joy-NVEnc-Quality-10-Mbps.png

[Boulder]

To me it looks like x265 has SAO enabled which is a no-no if you don't want it to smooth everything. Also, are they all the same frame type? It's pointless comparing a P-frame to a B-frame when you look at single frames.

[excellentswordfight]

To me it looks like x265 has SAO enabled which is a no-no if you don't want it to smooth everything. Also, are they all the same frame type? It's pointless comparing a P-frame to a B-frame when you look at single frames.
At this bitrate/compression I dont think turning off sao will do much good, and x265 medium has already more detail than nvenc in these samples anyway. I think the reason why NikosD finds nvenc superior is cause it is smoother, not the other way arround (he thinks the the clothes looks better, and they are more smudged together). x265 medium is overall much sharper, this is very clear when jumping between them, but since the bitrate is not sufficiant this also makes the people seem more cluttered.

I also had a look at the new JC samples without any filters, and it looks much better (if it was the old filters that was the issue or the new settings I'm not sure though). JC_const_quality_4Mbps looks absolutely fine now and do not suffer at all as much from inconsistent frame quality.

[Boulder]

At this bitrate/compression I dont think turning off sao will do much good, and x265 medium has already more detail than nvenc in these samples anyway. I think the reason why NikosD finds nvenc superior is cause it is smoother, not the other way arround (he thinks the the clothes looks better, and they are more smudged together). x265 medium is overall much sharper, this is very clear when jumping between them, but since the bitrate is not sufficiant this also makes the people seem more cluttered.

I also had a look at the new JC samples without any filters, and it looks much better (if it was the old filters that was the issue or the new settings I'm not sure though). JC_const_quality_4Mbps looks absolutely fine now and do not suffer at all as much from inconsistent frame quality.
Gah, I had the images in a wrong order in the tabs so I was looking at NVEnc thinking it's x265 and vice versa. That's why I thought x265 looked so smoothed out.

[NikosD]

I think the reason why NikosD finds nvenc superior is cause it is smoother, not the other way arround (he thinks the the clothes looks better, and they are more smudged together)That's why I thought x265 looked so smoothed out. Guys, are you telling me that the clothes of x265 medium are detailed and sharp and not messed up with the background of grass and trees and leafs ?
Because I just see blocks of pixels mixed with the background instead of clothes.

[Boulder]

They are more detailed than in the NVEnc one. I don't care if it's fake detail or real because when you watch the video from the normal viewing distance, you cannot tell which one it is. NVEnc is just oversmoothed to my taste. If you look at the leaves in the trees, they are quite smudged compared to x265. The same goes for the tree bark, it's almost unicoloured in NVEnc so all the detail in the shadows is lost.

[Atak_Snajpera]

x264 Very Slow is better than x265 Medium, but NVEnc is better than both especially x265 medium
I like how you ignored blurry leaves,tress and dark area in center. x264 is still a king. Period.

https://i.imgsafe.org/88/885662d543.png

x264 veryslow
https://i.imgsafe.org/5f/5f7f098893.png

[NikosD]

I like how you ignored blurry leaves,tress and dark area in center. x264 is still a king. Period This is a little embarrassing for x265.
And are you comparing x265 medium with x264 very slow ?
It's not fair.
I didn't have the time and patience to encode x265 very slow at 0,6fps, so I don't have the frame to compare.
Anyway, I prefer NVEnc, you prefer x264 and all the others prefer x265 because obviously they own a Ryzen 3900X and leave their machines encoding for weeks...

@Boulder
While playing video, NVEnc is even better than x264 and x265 compared to still images.

[Atak_Snajpera]

This is a little embarrassing for x265.
And are you comparing x265 medium with x264 very slow ?
It's not fair.
I didn't have the time and patience to encode x265 very slow at 0,6fps, so I don't have the frame to compare.
Anyway, I prefer NVEnc, you prefer x264 and all the others prefer x265 because obviously they own a Ryzen 3900X and leave their machines encoding for weeks...

@Boulder
While playing video, NVEnc is even better than x264 and x265 compared to still images.

I took NVenc frame not x265! Start thinking for god sake!

Furthermore, You are exaggerating like always regarding encoding speed. Anything above x265 medium is basically a placebo.
x265 veryslow
https://i.imgsafe.org/5f/5fe574aa0d.png

x265 medium
https://i.imgsafe.org/5f/5f80fbaaef.png

[NikosD]

I took NVenc frame not x265! Start thinking for god sake! You quoted my phrase comparing all of them, not in couples.
It is you, that you have to start thinking some time because you are still comparing apples with oranges.
You have to decide which is better after all and put them in order.
You jump from NVenc to x264 very slow and NVEnc to x265 medium.
We are talking about Turing's HEVC encoder and you always refer to x264, forgetting about x265.
Your comparisons are a mess!
Furthermore, You are exaggerating like always regarding encoding speed. Anything above x265 medium is basically a placebo. I'm the only one posting encoding speeds, how on earth could I exaggerate regarding speed ?

My Core i3 9100F using 4C/4T at 4.0 GHz achieved 3,7fps using x264 2pass very slow and 8,6fps using 2pass x265 medium.
x265 very slow was 0,6fps for the first pass.

On the other hand Turing's encoder at max quality achieves 160 fps.

So, Turing's HEVC is 43 times faster than x264 very slow, almost 20 times faster than x265 medium and 270 (!) times faster than 1st pass of x265 very slow.
I don't dare to compare it with total time of x265 very slow.

Can you take a calculator in your hands please and stop making wrong assumptions ?

Thanks!

P.S
If everything above x265 medium is placebo, then we shouldn't being talking about x265.
It's a dead project for sure.

[Tadanobu]

I really appreciate you guys giving your opinion and posting test encodes, screenshots and such, but you're kind of going round in circles.

If you want my two cents, x264 is still better than anything else when it comes to transparency and fine details. NVenc has improved a lot and is giving very satisfying results with fast encoding speeds. If you want to best possible quality, use x264. If you're ready to lose a small amount of visual information to save a lot of time and CPU work, use NVenc. If you are most interested in compression, then try x265.

Each and every codec has pros and cons, just use what's better for your specific needs and expectations.

Also, could somebody please include SVT HEVC in these comparisons ? I haven't been able to test it myself and wonder how good it is.

[stax76]

I'm retired form encoding... but still follow some threads like this to be able to maintain staxrip. I didn't even know nvenc or hardware encoders before Nikos suggested integrating it in staxrip and helped me to shape the integration. What people maybe miss is UHD and HD is a complete different story, I would guess that nvenc shines more with UHD content than it does with HD content. About SVT, probably it's not ready because I could not get SVT-AV1 working, piping input is undocumented and does not support y4m.

[Sharc]

FWIW a similar discussion is going on here for AVC
https://forum.videohelp.com/threads/394581-Encoding-test-some-AVC-encoders

[poisondeathray]

Also, could somebody please include SVT HEVC in these comparisons ? I haven't been able to test it myself and wonder how good it is.


SVT-HEVC Encodes for Parkjoy 50p 10Mb/s

Parkjoy is an AQ sensitive clip ; If you enable or tweak AQ it will move bitrate into some of those areas that look bad Atak is referring to, at the expense of edges (or vice versa). You can try it with x264/x264 with varying AQ strengths.

SVT-HEVC has one adjustment, but not for 1080


ImproveSharpness -sharp
This is a visual quality knob that allows the use of adaptive quantization within the picture and enables visual quality algorithms that improve the sharpness of the background. This feature is only available for 4k and 8k resolutions
0 = OFF, 1 = ON


=> Note earlier SVT-HEVC builds had PSNR, VMAF, Visual tuning, but they removed the -tune for builds in the last few months. I suspect they will make a comeback



These were all done at -encMode 2 (quality from 0-11, 0 is best), 1pass VBR (they don't have 2 pass yet).
SvtHevcEncApp.exe from 20191017

1) Default intra period and lookahead (turns out to be gopsize 49, LAD 48)

"SvtHevcEncApp.exe" -i "yuv420p10le.yuv" -w 1920 -h 1080 -n 500 -bit-depth 10 -color-format 1 -intra-period -2 -rc 1 -profile 2 -fps-num 50 -fps-denom 1 -encMode 2 -tbr 10000000 -b SVT-HEVC_20191017_enc2_rc1_10Mbps_intraauto_ladauto.hevc

https://www.mediafire.com/file/isnzxy5idk5h9ba/1_SVT-HEVC_20191017_enc2_rc1_10Mbps_intraauto_ladauto.mkv/file

2) (1) + SAO off

"SvtHevcEncApp.exe" -i "yuv420p10le.yuv" -w 1920 -h 1080 -n 500 -bit-depth 10 -color-format 1 -intra-period -2 -rc 1 -profile 2 -fps-num 50 -fps-denom 1 -encMode 2 -tbr 10000000 -sao 0 -b SVT-HEVC_20191017_enc2_rc1_10Mbps_intraauto_ladauto_sao0.hevc

https://www.mediafire.com/file/qr6ablm8uoyx8ly/2_SVT-HEVC_20191017_enc2_rc1_10Mbps_intraauto_ladauto_sao0.mkv/file

3) intra-period 250, LAD 250

"SvtHevcEncApp.exe" -i "yuv420p10le.yuv" -w 1920 -h 1080 -n 500 -bit-depth 10 -color-format 1 -intra-period 250 -rc 1 -profile 2 -fps-num 50 -fps-denom 1 -encMode 2 -tbr 10000000 -lad 250 -b SVT-HEVC_20191017_enc2_rc1_10Mbps_intra250_lad250.hevc

https://www.mediafire.com/file/wz0xvy259al2x35/3_SVT-HEVC_20191017_enc2_rc1_10Mbps_intra250_lad250.mkv/file

4) (3) + SAO off

"SvtHevcEncApp.exe" -i "yuv420p10le.yuv" -w 1920 -h 1080 -n 500 -bit-depth 10 -color-format 1 -intra-period 250 -rc 1 -profile 2 -fps-num 50 -fps-denom 1 -encMode 2 -tbr 10000000 -lad 250 -sao 0 -b SVT-HEVC_20191017_enc2_rc1_10Mbps_intraauto_ladauto_sao0.hevc

https://www.mediafire.com/file/5h7em575cddsuvp/4_SVT-HEVC_20191017_enc2_rc1_10Mbps_intra250_lad250_sao0.mkv/file

[RanmaCanada]

I would love to use SVT, but AFAIK there is no working GUI. I know it is being considered to be added to staxrip, but until then, I am sick and tired of command lines. It's also no where near as tunable as x265 is, yet.

[poisondeathray]

I would love to use SVT, but AFAIK there is no working GUI. I know it is being considered to be added to staxrip, but until then, I am sick and tired of command lines. It's also no where near as tunable as x265 is, yet.

Push for it ;

The more GUI support, the more users, the more encodes being done, the more feedback for developers and the more improvements.

There were Y4M pipe issues in the last few months for SVT-HEVC - but I think they got those issues fixed. Selur was involved in that on the issue tracker, so I'm guessing he will probably add it to hybrid. Working Y4M pipe is almost mandatory for most GUI's .

[stax76]

y4m helps, what it missed is including the frame count.

[K.i.N.G]

Anything above x265 medium is basically a placebo.
x265 veryslow
https://i.imgsafe.org/5f/5fe574aa0d.png

x265 medium
https://i.imgsafe.org/5f/5f80fbaaef.png

I find myself agreeing with you most of the time when reading posts of you on this forum dude... there are some clear differences between x265's medium and veryslow presets... veryslow retains noticeably more details and overal shapes

[Blue_MiSfit]

Yep, and it lets you push bitrate reasonably lower while keeping same quality.

For most people anywhere from faster to slow is all that's useful. For scaled VOD delivery to keep CDN costs down it's worth it to use slower/veryslow and drop bitrates by a bit.

[ReinerSchweinlin]

I would love to use SVT, but AFAIK there is no working GUI. I know it is being considered to be added to staxrip, but until then, I am sick and tired of command lines. It's also no where near as tunable as x265 is, yet.
I recently started playing around with hybrid - it has SVT included. Didn´t use it so far though, so no experience yet to share with it...