H264 and --gop-len(?)

[VD-NVencC]

using --codec h264 I'm having concerns about --gop-len , 1) create test video.. RGB Color Cube (virtualdub2) and now 2) looping frames using avisynth+, they'll sometimes leave behind remnants of previous frames.

I've provided a zip with the test pngs you made months ago and an avisynth+ file that includes nvencc64 commands sent commented out.
test.zip

if I use --preset p1 the higher --gop-len numbers don't appear to be affected if that narrows the list of possible issues.

I saw this show up on W7 AMD FX6300&GTX960, and now W10 INTEL 12400&RTX3070 platforms

[rigaya]

I think there is no problem with the input, but something related to the encoder.

Although, it is difficult to find out the cause, I recommend not using "--preset p7" and instead use at least default preset (or higher), there seem to be no problem with that.

[VD-NVencC]

I was aware of your concerns about P7, I saw your nice /vq_results article on your blog too, but I was aware of this for a few years and it didn't show itself in OBS recordings and no one else talked about it so I assumed edge case with high contrasts?

v5.15 did the same thing
nvencc64 --codec h264 --lossless --preset quality --profile high444 --colormatrix bt709 --colorrange limited --gop-len 30 -i imagesource.avs -o sample.mp4

v4.29 didn't know what --colorrange limited was and complained about an error in regards to nvEncGetEncodePresetConfig: 4 but still output a file that looks correct but I cannot trust it handles --preset correct on my driver?

edit upto P4 on 6.12 is artifact free, P5 and up has them in different places. 7.08 & P5 also.

[rigaya]

It is not surprising that v4.29 behaves different. Preset configs has been changed from v5.10 (as it introduced NVENC API v10.0 which changes preset configs and adds P1-P7).

I think using P4(default) preset is the solution, or if you can go with HEVC if possible, it seems to have no problem here.

x64\NVEncC64.exe -i imagesource.avs -o F:\temp\test.mp4 -c hevc --lossless --profile main444 --preset P7 --gop-len 30

[VD-NVencC]

I want to publish my own VQ results, but you can imagine why I would be hesitant to do so if a "Quality" preset was doing that.

What I used on the RGB color cube, change frame rate to fps: 60 & Convert to fps: 60 .. and you can get

back to back frame artifacts with the 1280 size, and they're not all focused on the outside of the cube rotating but also within it.

edit with external encoder & VD2, filters 1) convert format (no change x3), 2) alias format (rec. 601, no change x2), then the colors won't shift if you're concerned with that sort of thing. Can't have colors shifting in a VQ report ha ha.

[rigaya]

I see. If you want to go with P1, then adding --bref-mode each can solve the problem (as same as my test).

[VD-NVencC]

Not asking for immediate attention, just wondering if its able to be fixed by you, and if possible would you?
unsure if its an nvidia issue or your encoder atm, learning different encoder (ffmpeg) switches is a pain

I know h264 is on its way out, so it might get low or no priority.

[rigaya]

As there is a case with no problem depending on the parameter, it can be said that there is no problem with the app sending frames to the encoder.

As we won’t be able to go into the internal of the driver,( and I don’t want to do that), the way to solve this will be to change the parameters, which we have been discussing previously.

I think adding --bref-mode each can easily solve the problem which I think is a good way to solve. I’ll think of making --bref-mode each as default when it is supported by the GPU and B frame is enabled.

[rigaya]

Thank you for reporting this issue. NVEnc 7.14 enables --bref-mode by default when preset slower than default is selected.

I'll close this issue, as now we will be able to avoid this issue by default.

[VD-NVencC]

--bref-mode each appears to clear up the issue with P7 & colorcube, I'd like its section in https://github.com/rigaya/NVEnc/blob/master/NVEncC_Options.en.md to be slightly more clear what it wants thanks!

boy does --bref-mode each have a performance cost, but it saves space vs --bframes 0