Leak in lavfi movie source

[Alexandre Ferrieux]

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

[Alexandre Ferrieux]

sample annexb input (just in case; don't think it matters)

[Alexandre Ferrieux]

Commit dc8e1b75e721ee10a8ba34311ee622e7a6aa74c6 by Stefano fixes it. Thanks !!!