#66: Leak in lavfi movie source ------------------------+---------------------------------------------- Reporter: ferrieux | Owner: michael Type: defect | Status: new Priority: important | Component: avfilter Version: git | Keywords: overlay movie source memory leak Blocked By: | Blocking: Reproduced: 0 | Analyzed: 0 ------------------------+---------------------------------------------- I have discovered that the movie source has a systematic memory leak. Initially it hit me on realtime several-input side-by-side overlays, but I have tracked it down also in a non-realtime case with a single movie source. It is independent on the output codec nor container, and also disappears if one replaces the movie source by the 'color' trivial source. Details below. =========== COMMAND LINE ======================================== # ffmpeg_g.r29131git -flags low_delay -probesize 50000 -threads 3 -i flux.264 -vf ' movie=flux.264,setpts=PTS-STARTPTS [src1]; [in] setpts=PTS-STARTPTS, pad=768:288:0:0:red, [src1]overlay=384:0 ' -vcodec mpeg2video -strict experimental -r 15 -vb 8192k -f mpegts - =========== SYMPTOMS ================================================ The leak is steady, eventually using up all RAM. Here is Valgrind's output after 5, 200, and 500 frames: ==29022== LEAK SUMMARY: ==29022== definitely lost: 832 bytes in 8 blocks ==29022== indirectly lost: 1,217,536 bytes in 24 blocks ==29022== possibly lost: 0 bytes in 0 blocks ==29022== still reachable: 0 bytes in 0 blocks ==29022== suppressed: 0 bytes in 0 blocks ==29058== LEAK SUMMARY: ==29058== definitely lost: 21,320 bytes in 205 blocks ==29058== indirectly lost: 24,051,600 bytes in 568 blocks ==29058== possibly lost: 7,147,760 bytes in 47 blocks ==29058== still reachable: 0 bytes in 0 blocks ==29058== suppressed: 0 bytes in 0 blocks ==29216== LEAK SUMMARY: ==29216== definitely lost: 52,104 bytes in 501 blocks ==29216== indirectly lost: 51,002,888 bytes in 1,336 blocks ==29216== possibly lost: 25,245,304 bytes in 167 blocks ==29216== still reachable: 0 bytes in 0 blocks ==29216== suppressed: 0 bytes in 0 blocks Looking at the big leaks, the callstack seems to indicate something when wrong in the lifecycle of buffers obtained through avfilter_default_get_video_buffer: ==29216== 25,245,280 bytes in 166 blocks are possibly lost in loss record 1,004 of 1,005 ==29216== at 0x4004DEE: memalign (vg_replace_malloc.c:532) ==29216== by 0x4004E4B: posix_memalign (vg_replace_malloc.c:660) ==29216== by 0x8689540: av_malloc (mem.c:83) ==29216== by 0x8686B6B: av_image_alloc (imgutils.c:191) ==29216== by 0x805F2AD: avfilter_default_get_video_buffer (defaults.c:45) ==29216== by 0x805D7CB: avfilter_get_video_buffer (avfilter.c:296) ==29216== by 0x805D749: avfilter_get_video_buffer (avfilter.c:293) ==29216== by 0x806D113: request_frame (vsrc_movie.c:238) ==29216== by 0x440625F: ??? ==29216== ==29216== 50,946,800 bytes in 335 blocks are indirectly lost in loss record 1,005 of 1,005 ==29216== at 0x4004DEE: memalign (vg_replace_malloc.c:532) ==29216== by 0x4004E4B: posix_memalign (vg_replace_malloc.c:660) ==29216== by 0x8689540: av_malloc (mem.c:83) ==29216== by 0x8686B6B: av_image_alloc (imgutils.c:191) ==29216== by 0x805F2AD: avfilter_default_get_video_buffer (defaults.c:45) ==29216== by 0x805D7CB: avfilter_get_video_buffer (avfilter.c:296) ==29216== by 0x805D749: avfilter_get_video_buffer (avfilter.c:293) ==29216== by 0x806D113: request_frame (vsrc_movie.c:238) ==29216== by 0x440625F: ??? =========== FFMPEG OUTPUT FOR REFERENCE ============================= FFmpeg version git-N-29131-gf4bc923, Copyright (c) 2000-2011 the FFmpeg developers built on Apr 15 2011 18:13:18 with gcc 4.4.2 20091027 (Red Hat 4.4.2-7) configuration: --enable-gpl --enable-pthreads --enable-libx264 --disable-demuxer=v4l --disable-demuxer=v4l2 --disable-indev=v4l --disable-indev=v4l2 libavutil 50. 40. 1 / 50. 40. 1 libavcodec 52.119. 1 / 52.119. 1 libavformat 52.108. 0 / 52.108. 0 libavdevice 52. 4. 0 / 52. 4. 0 libavfilter 1. 78. 0 / 1. 78. 0 libswscale 0. 13. 0 / 0. 13. 0 [h264 @ 0x401e9c0] Estimating duration from bitrate, this may be inaccurate Seems stream 0 codec frame rate differs from container frame rate: 30.00 (30/1) -> 15.00 (30/2) Input #0, h264, from 'flux.264': Duration: N/A, bitrate: N/A Stream #0.0: Video: h264 (Main), yuv420p, 352x288 [PAR 1:1 DAR 11:9], 15 fps, 15 tbr, 1200k tbn, 30 tbc [buffer @ 0x41f0aa0] w:352 h:288 pixfmt:yuv420p [h264 @ 0x4202340] max_analyze_duration reached [h264 @ 0x4202340] Estimating duration from bitrate, this may be inaccurate [movie @ 0x41f1540] seek_point:0 format_name:(null) file_name:flux.264 stream_index:0 [overlay @ 0x4406260] auto-inserting filter 'auto-inserted scaler 0' between the filter 'Parsed filter 1 setpts' and the filter 'Parsed filter 4 overlay' [buffer @ 0x41f0aa0] TB:0.000001 [pad @ 0x4405b40] w:352 h:288 -> w:768 h:288 x:0 y:0 color:0x515AF0FF[yuva] [movie @ 0x41f1540] TB:0.000001 [scale @ 0x440cdb0] w:352 h:288 fmt:yuv420p -> w:352 h:288 fmt:yuva420p flags:0xa0000004 [overlay @ 0x4406260] main w:768 h:288 fmt:yuv420p overlay x:384 y:0 w:352 h:288 fmt:yuva420p [overlay @ 0x4406260] main_tb:1/1000000 overlay_tb:1/1200000 -> tb:1/6000000 exact:1 [mpegts @ 0x41e29c0] muxrate VBR, [mpegts @ 0x41e29c0] pcr every 1 pkts, sdt every 200, pat/pmt every 40 pkts Output #0, mpegts, to 'pipe:': Metadata: encoder : Lavf52.108.0 Stream #0.0: Video: mpeg2video, yuv420p, 768x288 [PAR 1:1 DAR 8:3], q=2-31, 8192 kb/s, 90k tbn, 15 tbc Stream mapping: Stream #0.0 -> #0.0 Press [q] to stop encoding -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/66> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker