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.FFmpeg 2.8 is now available as the latest major update to this important open-source multimedia project. The library can be configured to reject large frames sizes using -size-limit. There's nothing actionable here from the libvpx side. If I set the number of threads in ffmpeg to 1 the allocation profile will roughly match libvpx. I'm not sure about the difference between the source webm and the transmuxed ivf yet.ĭecoding the transmuxed ivf file in ffmpeg shows about the same 7GiB memory usage, so there may be more frame buffering or other allocations. The initial 2 frames are 512x512, but after that they are 15000x15000 which would be the cause of the large allocation in vpxdec. I haven't hit an allocation error on any test devices, but can try something with lower memory. If you have a crash stack trace that points to libvpx we can take a look. I'll take a closer look, but in general the bitstream and file appear to be valid so far. In ffmpeg using both the ffvp9 and libvpx decoders I see a similar max rss:Ĭonverting the file to an ivf file for use in vpxdec shows ~1.4GiB of usage. Apple uses their own parser for the platform. In some of them the demuxer is from ffmpeg, like Chrome. There are different demuxers and decoders in the applications listed, though. 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. I initially reported the issue to WebM/VPX bug tracker, here's the analysis from its dev: Video:41kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 3.560803% Neither bitrate nor constrained quality specified, using default CRF of 32 and bitrate of 256kbit/sec Input #0, matroska,webm, from 'CrashSticker.webm':ĭuration: N/A, start: 0.000000, bitrate: N/A > ffmpeg -i CrashSticker.webm CrashSticker.ivfįfmpeg version -git-f77ac5131c-full_build-Copyright (c) 2000-2022 the FFmpeg developersīuilt with gcc 11.3.0 (Rev1, Built by MSYS2 project)Ĭonfiguration: -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-chromaprint When FFMPEG executable works with this file, it allocates 3 GB of memory on my machine and decoding takes much more time than normal.
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). Applications included: Chrome, MPC-HC, Telegram on Windows, Linux, Android and iOS. A lot of applications playing this small WebM+VP9 file either crash or allocate gigabytes of memory.
0 kommentar(er)
