>> I've been experimenting with encoding with a cuda card, and I noticed that
>> setting the pict_type member of the AVFrame structure to AV_PICTURE_TYPE_I
>> >does not trigger it to encode the next frame as an IDR frame as libx264
>> does. I looked at the nvidia docs and it appears there is a mechanism for
>> this behavior.
>Is that behaviour documented anywhere?
I found documentation on the nvidia site
(https://developer.nvidia.com/nvencode), here is the section of the document
that I referred to in my previous post...
4.2.3 Forcing current frame to be used as an IDR frame
To force the current frame to be encoded as IDR frame, set
NV_ENC_PIC_PARAMS::encodePicFlags = NV_ENC_PIC_FLAG_FORCEIDR
>There should not be any technical issue with triggering a forced iframe, the
>encoder might just choose to ignore it.
Looking at the latest nvenc.c and the function ff_nvenc_encode_frame, I see
that the encodePicFlags member is just always being set to zero...
pic_params.encodePicFlags = 0;
...before being passed along in this line...
nv_status = p_nvenc->nvEncEncodePicture(ctx->nvencoder, &pic_params);
I have not contributed any patches to ffmpeg before, but this seems like a
simple and small patch to look at the incoming AVFrame's pict_type member and
when it's value is AV_PICTURE_TYPE_I, set the corresponding
NV_ENC_PIC_PARAMS::encodePicFlags member to NV_ENC_PIC_FLAG_FORCEIDR.
Would this be a welcome patch, or would I just be duplicating effort because
there is already someone maintaining this code? It seems to me there is quite a
bit of activity with nvenc.c, it works well and I don't want to interfere.
Also, my situation is somewhat narrow and perhaps a patch should be more
complete than what I describe?
I appreciate the guidance.
ffmpeg-devel mailing list