Very long CPU-bound loop with -fflags +genpts and -vsync cfr

[Thierry Lelegard]

This report describes a problem with memory usage and processing time of ffmpeg 2.1.1 on Windows 7 using the "volumedetect" audio filter in combination with the "-fflags +genpts" option.

I know that this combination is probably useless. But the ffmpeg commands was automatically generated by a tool which added "-fflags +genpts" on all ffmpeg commands.

$ ffmpeg -fflags +genpts -i input.avi -af volumedetect -vn -f null -y NUL
ffmpeg version 2.1.1 Copyright (c) 2000-2013 the FFmpeg developers
  built on Nov 20 2013 21:13:48 with gcc 4.8.2 (GCC)
  configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetype --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
  libavutil      52. 48.101 / 52. 48.101
  libavcodec     55. 39.101 / 55. 39.101
  libavformat    55. 19.104 / 55. 19.104
  libavdevice    55.  5.100 / 55.  5.100
  libavfilter     3. 90.100 /  3. 90.100
  libswscale      2.  5.101 /  2.  5.101
  libswresample   0. 17.104 /  0. 17.104
  libpostproc    52.  3.100 / 52.  3.100
Input #0, avi, from 'input.avi':
  Duration: 01:26:59.64, start: 0.000000, bitrate: 1469 kb/s
    Stream #0:0: Video: mpeg4 (Advanced Simple Profile) (XVID / 0x44495658), yuv420p, 696x452 [SAR 1:1 DAR 174:113], 25 tbr, 25 tbn, 25 tbc
    Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 48000 Hz, stereo, s16p, 128 kb/s
Output #0, null, to 'NUL':
  Metadata:
    encoder         : Lavf55.19.104
    Stream #0:0: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
Stream mapping:
  Stream #0:1 -> #0:0 (mp3 -> pcm_s16le)
Press [q] to stop, [?] for help

All the above is quickly displayed. Then, there is no more display for several minutes. During this period, ffmpeg uses 100% CPU and the virtual memory of the process slowly increases up to approximately 180 MB.

After several minutes, the following display restarts. The "time" value increases at the usual speed. And the virtual memory decreases quite quickly.

size=N/A time=01:26:59.11 bitrate=N/A    
video:0kB audio:978584kB subtitle:0 global headers:0kB muxing overhead -100.000002%
[Parsed_volumedetect_0 @ 000000000282f4a0] n_samples: 501034752
[Parsed_volumedetect_0 @ 000000000282f4a0] mean_volume: -20.7 dB
[Parsed_volumedetect_0 @ 000000000282f4a0] max_volume: 0.0 dB
[Parsed_volumedetect_0 @ 000000000282f4a0] histogram_0db: 462
[Parsed_volumedetect_0 @ 000000000282f4a0] histogram_1db: 3951
[Parsed_volumedetect_0 @ 000000000282f4a0] histogram_2db: 19706
[Parsed_volumedetect_0 @ 000000000282f4a0] histogram_3db: 71897
[Parsed_volumedetect_0 @ 000000000282f4a0] histogram_4db: 209764
[Parsed_volumedetect_0 @ 000000000282f4a0] histogram_5db: 496839

Using the same command without the "-fflags +genpts" option, there is no CPU-bound loop in the middle. The "time" line starts to be updated immediately. The virtual memory of the process is stable at 11 MB.

But the "-fflags +genpts" option is not responsible alone for this problem. When this option is used in a conversion command, there is no such very long CPU-bound loop. The "time" line starts to be updated immediately. The virtual memory keeps increasing during the execution up to more than 220 MB but this is probably the required memory for the conversion process.

Conclusion:

The "-fflags +genpts" option, when used in combination with the audio filter "volumedetect" only, creates a several minutes long CPU-bound loop with an increasing virtual memory.

The "-fflags +genpts" option, when used in another context such as an audio/video conversion, does not create this artefact.

Workaround:

Obvious. The "-fflags +genpts" option is useless with the audio filter "volumedetect", so do not use it.

[Carl Eugen Hoyos]

Is this reproducible with current FFmpeg git head?

Please provide the input sample.

[Thierry Lelegard]

Reproduceable with the following version:

ffmpeg version N-58882-ga12f679
built on Dec  8 2013 22:07:18 with gcc 4.8.2 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetype --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
libavutil      52. 56.100 / 52. 56.100
libavcodec     55. 45.100 / 55. 45.100
libavformat    55. 22.100 / 55. 22.100
libavdevice    55.  5.102 / 55.  5.102
libavfilter     3. 92.100 /  3. 92.100
libswscale      2.  5.101 /  2.  5.101
libswresample   0. 17.104 /  0. 17.104
libpostproc    52.  3.100 / 52.  3.100

The input file can be downloaded at ​http://dl.free.fr/rgPwN22MA

[Carl Eugen Hoyos]

Reproducible with the following command:

$ ffmpeg -vsync cfr -fflags +genpts -i input.avi -vn -f null -

Regression since 8c5ee45d / 574dcb5b

[Carl Eugen Hoyos]

Reproducible with the following commands:

$ ffmpeg -f lavfi -i testsrc -f s16le -i /dev/zero -t 3600 -bf 2 -acodec ac3 out.avi
$ ffmpeg -vsync cfr -fflags +genpts -i out.avi -vn -f null -

[Michael Niedermayer]

the link to the input file seems not to work anymore

[Carl Eugen Hoyos]

What's wrong with the commands from comment:4?

[Thierry Lelegard]

@michael (comment 5)

The site dl.free.fr is a big file transfer utility. The files don't stay there forever. If nobody downloads them during something like 1 or 3 months, they are automatically deleted. You cannot expect huge test video files to stay online forever.

The input file was requested by cehoyos Dec 8 2013, the file was provided Dec 9. The problem was reproduced with this file by cehoyos Dec 10. So everything was done quite quickly.

[Michael Niedermayer]

Fixed in 8202c49b43621c04e26d4a3aa83a10e1e5cc1836