Errors in the "NVEncC option list"

[warrex1979]

1. The English and Chinese version of the "NVEncC option list" state that VC-1 decoding via "--avhw" is not supported. This is wrong. The Japanese version of that document is not affected.

2. Every version of the "NVEncC option list" states that --weightp is an H264 only feature. This not true for Pascal and Turing based GPUs and NVEnc allows using this option but warns that: "HEVC encode with weightp is known to be unstable on some environments. Consider not using weightp with HEVC encode if unstable." If this is still true this should be added to the documentation instead along with a note that using --weightp will be ignored when the usage of b-frames is set by the driver or the user.

[Starkler]

HI!
Weightp is not unstable anymore, at least on Turing cards.

[Starkler]

Most VC-1 films works with NVENCC's HW decoder, but some of them doesn't work.

[warrex1979]

Nvidia states that every GPU since Kepler that has a NVDEC chip supports VC-1 (https://developer.nvidia.com/video-encode-decode-gpu-support-matrix).

If there is spec compliant VC-1 content that cannot be decoded please inform Nvidia.

In any case the option list should be corrected.

[rigaya]

HEVC encode with weightp is known to be unstable on some environments. Consider not using weightp with HEVC encode if unstable."
Weightp is not unstable anymore, at least on Turing cards.

There was some report in Pascal that weightp with HEVC encoding was unstable, but I haven't had problem myself. I cannot say if it is fixed in Turing, so I'm keeping that message in case it is unstable.

Most VC-1 films works with NVENCC's HW decoder, but some of them doesn't work.

Unstable VC-1 hw decode might be caused by the implementation of NVEncC. I've also struggled about VC-1 decode in QSVEncC, but I'm feeling that I have too little knowledge about VC-1, so I might remove VC-1 hw decode from NVEncC (as same as in QSVEncC).

[warrex1979]

Unstable VC-1 hw decode might be caused by the implementation of NVEncC. I've also struggled about VC-1 decode in QSVEncC, but I'm feeling that I have too little knowledge about VC-1, so I might remove VC-1 hw decode from NVEncC (as same as in QSVEncC).

If you ARE seeing issues you might want to contact Nvidia first. Would be really sad to see an officially supported codec being droped from HW decoding. A lot of content uses VC-1.

If you still do it it would be nice if NVEncC could fall back to SW decoding with a warning even if --avhw was specified.

[warrex1979]

rigaya, can you please elaborate under which circumstances you experienced unstable decoding and how decoding is implemented in NVEncC?

I am asking this as I have come across serveral bug reports / forum posts (e.g. https://trac.ffmpeg.org/ticket/7778) concerning the different ways how to intialize HW decoding on Nvidia hardware in ffmpeg.

Prior to version 4.0 "-hwaccel cuvid -c:v h264_cuvid" had to be used. Since version 4.0 NVDEC is supported which can alternatively be used this way: "ffmpeg -hwaccel nvdec -hwaccel_output_format cuda". The latter is supposed to use the more robust ffmpeg parser instead of cuvid.

Might this information also be helpful for NVEncC?

[rigaya]

rigaya, can you please elaborate under which circumstances you experienced unstable decoding and how decoding is implemented in NVEncC?

I don't have issues with the very few VC-1 samples I have myself. I just thought NVEncC might have some issues as reported in this issue, as I had hw decode errors in QSVEncC which has similar code to NVEncC.

The latter is supposed to use the more robust ffmpeg parser instead of cuvid.

NVEncC uses cuvid parser. As you have mentioned, the ffmpeg nvdec uses ffmpeg parsers, however they are ffmpeg internal parsers not exposed in the libavcodec API, and seems to require codec specific knowledge.

I'm interested in whether the VC-1 files with errors in NVEncC are able to be decoded in ffmpeg nvdec or ffmpeg cuvid, might be a hint of where the problem is.

[warrex1979]

I don't have issues with the very few VC-1 samples I have myself. I just thought NVEncC might have some issues as reported in this issue, as I had hw decode errors in QSVEncC which has similar code to NVEncC.

If so please just leave the VC-1 support in there and warn about it in the "options list" if you have to. From what I have read this warning should then apply to all cuvid HW decoders.

Personally I would only issue warnings for problems I can reproduce and where I can therefore also verify that the problem has been solved with a later driver release or a newer version of NVEncC (also see your comment about YOU not having issues with weightp).

Otherwise you might make your decisions depended on people who try to encode broken streams, have faulty hardware, etc.

I'm interested in whether the VC-1 files with errors in NVEncC are able to be decoded in ffmpeg nvdec or ffmpeg cuvid, might be a hint of where the problem is.

Exactly. Maybe Starkler can provide a sample to you.

[rigaya]

NVEnc 4.56 focuses on the topics discussed here.

weightp option

• I have removed "H.264 only" from readme.
• Now the "unstable warning" will only be shown on Pascal/Volta, and not on Turing.

VC-1 hw decode

• Thanks to the samples provided by Starkler, I was able to resolve the issue. Please refer Error message for the cutted video files with NVENCC HW decoding #174.

[warrex1979]

Great. I assume this can be closed if you correct this:

The English and Chinese version of the "NVEncC option list" state that VC-1 decoding via "--avhw" is not supported. This is wrong. The Japanese version of that document is not affected.

[rigaya]

Now the documents are also corrected.