Hi Chen,
> On Nov 12, 2024, at 01:09, chen <chenm...@163.com> wrote:
>
> From 4067c58be8e719a55d89e68aaa9d3db19b88b32f Mon Sep 17 00:00:00 2001
>
> From: Chen <chenm...@163.com>
>
> Date: Fri, 8 Nov 2024 22:21:19 -0800
>
> Subject: [PATCH] Fix memory leak in the libx265
>
>
>
>
> ---
>
> libavcodec/libx265.c | 4 +++-
>
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>
>
>
> diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
>
> index 63cc497..60e84d1 100644
>
> --- a/libavcodec/libx265.c
>
> +++ b/libavcodec/libx265.c
>
> @@ -143,8 +143,10 @@ static av_cold int libx265_encode_close(AVCodecContext
> *avctx)
>
> rd_release(ctx, i);
>
> av_freep(&ctx->rd);
>
>
>
> - if (ctx->encoder)
>
> + if (ctx->encoder) {
>
> + ctx->api->cleanup();
>
> ctx->api->encoder_close(ctx->encoder);
>
> + }
cleanup() release library static allocations, and I don’t see lock or reference
count
within x265_cleanup(). So call cleanup() will break other x265 encoder instance,
right?
>
>
>
> ff_dovi_ctx_unref(&ctx->dovi);
>
>
>
> --
>
> 2.35.1.windows.2
>
>
> <0001-Fix-memory-leak-in-the-libx265.patch>_______________________________________________
> 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".
_______________________________________________
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".
