>> Hello, >> >> 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 ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
