Nvenc 4:2:2

[excellentswordfight]

Originally Posted by FranceBB

That's very good to know. The last two things we need to address are:

1) why -refs 1 is being ignored when I pass it in FFMpeg
2) someone to implement enableFillerDataInsertion in FFMpeg as it's already supported by the NVIDIA SDK

I also noticed in your post that High 4:2:2 Intra Profile is not flagged, looking at the sdk documentation (I did not look at the source code), I cannot find the intra profiles either. It is ofc possible to do intra-only encoding, but the profile flag should be correct as well.

[Z2697]

There're spikes in nvenc encoded streams still, the filler will not eliminate those?

[excellentswordfight]

Originally Posted by Z2697

There're spikes in nvenc encoded streams still, the filler will not eliminate those?

According to the nvenc documentation maxrate should eliminate those, but maybe thats only in effect in vbr mode, but maybe vbr+maxrate creates more of a "true" cbr bitrate distrubution?

[FranceBB]

Originally Posted by excellentswordfight

I also noticed in your post that High 4:2:2 Intra Profile is not flagged, looking at the sdk documentation (I did not look at the source code), I cannot find the intra profiles either. It is ofc possible to do intra-only encoding, but the profile flag should be correct as well.

Correct.
In x264 this is changed automatically, in fact even when you specify --profile high422 in combination with --keyint 1 then the actual profile gets set to High 4:2:2 Intra instead of High 4:2:2.

In particular, taking a peek at the x264 source code in set.c (line 143) we have

if( param->i_keyint_max == 1 && sps->i_profile_idc >= PROFILE_HIGH )
sps->b_constraint_set3 = 1;

which sets b_constraint_set3 to true when the keyint is set to 1 and therefore in encoder.c (line 1841)

h->sps->i_profile_idc == PROFILE_HIGH422 ?
(h->sps->b_constraint_set3 ? "High 4:2:2 Intra" : "High 4:2:2")

instead of using the normal High 4:2:2 profile we automatically switch to the High 4:2:2 Intra profile, which is the right thing to do.

Ideally, NVEnc should be doing the same and implement the same logic, but currently they're not doing it, which is why the High 4:2:2 profile is used instead.

Originally Posted by Z2697

There're spikes in nvenc encoded streams still, the filler will not eliminate those?

There are, but that's only because we're encoding a not-so-complex content and in some scenes it doesn't really need that much bitrate. The spikes are there but don't seem to be overshooting, in other words, they don't seem to be going above the specified maximum. This means that, once the rest of the frames with undershooting are gonna be zero-filled / padded, they will also be at the same size and therefore we're gonna get a true 113664 kbit/s constant bitrate.

Anyway, the enableFillerDataInsertion is supported by the NVIDIA SDK which means that someone needs to implement it in FFMpeg. One of my colleagues had a chat with Timo Rothenpieler which is one of the FFMpeg maintainers and he seems to be onboard with it, in the sense that if someone is gonna send a patch to enable it by default when we're using CBR, then he will merge it, but someone has to submit a patch nonetheless.


There's still the problem with -refs 1 being ignored and having the reference frames reported as 2 instead anyway. So, the reframe and the wrong profile are two blockers and my colleagues just bumped into the NVIDIA guys at NAB and reached out to them about those very specific issues. We'll see where we go from here, but they're now definitely aware of this.

[Z2697]

"-rc cbr" seems to enable the filler.
But I only tested on RTX 40.
I guess there's something missing in the "new" format settings.
Maybe you can try test the "old" yuv420p and see if the filler works.

update: Just checked FFmpeg's nvenc settings and I found a option named "cbr_padding".
commited this month
https://github.com/FFmpeg/FFmpeg/com...02f7e15f859f0a