From: Niklas Haas <g...@haasn.dev> Uploads can be asynchronous, so we need to wait for them on unit to prevent a cyclic reference from keeping the hwfc alive indefinitely, since there is no other way for the hwfc to know when prior commands should be cleaned up.
In theory, it might be possible for this to be signalled backwards by downstream consumers of the corresponding AVFrames, but this is very nontrivial as there may be multiple, or even no downstream consumers, such as in the degenerate case of: ffmpeg ... -vf hwupload -f null - Waiting for outstanding transfers to have completed explicitly in uninit is the only solution that is both robust, simple, and comes without a performance penalty. --- libavfilter/vf_hwupload.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/libavfilter/vf_hwupload.c b/libavfilter/vf_hwupload.c index 6aafac4d4d..3142aabb17 100644 --- a/libavfilter/vf_hwupload.c +++ b/libavfilter/vf_hwupload.c @@ -222,6 +222,15 @@ static av_cold void hwupload_uninit(AVFilterContext *avctx) { HWUploadContext *ctx = avctx->priv; + /** + * Ensure that all outstanding asynchronous uploads are properly completed. + * This is to avoid leaking the context, because nobody else will clean up + * after the hwfc while there are still pending asynchronous transfers + * referencing it. + */ + if (ctx->hwframes_ref) + av_hwframe_transfer_wait_all(ctx->hwframes_ref, 0); + av_buffer_unref(&ctx->hwframes_ref); av_buffer_unref(&ctx->hwdevice_ref); } -- 2.47.0 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".