libavcodec: memory leak at libavcodec/utils.c:unrefcount_frame

[faham]

I'm using ffmpeg (revision: ecafde6606a51c285ed7ca4d27697392b493919e) to playback HD audio (ac3) contents for more than a few hours (long-term runs) and observe a mem leak in ffmpeg/libavcodec/utils.c:2287 inside unrefcount_frame.

It looks like the call to av_frame_copy_props() is leading to the leak, I'm not sure if it is necessary to do this operation or not but by removing that line the mem leak goes away. Can find further info in the attached valgrind-massif output.

[faham]

massif output showing memory leak at libavcodec

[cehoyos]

Please test current FFmpeg git head and provide valgrind output.

[gjdfgh]

You're most likely just using the API incorrectly (which is easy).

[faham]

Just switched to tip of the master (a61c75e9f77a063cdcf2e68ee752c08a3ff8173d) and the leak is still happening, I'm actually using ffmpeg through gstreamer, gst-libav used libav as a submodule, I've replaced that submodule with ffmpeg (as far as both provide same interfacing functions) and am using the following gstreamer pipeline to playback:

gst-launch-1.0 \
    udpsrc address=239.6.60.1 port=6100 name=udpsrc1 ! \
    queue max-size-bytes=0 max-size-buffers=0 max-size-time=10000000000 name=q_tsdemux_1 ! \
    tsdemux name=dmx \
    dmx. ! mpegvideoparse ! \
        queue max-size-bytes=0 max-size-buffers=0 max-size-time=10000000000 name=q_videoparse_1 ! \
        vaapidecode name=vaapidecode_1 !  \
        queue max-size-bytes=0 max-size-buffers=0 max-size-time=10000000000 name=q_videosink_1 ! \
        vaapisink display=x11 \
    dmx. ! identity ! ac3parse ! avdec_ac3 ! audioconvert ! \
        audioresample sinc-filter-mode=full quality=3 ! \
        audio/x-raw, format=S16LE, rate=44000 ! \
        queue max-size-bytes=0 max-size-buffers=0 max-size-time=10000000000 name=q_audiosink ! \
        autoaudiosink

in this pipeline the avdec_ac3 element utilizes libavcodec of ffmpeg which leads to the memory leak

[cehoyos]

Please provide valgrind output for memory leaks.

[faham]

massif output - memory leak (ffmpeg revision a61c75e9f77a063cdcf2e68ee752c08a3ff8173d)

[faham]

​https://trac.ffmpeg.org/attachment/ticket/4484/massif.out.32533

The updated valgrind massif output is attached. av_malloc is constantly increasing over time at the same spot in libavcodec (can see it with massif-visualizer)

[cehoyos]

If you want to report a memory leak, valgrind output (and only valgrind output) is needed.
If you don't want to report a memory leak, please explain clearly that you don't want to report a memory leak.
Please understand that "memory leak" is a well defined term and massif (which is a useful tool) is not able to detect memory leaks.

[faham]

valgrind memcheck output

[faham]

​https://trac.ffmpeg.org/attachment/ticket/4484/memcheck.txt

valgrind memcheck output is attached to the bug, I generated that with the following command, also stripped out rest of my gstreamer pipeline to make it more easily observable.

valgrind --tool=memcheck --leak-check=full --log-file=memcheck.txt \ 
  ~/gst/master/gstreamer/tools/.libs/gst-launch-1.0 \
  udpsrc address=224.1.1.1 port=5000 ! queue ! \
  tsdemux name=dmx1 \
  dmx1. ! identity ! ac3parse ! avdec_ac3 mode=stereo ! audioconvert ! \
  audioresample sinc-filter-mode=full quality=3 ! \
  audio/x-raw, format=S16LE, rate=44000 ! autoaudiosink

[michael]

You can probably fix that issue by calling av_frame_unref() on the frame once you are done with using it.

[gjdfgh]

Apparently he isn't use refcounting (or unrefcount_frame wouldn't be called), so that's not going to help?

[heleppkes]

gst-ffmpeg did use the API wrong, they used a AVFrame on the stack and never called a free function on it. They changed it end of last month, though, so this can be considered resolved (or invalid, if you want)