[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