ffmpeg.wasm is not "technically" production ready!

I believe it makes sense to add an option to disable the WASM threads and use a single core (be it that it makes it slower). ffmpeg.js is massive and extremely slow and does not support most of the options we need, so it is not an option for us. At the same time, any attempt to use CORP and COEP disables Stripe, Intercom, and many other necessary integrations on our production website, which in effect makes ffmpeg.wasm not production-ready.

What happened to SharedArrayBuffer after the Spectre is fairly new and it’s going to take some time for all the other companies out there to jump on the cross-origin isolation bandwagon.

Currently, there is only one way to use ffmpeg.wasm in production, which is by signing up for an origin trial to be able to use SharedArrayBuffers without cross-origin isolation, but this only works on Chrome, and only until Chrome 103, after which we are back to square one. There is some hope according to this article that options like Cross-Origin-Opener-Policy: same-origin-allow-popups might work in the future, but no one knows yet how many of those integrations would break again, back to my initial statement, without this option ffmpeg.wasm is not going to be actually production-ready.

---

_Originally posted in https://github.com/ffmpegwasm/ffmpeg.wasm/issues/137#issuecomment-975383348_

[CrypticSignal]

@NayamAmarshe Unusable in what way? My website (GitHub repo: https://github.com/CrypticSignal/av-converter) is using FFmpeg WASM and it seems to be working okay, although it would be nice if the transcoding speed was as fast as running FFmpeg directly in the terminal.

[hoomanaskari]

@julienbeisel I consulted with Stripe about the issue, unfortunately, this is something that has to be fixed by them, and they are not willing to solve it anytime soon. Same with Intercome. Because they both use iframes and CORP/COEP will block all unsafe iframes.