[FFmpeg-trac] #3208(FFmpeg:new): Very long CPU-bound loop with -fflags +genpts and -af volumedetect
FFmpeg
trac at avcodec.org
Sun Dec 8 19:18:31 CET 2013
#3208: Very long CPU-bound loop with -fflags +genpts and -af volumedetect
----------------------------------+----------------------------------
Reporter: lelegard | Type: defect
Status: new | Priority: normal
Component: FFmpeg | Version: 2.1.1
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
----------------------------------+----------------------------------
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.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/3208>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list