combining audio and video filters crashes machine

[atlithorn]

Summary of the bug: if you combine overlay and amerge in a filter_complex statement then the machine will start eating memory as soon as the shortest input file is complete and ultimately bring down the machine. Tested on Ubuntu 12.04 and a Debian as well

How to reproduce:

ffmpeg -i test1.flv  -i test2.flv -filter_complex '[0:0]scale=iw/2:ih/2,pad=2*iw:ih[left];[1:0]scale=iw/2:ih/2[right];[left][right]overlay=main_w/2:0;[0:1][1:1] amerge' comb.flv
ffmpeg version N-36926-g02827a3 Copyright (c) 2000-2012 the FFmpeg developers
  built on Jun  5 2012 15:47:40 with gcc 4.6.3
  configuration: --enable-gpl --enable-libfaac --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-nonfree --enable-version3 --enable-x11grab
  libavutil      51. 56.100 / 51. 56.100
  libavcodec     54. 23.100 / 54. 23.100
  libavformat    54.  6.101 / 54.  6.101
  libavdevice    54.  0.100 / 54.  0.100
  libavfilter     2. 78.100 /  2. 78.100
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 15.100 /  0. 15.100
  libpostproc    52.  0.100 / 52.  0.100
Input #0, flv, from 'test1.flv':
  Metadata:
    creationdate    : Thu Apr 26 14:03:11
  Duration: 00:12:07.70, start: 0.000000, bitrate: 341 kb/s
    Stream #0:0: Video: h264 (Baseline), yuv420p, 592x444 [SAR 1:1 DAR 4:3], 10 tbr, 1k tbn, 20 tbc
    Stream #0:1: Audio: nellymoser, 11025 Hz, mono, s16
Input #1, flv, from 'test2.flv':
  Metadata:
    creationdate    : Thu Apr 26 12:42:07
  Duration: 00:23:35.37, start: 0.000000, bitrate: 220 kb/s
    Stream #1:0: Video: h264 (Baseline), yuv420p, 592x444 [SAR 1:1 DAR 4:3], 10 tbr, 1k tbn, 20 tbc
    Stream #1:1: Audio: nellymoser, 11025 Hz, mono, s16
[0:0 @ 0xa627200] w:592 h:444 pixfmt:yuv420p tb:1/1000 sar:1/1 sws_param:flags=2
[1:0 @ 0xa5da160] w:592 h:444 pixfmt:yuv420p tb:1/1000 sar:1/1 sws_param:flags=2
[ffmpeg_buffersink @ 0xa6272a0] No opaque field provided
[Parsed_amerge_4 @ 0xa51d2e0] Inputs overlap: output layout will be meaningless
[Parsed_scale_0 @ 0xa51c260] w:592 h:444 fmt:yuv420p sar:1/1 -> w:296 h:222 fmt:yuv420p sar:1/1 flags:0x2
[Parsed_pad_1 @ 0xa6278c0] w:296 h:222 -> w:592 h:222 x:0 y:0 color:0x000000FF
[Parsed_scale_2 @ 0xa51d8e0] w:592 h:444 fmt:yuv420p sar:1/1 -> w:296 h:222 fmt:yuva420p sar:1/1 flags:0x2
[Parsed_overlay_3 @ 0xa51ce40] main w:592 h:222 fmt:yuv420p overlay x:296 y:0 w:296 h:222 fmt:yuva420p
[Parsed_overlay_3 @ 0xa51ce40] main_tb:1/1000 overlay_tb:1/1000 -> tb:1/1000 exact:1
[Parsed_amerge_4 @ 0xa51d2e0] in1:mono + in2:mono -> out:stereo
[flv @ 0xa512ac0] removing common factors from framerate
Output #0, flv, to 'comb.flv':
  Metadata:
    creationdate    : Thu Apr 26 14:03:11
    encoder         : Lavf54.6.101
    Stream #0:0: Video: flv1 ([2][0][0][0] / 0x0002), yuv420p, 592x222 [SAR 1:1 DAR 8:3], q=2-31, 200 kb/s, 1k tbn, 10 tbc
    Stream #0:1: Audio: mp3 ([2][0][0][0] / 0x0002), 11025 Hz, stereo, s16
Stream mapping:
  Stream #0:0 (h264) -> scale
  Stream #0:1 (nellymoser) -> amerge:in1
  Stream #1:0 (h264) -> scale
  Stream #1:1 (nellymoser) -> amerge:in2
  overlay -> Stream #0:0 (flv)
  amerge -> Stream #0:1 (libmp3lame)

This bug is mentioned in comments to #1400 but I thought it warranted its own ticket.

[Cigaes]

I could not reproduce with current Git head and a pair of files picked at random on my hard drive. I got a segfault I fixed with ​http://ffmpeg.org/pipermail/ffmpeg-devel/2012-June/125541.html, but after that, the command finishes without problem.

Can you point me to the exact samples you used?

[atlithorn]

​http://dl.dropbox.com/u/4714388/test1.flv
​http://dl.dropbox.com/u/4714388/test2.flv

[Cigaes]

Ok, understood. The problem is this: when the first video ends, both overlay and amerge consider it means EOF for them and return EOF. Unfortunately, ffmpeg does not take that EOF return into account. Instead, it continues to decode both files and feed the data to the filters. As no frame is requested for the second file, they accumulate in buffersrc, until they exhaust the memory.

There are several things that are wrong here, some I already knew about and intended to fix, others that I just realized and need to think about.

In the meantime, you can avoid the bug using the -shortest option.

[Carl Eugen Hoyos]

This is supposed to be fixed in current git head (and 1.0), please reopen if you can still reproduce the problem.