[FFmpeg-trac] #66(avfilter:new): Leak in lavfi movie source
FFmpeg
trac at avcodec.org
Mon Apr 18 13:16:23 CEST 2011
#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
More information about the FFmpeg-trac
mailing list