Just a thought - is the text “Click to upload” with a cloud icon perhaps a bit misleading?

If it’s fully client side, then you are just opening a file in essence - no clouds in sight!

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 agree something like a folder or file icon would be more accurate.

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.

So ffmpeg's man page is doing less work than your GUI.

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?

vibe-coded, and the github repo does not even contain the sources, just a single 'server.js' that is only for the documentation

Yup the readme reeks of llm generated fluff. Lately I find myself getting more and more suspicious whenever I see lots of emojis in markdown headers..

Fair. The emojis are a style choice -- I find them useful as visual anchors when scanning a long feature list. The code is in docs/ either way.

It looks like most of the sources might be under the “docs” subfolder.

Just look at the descriptive commit messages. /s

Tells you that most here just read the headline and not the code or commits any-more and this will just become abandonware.

Active development -- PR just came in from luispa. Happy to review contributions.

Commit messages are a weak signal. We've had repos with pristine history that died in months and messy ones still running five years later. Who uses it determines longevity, not git log.

Dug into the docs bundle - it's pulling ffmpeg.wasm, the Emscripten port everyone knows. Not much original source because there was never meant to be any.

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?)

~4x slower than native for encoding, which is acceptable for clips under 5 mins. No hardware encoding -- WASM is CPU-bound, for now. WebCodecs could bridge that gap in future.

I would imagine the only way to use NVENC directly from a browser would be via WebCodecs.

Any chance those AVX-512 optimizations they released a while ago work within this? [1]

[1] https://www.phoronix.com/news/FFmpeg-July-2025-AVX-512

I think WASM SIMD is only 128-bit wide.

WASM SIMD is 128-bit wide as dtf noted, so AVX-512 won't apply here. Longer term, WebGPU could be a more interesting path for compute acceleration in the browser than SIMD widening.

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

From https://news.ycombinator.com/item?id=44717303 :

> Objective metrics and tools for video encoding and source signal quality: netflix/vmaf, easyVmaf, psy-ex/metrics, ffmpeg-quality-metrics,

netflix/vmaf: https://GitHub.com/netflix/vmwaf

gdavila/easyVmaf: https://github.com/gdavila/easyVmaf

psy-ex/metrics: https://github.com/psy-ex/metrics/

slhck/ffmpeg-quality-metrics: Calculate quality metrics with FFmpeg (SSIM, PSNR, VMAF, VIF) https://github.com/slhck/ffmpeg-quality-metrics

Something like this would be great too:

The Ardour Manual > Loudness Analyzer and Normalizer: https://manual.ardour.org/mixing/basic-mixing/loudness-analy...

This is a great addition! You can use the raw ffmpeg mode to do this currently if you know the flag syntax

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.

Thank you. This works entirely offline. I work in a univ setting where I cannot easily install software for classes. This can be used as a regular app once installed as a PWA. Even the ffmppeg lib is cached. Once installed it looks like any other app, with dock icon etc.

Go here for live demo: https://tejaswigowda.com/ffmpeg-webCLI/

Thanks for all the comments. Changed upload icon to floppy disk to make it clear that all data stays local.

Note that this is the webpage: https://tejaswigowda.com/ffmpeg-webCLI

Works really well. It does say "100% local. Data never leaves your browser." but indeed, a icon that does not a cloud-upload would be clearer.

Thank you. Switched it to a floppy disk!

Interesting idea - must have been a lot of work to add all those features. I just tried it and it works locally too, which is pretty epic.

Thank you!

Offline PWA capability isn't surprising given service worker maturity, but compiling FFmpeg's full codec support cleanly to WASM is still non-trivial, as far as I know.

I love this, be interesting if this could make an in-browser video editor

It already does -- trim, crop, concatenate, picture-in-picture, side-by-side, subtitle embedding. What would you add? Let's make it happen.

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 browser-as-runtime has one property nothing else has: zero install on every OS. For sensitive files for medical, legal, personal. It's also the only architecture where you can verifiably prove data never left the device.

My personal pain point. I teach entertainment engineering at univ. We need this. All the time. Getting IT to install this in a classroom is a pain. It has already reduced my pain regarding this (anecdotal, yes. But I see the results and am planning to do a usability study). Thought it might be useful to someone else.

this is ffmpeg running inside the browser am I correct? did not know this was possible. wonder what else we can run via webassembly

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.

this is cool. was thinking for this long time. someone shows up

FFmpeg is so useful for TTS

Absolutely. Audio extraction, format conversion, loudness normalization are all there. If you have a specific TTS pipeline in mind the raw FFmpeg mode should handle most of it.

fantastic. It really works great!

Very cool.

This is dope. Made a PR.

Thank you! Reviewed and merged!

Has anyone tested this with files above, say, 500MB? Browser memory limits for WASM are real -- I'd expect it to silently fail or crash on anything resembling production-sized video.