[FFmpeg-devel] Leak in lavfi movie source

[Alexandre Ferrieux]

Hi,

(I'm just about to submit a trac entry, but writing this message because I know the movie source was only recently 
integrated into the trunk, so perhaps people are busily improving it... please tell me)

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.

Is anybody aware of / working on something similar ?

-Alex


=========== 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