ffmpeg.wasm VS assemblyscript

There's already ffmpeg wasm. I've used it in projects. Works great.

https://github.com/ffmpegwasm/ffmpeg.wasm

There's a low-hanging fruit that I think would make ffmpeg more helpful for regular people.

There's a million terrible websites that offer file conversion services. They're ad-ridden, with god-knows-what privacy/security postures. There's little reason for users to need to upload their files to a third-party when they can do it locally. But getting them to download fiddly technical software is tough - and they're right to mistrust it.

So, there's a WASM version of ffmpeg, already working and hosted at Netlify [1]. It downloads the WASM bundle to your browser and you can run conversions/transformations as you wish, in your browser. Sandboxed and pretty performant too!

If this tool a) was updated regularly b) had a nicer, non-CLI UI for everyday users and c) was available at an easily-Googlable domain name - it would solve all the problems I mentioned above.

[1]: https://ffmpegwasm.netlify.app/

As their github page says, based on https://ffmpegwasm.netlify.app ...

I'm guessing no one did GPU-optimizations? I saw a web app (not an ffmpeg transpilation) that went clever and used WebGL so it can access the GPU and use its parallel processing capabilities...

ffmpeg.wasm: The engine making all these happen. However, I’m a bit concerned about its current situation. The repo has not been updated for more than six months now, and that’s not a healthy sign for an open-source project. Clearly I was reading the commits wrong. The author mentioned “speed up x264 with SIMD intrinsics” in their roadmap (https://github.com/ffmpegwasm/ffmpeg.wasm/discussions/415), which, if landed, could make such on-device video editors much more competitive.

I use https://github.com/ffmpegwasm/ffmpeg.wasm and I want my FFMPEG commands to be hidden from others.

Possibly using this? https://github.com/ffmpegwasm/ffmpeg.wasm

You could try using something like ffmpeg wasm which is a way of using ffmpeg client side in browser. Unfortunately WebAssembly only supports files less than 2 gigabytes, which is a problem for videos. And I don't know if ffmpeg wasm contains ffprobe, so you might have to find another project or try to compile ffprobe to wasm yourself. This stuff is out of my wheelhouse so I can't offer much help.

I like your take but JavaScript was literally the assembly language of the web until WASM came along. There was no other language that TypeScript could compile to.

This train of thought lead me to discover AssemblyScript! https://www.assemblyscript.org/

Incidentally, it’s also what AssemblyScript uses: https://github.com/AssemblyScript/assemblyscript/blob/main/s...

Use it as a Front-End for other low-level languages.

> MHO typescript could just cut loose from its javascript compatibility. Why not compile it to wasm instead of transpiling it to javascript?

Check out AssemblyScript which is exactly that:

https://www.assemblyscript.org/

If you're curious, check out AssemblyScript, that might describe better what needs to be cut from TypeScript to make it possible to be compiled to WASM.

This is kinda the idea behind AssemblyScript, but IIRC it's more of a low-level typescript-ish syntax for WebAssembly.

https://www.assemblyscript.org/ maybe, but I'm not sure exactly what you need.

Exactly, WASM was designed to be very very lightweight... you can put a lot of logic into a very small amount of WASM, but you need a good compiler to do that, or write WASM by hand to really feel the benefit. If you just compile Go to WASM, with its GC, runtime and stdlib included in the binary, yeah it's going to be pretty heavy... Rust doesn't have a runtime but as you said, for some reason, produces relatively large binaries (not the case only in WASM by the way). Probably, the best ways to create small WASM binaries is to compile from C or from a WASM-native language like AssemblySCript (https://www.assemblyscript.org).

Well we have all the new ECMA standards that will be introduced in 5 years now. It's looking more like Java actually. its accessor and typing patterns match it the most. TypeScript has had quite the profound influence over future ECMA design. There is a not so well known project called AssemblyScript which I think has a promising future. Since future ecma standards closely resembles it and TypeScripts popularity has exploded I have a feeling it may become a real standard as well.