[FFmpeg-trac] #9932(undetermined:new): Massive memory usage caused by a small file leads to crashes in some applications

FFmpeg trac at avcodec.org
Wed Sep 21 06:23:14 EEST 2022

#9932: Massive memory usage caused by a small file leads to crashes in some
             Reporter:  Athari       |                     Type:  defect
               Status:  new          |                 Priority:  normal
            Component:               |                  Version:
  undetermined                       |  unspecified
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
 A lot of applications playing this small WebM+VP9 file either crash or
 allocate gigabytes of memory. Applications included: Chrome, MPC-HC,
 Telegram on Windows, Linux, Android and iOS. This file is crafted as a
 Telegram sticker and is used by malicious users to make Telegram unusable
 or even crash OS (I've heard it crashes Apple's OSes).

 When FFMPEG executable works with this file, it allocates 3 GB of memory
 on my machine and decoding takes much more time than normal.

 > ffmpeg -i CrashSticker.webm CrashSticker.ivf
 ffmpeg version 2022-05-08-git-f77ac5131c-full_build-www.gyan.dev Copyright
 (c) 2000-2022 the FFmpeg developers
   built with gcc 11.3.0 (Rev1, Built by MSYS2 project)
   configuration: --enable-gpl --enable-version3 --enable-static --disable-
 w32threads --disable-autodetect --enable-fontconfig --enable-iconv
 --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma
 --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt
 --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray
 --enable-libcaca --enable-sdl2 --enable-libdav1d --enable-libdavs2
 --enable-libuavs3d --enable-libzvbi --enable-librav1e --enable-libsvtav1
 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2
 --enable-libxvid --enable-libaom --enable-libjxl --enable-libopenjpeg
 --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r
 --enable-libfreetype --enable-libfribidi --enable-liblensfun --enable-
 libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-
 llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc
 --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-libshaderc
 --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio
 --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-
 libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora
 --enable-libtwolame --enable-libvo-amrwbenc --enable-libilbc --enable-
 libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex
 --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite
 --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-
   libavutil      57. 24.101 / 57. 24.101
   libavcodec     59. 27.100 / 59. 27.100
   libavformat    59. 23.100 / 59. 23.100
   libavdevice    59.  6.100 / 59.  6.100
   libavfilter     8. 38.100 /  8. 38.100
   libswscale      6.  6.100 /  6.  6.100
   libswresample   4.  6.100 /  4.  6.100
   libpostproc    56.  5.100 / 56.  5.100
 Input #0, matroska,webm, from 'CrashSticker.webm':
     title           : https://t.me/totallynormalchannel
     ENCODER         : Lavf58.29.100
   Duration: N/A, start: 0.000000, bitrate: N/A
   Stream #0:0: Video: vp9 (Profile 0), yuv420p(tv), 512x512, SAR 1:1 DAR
 1:1, 25 fps, 25 tbr, 1k tbn (default)
       ALPHA_MODE      : 1
       ENCODER         : Lavc58.54.100 libvpx-vp9
       DURATION        : 00:00:04.920000000
 Stream mapping:
   Stream #0:0 -> #0:0 (vp9 (native) -> vp8 (libvpx))
 Press [q] to stop, [?] for help
 [libvpx @ 0000023b9c822ec0] v1.11.0-194-g8ac72859e
 [libvpx @ 0000023b9c822ec0] Neither bitrate nor constrained quality
 specified, using default CRF of 32 and bitrate of 256kbit/sec
 Output #0, ivf, to 'CrashSticker.ivf':
     title           : https://t.me/totallynormalchannel
     encoder         : Lavf59.23.100
   Stream #0:0: Video: vp8 (VP80 / 0x30385056), yuv420p(tv, progressive),
 512x512 [SAR 1:1 DAR 1:1], q=2-31, 256 kb/s, 25 fps, 25 tbn (default)
       ALPHA_MODE      : 1
       DURATION        : 00:00:04.920000000
       encoder         : Lavc59.27.100 libvpx
     Side data:
       cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
 frame=  123 fps=5.5 q=32.0 Lsize=      43kB time=00:00:04.92 bitrate=
 71.3kbits/s speed=0.222x
 video:41kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
 muxing overhead: 3.560803%

 I initially reported the issue to WebM/VPX bug tracker, here's the
 analysis from its dev:

 > libwebm fails to load the file (in vpxdec, mkvparser_sample, webm_info),
 though the newer webm_parser handles it all right with minimal memory
 usage. There are different demuxers and decoders in the applications
 listed, though. In some of them the demuxer is from ffmpeg, like Chrome.
 Apple uses their own parser for the platform.
 > In ffmpeg using both the ffvp9 and libvpx decoders I see a similar max
 > libvpx: bench: maxrss=7470548kB
 > ffvp9: bench: maxrss=7466176kB
 > Converting the file to an ivf file for use in vpxdec shows ~1.4GiB of
 usage. I'll take a closer look, but in general the bitstream and file
 appear to be valid so far. If you have a crash stack trace that points to
 libvpx we can take a look. I haven't hit an allocation error on any test
 devices, but can try something with lower memory.
 > The initial 2 frames are 512x512, but after that they are 15000x15000
 which would be the cause of the large allocation in vpxdec. I'm not sure
 about the difference between the source webm and the transmuxed ivf yet.
 > Decoding the transmuxed ivf file in ffmpeg shows about the same 7GiB
 memory usage, so there may be more frame buffering or other allocations.
 If I set the number of threads in ffmpeg to 1 the allocation profile will
 roughly match libvpx.
 > There's nothing actionable here from the libvpx side. The library can be
 configured to reject large frames sizes using --size-limit [1].

 I don't know what arguments they used exactly and couldn't reduce memory
 usage by setting threads to 1, but FFMPEG does show unreasonable memory
 allocations with the command line I used above.
Ticket URL: <https://trac.ffmpeg.org/ticket/9932>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list