[FFmpeg-trac] #11259(undetermined:new): anull filter consumes an apparently abound quantity of memory

[FFmpeg]

#11259: anull filter consumes an apparently abound quantity of memory
-------------------------------------+-------------------------------------
             Reporter:  Alfredo Di   |                     Type:  defect
  Napoli                             |
               Status:  new          |                 Priority:  normal
            Component:               |                  Version:  7.1
  undetermined                       |
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 At work we recently upgraded from 5.0.1 to 7.1.0, and we couldn't figure
 out why some machines in our cluster were really struggling; these are big
 machines with 16 cores and something like 30GB of RAM. By a quick `htop`
 inspection it seemed like for a single ffmpeg command, all the RAM was
 being eventually consumed and the machines started to swap. Removing the
 `anull` filter to the command made the leak go away. We could still see
 the memory climbing ever so slightly, but not in the same aggressive way.

 To reproduce, consider the following command:

 {{{
 % /usr/local/bin/ffmpeg-7.1.0 -i /foo/left/master -i /foo/right/master -i
 /foo/left/master.muted.mov -i /foo/right/master.muted.mov -aspect 32:9 -y
 -filter_complex [1:1]anull[hms-1-1]  -filter_complex [0:1]anull[hms-0-1]
 -filter_complex '[2:v]setpts=PTS-
 STARTPTS,pad=iw*2:ih:color=white,framerate=30[l];[3:v]setpts=PTS-
 STARTPTS[r];[l][r]overlay=x=W-w:shortest=1[vout]' -map [vout] -map
 [hms-1-1] -map [hms-0-1] -shortest /foo/central/master.mp4
 }}}

 Without getting into too much detail, `anull` here is used just as a way
 to pass the audio stream, unchanged, to the final video. I can't remember
 why I'm using `anull` and not just mapping the relevant audio streams
 directly, but case on point, this command leaks quite severely. If we
 amend the command this way:

 {{{
 % /usr/local/bin/ffmpeg-7.1.0 -i /foo/left/master -i /foo/right/master -i
 /foo/left/master.muted.mov -i /foo/right/master.muted.mov -aspect 32:9 -y
 -filter_complex '[2:v]setpts=PTS-
 STARTPTS,pad=iw*2:ih:color=white,framerate=30[l];[3:v]setpts=PTS-
 STARTPTS[r];[l][r]overlay=x=W-w:shortest=1[vout]' -map [vout] -shortest
 /foo/central/master.mp4
 }}}

 The leak goes away.

 {{{
 ffmpeg version 7.1 Copyright (c) 2000-2024 the FFmpeg developers
 built with gcc 11 (Ubuntu 11.4.0-1ubuntu1~22.04)
 configuration: --prefix=/usr/local/ic-ffmpeg-7.1.0 --extra-
 cflags=-I/usr/local/ic-ffmpeg-7.1.0/include --extra-ldflags=-L/usr/local
 /ic-ffmpeg-7.1.0/lib --bindir=/usr/local/ic-ffmpeg-7.1.0/bin --extra-
 libs=-ldl --ld=g++ --enable-gpl --enable-gnutls --enable-libass --enable-
 libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus
 --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265
 --enable-nonfree --enable-frei0r
 libavutil      59. 39.100 / 59. 39.100
 libavcodec     61. 19.100 / 61. 19.100
 libavformat    61.  7.100 / 61.  7.100
 libavdevice    61.  3.100 / 61.  3.100
 libavfilter    10.  4.100 / 10.  4.100
 libswscale      8.  3.100 /  8.  3.100
 libswresample   5.  3.100 /  5.  3.100
 libpostproc    58.  3.100 / 58.  3.100
 }}}
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/11259>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker