23 ms·
FWIW we’ve been using ffmpeg-wasm on one of our products [0] for a couple months and the main issue is garbage collection. You’re limited to 4GB memory, but if
by 0x62 4y ago
FWIW we’ve been using ffmpeg-wasm on one of our products [0] for a couple months and the main issue is garbage collection. You’re limited to 4GB memory, but if you don’t kill and restart the workers every N operations it crashes the browser tab (even with proper unlinking of files in the virtual FS).
I suspect you could still make it work with clever usage of the File System Access API as a cache, and process larger files in chunks. Then you’d mostly be limited by the Blob storage limits [1], and memory required to merge processed chunks together.
[0] https://nft-inator.com/app https://nft-inator.com/app
[1] https://chromium.googlesource.com/chromium/src/+/224e43ce1ca4f6ca6f2cd8d677b8684f4b7c2351/storage/browser/blob/README.md https://chromium.googlesource.com/chromium/src/+/224e43ce1ca...
- marclundgren 4y agoIt works great for audio. Here's a wasm-ffmpeg solution I created trim audio. https://wasm-audio-clipper.netlify.app/ https://wasm-audio-clipper.netlify.app/ Check the repo: https://github.com/marclundgren/wasm-audio-clipper https://github.com/marclundgren/wasm-audio-clipper. I ended up lazily registering the context. The memory footprint stays lower even after trimming multiple clips on the same session.