[FFmpeg-devel] [PATCH] lavformat/utils: Fix a memleak that st->codec->hw_frames_ctx
wm4
nfxjfg at googlemail.com
Sun Jan 22 13:15:59 EET 2017
On Sun, 22 Jan 2017 10:26:58 +0800
"Huang, Zhengxu" <zhengxu.maxwell at gmail.com> wrote:
> 在 2017/1/20 17:56, wm4 写道:
>
> > On Fri, 20 Jan 2017 17:35:33 +0800
> > Chao Liu <chaox.a.liu at gmail.com> wrote:
> >
> >> Have you ever used valgrind? Please just run the command below:
> >> valgrind --leak-check=full --log-file=out.log ffmpeg -hwaccel qsv
> >> -qsv_device /dev/dri/renderD128 -c:v h264_qsv -i a.h264 -c:v h264_qsv -b:v
> >> 2M -y out.h264
> >>
> >> See line 3323 of ffmpeg.c,
> >> ret = avcodec_copy_context(ost->st->codec, ost->enc_ctx);
> >> and see what have been done in avcodec_copy_context:
> >> if (src->hw_frames_ctx) {
> >> dest->hw_frames_ctx = av_buffer_ref(src->hw_frames_ctx);
> >> if (!dest->hw_frames_ctx)
> >> goto fail;
> >> }
> >> However, that is not freed when calling avformat_free_context.
> >>
> > The hardware decoder should never be created in the demuxer.
> I quite can't understand why this related to the "demuxer". Firstly we
> should admint that if
> there is a memleak issue. Secondly, how or where to free the hw_frames_ctx.
demuxer = libavformat. libavformat sometimes/often opens a decoder to
probe codec parameters. (Which I think is madness, but that's another
issue.)
What absolutely shouldn't happen is that libavformat opens a
hardware-based decoder. What should happen even _less_ is that closing
the decoder somehow leaves hw_frames_ctx set.
I'm against painting bugs just over without knowing the real underlying
issue.
More information about the ffmpeg-devel
mailing list