Opened 6 years ago
Closed 6 years ago
#4484 closed defect (invalid)
libavcodec: memory leak at libavcodec/utils.c:unrefcount_frame
Reported by: | faham | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avcodec |
Version: | unspecified | Keywords: | leak |
Cc: | nfxjfg@googlemail.com, michael | Blocked By: | |
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
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.
Attachments (3)
Change History (15)
Changed 6 years ago by faham
comment:1 Changed 6 years ago by cehoyos
- Keywords memory removed
- Priority changed from critical to normal
Please test current FFmpeg git head and provide valgrind output.
comment:2 Changed 6 years ago by gjdfgh
- Cc nfxjfg@googlemail.com added
You're most likely just using the API incorrectly (which is easy).
comment:3 Changed 6 years ago by 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
comment:4 Changed 6 years ago by cehoyos
Please provide valgrind output for memory leaks.
Changed 6 years ago by faham
massif output - memory leak (ffmpeg revision a61c75e9f77a063cdcf2e68ee752c08a3ff8173d)
comment:5 Changed 6 years ago by 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)
comment:6 Changed 6 years ago by 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.
comment:7 Changed 6 years ago by 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
comment:8 Changed 6 years ago by michael
You can probably fix that issue by calling av_frame_unref() on the frame once you are done with using it.
comment:9 Changed 6 years ago by michael
- Cc michael added
comment:10 Changed 6 years ago by gjdfgh
Apparently he isn't use refcounting (or unrefcount_frame wouldn't be called), so that's not going to help?
comment:11 Changed 6 years ago by 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)
comment:12 Changed 6 years ago by richardpl
- Resolution set to invalid
- Status changed from new to closed
massif output showing memory leak at libavcodec