On Sun, 22 Jan 2017 10:26:58 +0800 "Huang, Zhengxu" <zhengxu.maxw...@gmail.com> wrote:
> 在 2017/1/20 17:56, wm4 写道: > > > On Fri, 20 Jan 2017 17:35:33 +0800 > > Chao Liu <chaox.a....@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel