Built a browser-based FFmpeg editor that runs entirely client-side via WebAssembly. Your files never leave your device -- all processing happens in a Web Worker. Works offline as an installable PWA after first load.
Yeah, if the author sees this, it would be best to change this to "Click to Open". We can argue about the icon (I would say the floppy image), but seeing the word "upload" with a cloud icon 1000% means "send this up to the Internet."
I guess UI-wise some changes wouldn't be bad, but I am
just glad it works. I am currently converting an ancient
.mpg into a .mp4; I could do so via ffmpeg from the
commandline, but I always forget which options to use,
so a GUI kind of frees brain space here.
this might be an extremely stupid question, but is this just a demo project of https://github.com/ffmpegwasm/ffmpeg.wasm? or is this bringing forth some other utility that im not seeing?
Nice interface at a first glance, for sure can be useful for users who would find using the actual thing too cumbersome. How does performance compare to the native app? Is any form of hardware decoding/encoding like h264_nvenc available? (I guess not?)
Note those only apply to scene_sad which is used for scene change detection and freeze detection and a few other things like mpdecimate -- it's a very specific use case
In 2016 I was working for an organization that wanted a video streaming web app, but could not tolerate any latency. In the past, we solved this with an NAPI extension in Firefox. They removed this for good security reasons, but it left our users without an option. They would have to move to an electron app. Distributing this app and updating it across 1000s of terminals worldwide was not something we were set up to do. I hacked together something like this and could not believe how well it worked. The initial POC is here: https://github.com/colek42/streamingDemo.
I find it fascinating that we keep trying to build things that already exist, but on top of another app (web browser). I mean, it's cool to see, and it will have its use-cases, but I wonder where we'd be if we didn't have to do this.
The things that are harder to get running in a browser via webassembly tend to have a GUI, network communication, or system calls that browsers don’t provide the APIs that are needed to support. But I’ve seen workarounds using websocket proxy servers to get around the lack of raw TCP or UDP socket access.
I’ve been surprised how easy it can be to get Python and C# code running in a browser.
If it’s fully client side, then you are just opening a file in essence - no clouds in sight!
reply