Both the name as well as the options need to be freed.
(Right now there is no option for the AVFilterContext itself that could
leak, but some filters have options (e.g. of type AV_OPT_TYPE_STRING)
that can leak.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@outlook.com>
---
I intend to remove this duplicated freeing code and call avfilter_free()
directly once it is ensured that it is safe to do so; a few checks will
have to be added to it and the filters will have to be checked to be
compatible with it. The only thing I already found out is that libvamf
is buggy (even without calling avfilter_free), because it just presumes
that a mutex and a condition variable have always been properly
initialized.
libavfilter/avfilter.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index 358bf8a853..908e812b5c 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -684,13 +684,19 @@ AVFilterContext *ff_filter_alloc(const AVFilter *filter,
const char *inst_name)
err:
if (preinited)
filter->uninit(ret);
+ av_freep(&ret->name);
av_freep(&ret->inputs);
av_freep(&ret->input_pads);
ret->nb_inputs = 0;
av_freep(&ret->outputs);
av_freep(&ret->output_pads);
ret->nb_outputs = 0;
- av_freep(&ret->priv);
+ if (ret->priv) {
+ if (filter->priv_class)
+ av_opt_free(ret->priv);
+ av_freep(&ret->priv);
+ }
+ av_opt_free(ret);
av_freep(&ret->internal);
av_free(ret);
return NULL;
--
2.30.2
_______________________________________________
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".
