[FFmpeg-devel] [PATCH] avcodec/nvenc: Video Codec SDK 10 features support

[hydra3333 at gmail.com]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Soft Works
> Sent: Wednesday, July 1, 2020 1:34 PM
> To: Roman Arzumanyan <rarzumanyan at nvidia.com>; FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> Cc: Yogender Gupta <ygupta at nvidia.com>
> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Video Codec SDK 10 features support
>
> > From: Roman Arzumanyan <rarzumanyan at nvidia.com>
> > Sent: Tuesday, June 30, 2020 10:23 PM
> > To: Soft Works <softworkz at hotmail.com>; FFmpeg development discussions 
> > and patches <ffmpeg-devel at ffmpeg.org>
> > Cc: Yogender Gupta <ygupta at nvidia.com>
> > Subject: RE: [FFmpeg-devel] [PATCH] avcodec/nvenc: Video Codec SDK 10 
> > features support
> > 
> > Hello, nice to meet you.
> > 
> > >Wouldn't it make sense to transition from compile time version checks to runtime checking?
> > 
> > Video Codec SDK headers are not included into ffmpeg 'as is' but using the nvcodec-headers project instead.
>
> I know (https://github.com/FFmpeg/nv-codec-headers/commit/72f8b4bc6a2225c6fec6c046bb45c4a6be391f9f)
>
> > This is community-driven project which aims to work around the licensing policies.
>
> Talking about this rarely ends well, 
> > So we can't influence ffmpeg development too much and only supports it's development with patches.
>
> I'm sure, all contributions are welcome, small and big ones ;-)
>
> > Changing compile-time checks with runtime checks is a big thing to do and in order to convince community to accept such changes we need to have very solid background.
>
> I know that it's not a small thing and it will surely be better to discuss this first (not with me...).
>
> Anyway, great to see Nvidia participating again!
>
> softworkz
>

Oh. Thank you again.

In here https://github.com/FFmpeg/nv-codec-headers/commit/5ee2ae591f74f53bd6028344f8690f1558a1f17a
it says this
NV_ENC_MULTI_PASS               multiPass;                                    /**< [in]: This flag is used to enable multi-pass encoding for a given ::NV_ENC_PARAMS_RC_MODE. This flag is not valid for H264 and HEVC MEOnly mode */

So, just confirming, the new multi-pass is valid only for h265/hevc ?

And I see this:
    NV_ENC_LEVEL_H264_5             = 50,
    NV_ENC_LEVEL_H264_51            = 51,
    NV_ENC_LEVEL_H264_52            = 52,

    NV_ENC_LEVEL_H264_60            = 60,
    NV_ENC_LEVEL_H264_61            = 61,
    NV_ENC_LEVEL_H264_62            = 62,

    NV_ENC_LEVEL_HEVC_1             = 30,
    NV_ENC_LEVEL_HEVC_2             = 60,
which seems to indicate h.264 levels up to 6.2 are possible - however the ffmpeg nvenc code somehow has a hard limit of 5.1 (even though 5.2 is already in the header).
I am not sure what other hard limits or exclusions may apply (eg cq?) ?