ffmpeg.wasm
ffmpeg.wasm copied to clipboard
ffmpegwasm
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
@hoomanaskari I agree, using CORP and COEP is an issue regarding the use of external resources.
However, I think an appropriate configuration of your back-end should let you use Stripe for example ? I use ffmpeg-wasm in production (and I enable WASM threads) but I think I can use almost every service I want by configuring my back-end the right way.
Note: I use ffmpeg.wasm in the browser (frontend)
@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.
FFMPEG WASM is almost unusable at the current moment. Ah well, there goes my project down the drain.
@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.
I built the project manually to make it work with 1 core
https://github.com/ffmpegwasm/ffmpeg.wasm/issues/137
It's just a bit slow, but honestly if you just have short videos it works fine
@CrypticSignal Unusable in what way?
https://github.com/ffmpegwasm/ffmpeg.wasm/issues/137
@CrypticSignal Please refer to the original question for the reason behind it.
@hoomanaskari The OP said "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)"
I don't understand why you'd want to make this slower? Or am I misreading that and what you're saying is that using threads instead of a single core makes it slower?
@CrypticSignal
"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."
The point is not making it slower, the point is making it production-ready for an actual commercial and production-ready application.
Basically once you enable CORP and COEP which is required for wasm threads, you will have to set Cross-Origin-Opener-Policy: same-origin-allow-popups on all popups and iframe, if the iframes belong to you, you can do it yourself, but if in my case the iframe is the Stripe Checkout Form, then you are out of luck unless Stripe decides to enable it. I already contacted them and they refused to do anything about it at moment.
Giving an option to disbale threads, allows me to start using ffmpeg.wasm today and if at some point the CORP and COEP problems got resolved by Stripe etc. then I can enable it and make my app even faster.
@hoomanaskari I see, so CORP and COEP are only needed if threads are used but not if a single core is used. Interesting. I have no idea how WASM works, so I didn't know this.
The ffmpeg-asm.js doesn't have the security issues but is super slow.
If someone wants to try it out I threw up a demo here:
https://www.zaxtunes.com/client_transcoder/
Should be extremely easy to adapt to anyone elses use case.
@hoomanaskari Hi, thanks for the reply, I was wrong: we can't use Stripe on our website as well...
I'm thinking about workarounds. Do you think you can only cross-isolate a specific page (e.g. the page that runs ffmpeg wasm) so you can still use Stripe on other pages?
Otherwise I'll have to host our payment system on a different domain...