I'm using this in a current project and it really is great to be able to do things in the browser that would otherwise require a nontrivial native client. One limitation I'd like to figure out how to get around is the 2GB file size limit. According to the docs, this is a WebAssembly limitation? It's not hard to find videos that cross that size.
There used to be 2GB limitations both on JS typed arrays and on the size of wasm memory, so this might refer to either or both of those. But browsers have been fixing that, here is Chrome doing so back in 2020:
(Note that as mentioned there you need to build the wasm with that support, like -sMAXIMUM_MEMORY=4GB in Emscripten, so ffmpeg.wasm would need that, if it hasn't added it already.)
How slow is it? And why bother when you could run ffmpeg natively and just send it commands from the browser (even suing something as primitive as custom URI)
Apologies - let me try and be more clear. The user loads a local movie into the browser, and the browser then processes locally with ffmpeg. The movie started on the client and stays there. If it is less than 2GB then no problems. If it is larger then it hits this limitation. (I am taking the results from ffmpeg and sending those server side, but those results are always << 2GB and therefore no issues).
Maybe the suggestion is to only load < 2GB into ffmpeg in the browser? I could see how that would work for the 1st chunk. But the 2nd one and beyond would not be valid.
A year ago, I wanted to use this library but it's way too buggy imo. Stuff kept breaking, incompatible with React. Tried to use with Electron.js only to find out it's not supported (I think the issue's still open).
So I ditched this in favor of real ffmpeg binary that I can download according to someone's PC architecture. It works better and is also fast. Downsides? I can't use it on the web but at least electron.js would allow me to use the binary.
I'm not sure I understand your criticism - in what way is it not a port to pure webassembly?
I'm tempted to hazard a guess that you expected a rewrite, but that's not what port normally means - if I said I ported ffmpeg to RISC-V no one would have expected me to have rewritten all of ffmpeg in RISC-V assembly, they would expect that I did mild-to-medium modifications on the source and build system to get it compiling to RISC-V machine code (which is analogous to the ffmpeg.wasm project).
If that's not what you meant, I apologize for interpreting incorrectly!
