4 ms·
This is awesome. I tried to do something similar a long time ago (back when the html5 video tracks/codecs API were released). I'd love to see a FFmpeg compilat
by syrusakbary 6y ago
This is awesome. I tried to do something similar a long time ago (back when the html5 video tracks/codecs API were released).
I'd love to see a FFmpeg compilation to WASI, so it can be run also standalone in server-side runtimes (such as Wasmer or WAVM).
I wonder if threads would made a WASI compilation more challenging?
- stjohnswarts 6y agoNot knowing much about WASM wouldn't just using straight up native platform ffmpeg be a lot faster and more energy efficient if you're going to be running it on the backend anyway?
- sp332 6y agoFaster, yes. But a WASM version would have other advantages: it wouldn't need to be recompiled for each platform, and it would run in a sandbox.
- syrusakbary 6y agoThe advantages of using Wasm in this case would be: multiplaform/multichipset binaries along with a completely sandboxed environment. It's true that the speed will be a bit slower (I expect to be 5-10% slower than native), but in some cases the gains could outweight the relative slowdown.
- rndgermandude 6y agoThe popular external encoder libraries such as x264/x265/libvpx/libaom-av1 as well as a lot of parts of ffmpeg itself have fine-tuned assembly and sometimes C for a lot of things that you'd be missing out on. So I'd guess the speed is more than a bit slower, at least when run on common x84-64 and arm targets, even considering any WASI runtime JIT.
- syrusakbary 6y agoTrue! I haven't considered the fine-tuned assembly inside of the encoders. I would love to have it working in Wasmer so we can benchmark both paths (native vs Wasm).