[HELP] 2-Pass /Motion Vector Precision

[karthauzi]

Hi,

I am using the lastest Hybrid Version 2021 04.12.1.

What are the differences in none, 2pass-quarter and 2pass-full and in Motion Vector Precision, quarter pixel, half pixel and full pixel with NVENC? I really dont understand what it does.



I want to get the Best Quality out of NVENC, but i need to know what it exactly does, i already searched for it on google but i havent found any plausible explanation to it.

What can i do else to get better quality out of NVENC?

Im using VBR, main10, auto, high, encoder Preset "quality" and output bit-depth 10 bit

Set Lookahead to 32?
Use Weigthed P-Frames?

Im Using a Turing Card, RTX 2060

a Friend of Mine is using x265 CPU with 16-Bit Calculation Precision (older Version of Hybrid) with the same settings and only use about 500 kbit (Temporal degrained and resized to 960x720) and he have no Artifacts on some fast scenes that is using high bitrate peaks.

My one is not degrained and have some bigger size (resized to 1280x960 from 1440x1080), but i was expecting only to use about 1000kbit with ungrained, im now on 1600 kbit and still spotting some artifacts, its getterig better the higher i get, but its increasing my Filesize.

With the Turing Card i have, i thought i can go near a x265 CPU Bitrate, just testing out.

Greetings
Karthauzi

[Selur]

What are the differences in none, 2pass-quarter and 2pass-full

In 1-pass rate control modes, the encoder will estimate the required QP for the macroblock and immediately encode the macroblock.

In 2-pass rate control modes, NVENC estimates the complexity of the frame to be encoded and determines bit distribution across the frame in the first pass. In the second pass, NVENC encodes macroblocks in the frame using the distribution determined in the first pass. 2-pass rate control modes can distribute the bits more optimally within the frame and can reach closer to the target bitrate, especially for CBR encoding.

• none
      1pass mode. (fast)
  
• 2pass-quarter
      Runs first pass in quater resolution, which results in larger motion vectors being caught and fed as hints to second pass.
  
• 2pass-full
      Runs first pass in full resolution, slower but generating better statistics for the second pass.
  

see: https://github.com/rigaya/NVEnc/blob/mas...ions.en.md

Motion Vector Precision, quarter pixel, half pixel and full pixel with NVENC?

Smaller the precision potentially allows to find more precise motion vectors and thus potentially increases compression, but also require more processing power.

but i need to know what it exactly does

If you want to exactly understand what the settings to up on:
a. how H.265 works (before that you should understand how MPEG compression in general works)
b. what options the NVEnc offers (https://docs.nvidia.com/video-technologi...rog-guide/ + https://github.com/rigaya/NVEnc/blob/mas...ions.en.md)

Set Lookahead to 32?

Look-ahead improves the video encoder’s rate control accuracy by enabling the encoder to buffer the specified number of frames, estimate their complexity and allocate the bits appropriately among these frames proportional to their complexity. This also dynamically allocates B and P frames.

Use Weigthed P-Frames?

yes, it potentially can help a lot. Read up on what weighted prediction means.

With the Turing Card i have, i thought i can go near a x265 CPU Bitrate, just testing out.

You are comparing:
a. noise source to an denoised source
b. a source with 1/4 higher resolution (960x720 vs 1280x960 pixels)
and expect to go near the same bit rate to archive similar quality.
-> You thought wrong.

Cu Selur

[karthauzi]

Thanks for the explanations, I'll take a closer look at the links before I ask relatively stupid questions here the next time, now i know so much more, thanks again!

I think we still need a high bitrate when encoding with nvenc, even if turing has gotten better. But the Quality of very fine Details is still shown like progressed with a hammer in comparison versus a CPU, even if the GPU use a high Bitrate.. but it have clearly gotten a bit better in comparison to non turing.

I need a Scalpel and not a Club! 
https://www.youtube.com/watch?v=E6Mx0JtseV0

I stick with x265. 

With x264 at 2000 kbit, i spotted artifacts. With x265 at 1000kbit, no artifacts and perfect Image Quality.

Can you bring back 16-Bit Calculation Precision if the actual Plugin allow it for x265? I think, thats why x264 at that big Bitrate cant bring the Quality with 10-Bit Calculation Precision.

In the newest Hybrid you or the Plugin dont offer 16-Bit Calculation Precision for x265 anymore   Thats why im Using Hybrid 2015 5.1.1 for x265.

That 16-Bit Calculation Precision in x265 makes your Program superior in every way.

Even with NVENC in the newest Hybrid version, i spotted settings, that other as known "good programs" dont have. So professionals can get the best out of NVENC, i dont call names here because that program is free to use too and he also invest work/ time to get us a good product, even it have still some bugs, i think you know who i mean and im not talking about Handbrake 

EDIT: like i read on Google search, x265 is actually not supported anymore with 16-Bit Calculation Precision yet (gleitz.info)
can you bring the option, that we can use the old plugin from the 2015 Hybrid with your newest hybrid versions that is working with your GUI? I dont think if i import the old Plugin it would work with the new GUI!?

Because your new version is working very well with (AAC FDK High Complexity) where the old version is much slower and buggy sometimes when using it!

Your newest hybrid versions are cool, but i miss the 16-Bit Calculation Precision. That would be awesome if you can manage it, to bring the old plugin somehow in the new versions.

Maybe a Menu where we can switch what plugin version we want to use for it.

[Selur]

I removed 16bit support back in Hybrid version 2015.06.28.1 (5+ years ago) since x265 stopped supporting it and there isn't a way to
Problem is that x265s command line options and presets changed a LOT since then, adding support for such an old version would basically like adding support for a new encoder altogether.
If I remember correctly the developers removed 16bit since it wasn't optimized and added quite a bit off overhead which hindered general development, which is why the removed it. But iirc they also wanted to add it back some time, but that never happened.
I agree it would be nice to have x265 with 16bit support back, but it doesn't look like it's happening.

Cu Selur

[augur89]

It would be wonderful to get 16 bit precision back in their releases. i have to use the 2015er version of hybrid since their removal of this.
main reason for usage of x265 is saving bandwith and by removing the 16 bit calculation precision they drastically reduced the ammount of bandwith, that can be saved by using x265.
→ their whole development since that time doesn't make sense to me since their older version is way more efficient (in my eyes).

it would be nice to have more information about what this setting exactly changes and why they removed it.

do you have contact data of x265 developers, so that we can ask them to reimplement 16 bit calculation precision?
or do they have a forum?

if they would reimplement 16 bit calculation support, then it would make more sense to use x265 in other programs besides hybrid 2015er version again (at least for me)

[Selur]

You can contact the developers through their bitbucket repository: https://bitbucket.org/multicoreware/x265_git/src

Cu Selur

[augur89]

i wrote an E-Mail to x265-devel-owner@videolan.org, but my E-Mail still is awaiting moderator approval.
don't they have a forum or normal E-Mail adresses?

[Selur]

i wrote an E-Mail to x265-devel-owner@videolan.org, but my E-Mail still is awaiting moderator approval.
don't they have a forum or normal E-Mail adresses?

not that I know of + never tried to contact the multicore x265 developers through the x265 dev mailing list,...
you could try reaching them through the doom9 forum, there's a x265 thread where some of the devs appear from time to time,...

[augur89]

ok, i'll try that. thanks