DEV Community

Cover image for What I learned shipping a tiny FFmpeg desktop app
Sanskar Kharya
Sanskar Kharya

Posted on

What I learned shipping a tiny FFmpeg desktop app

I kept hitting the same annoyance. Someone sends me a .mov, I need an .mp4, and every free option online wants me to upload the file to a server I do not trust. So I built mov2mp4, a small desktop app that converts locally and never touches the network.

The conversion itself is the easy part. FFmpeg already does it in one line:

ffmpeg -i input.mov -c:v libx264 -c:a aac output.mp4
Enter fullscreen mode Exit fullscreen mode

Wrapping that in something a non-developer can actually use is where the real work lived.

Bundling FFmpeg so nobody has to install it

My first version just called ffmpeg from the system path. That works on my machine and almost nobody else's. Most people do not have FFmpeg installed, and I did not want the first step of my app to be "go install a command line tool."

So I bundled the FFmpeg binary inside the app and pointed the code at the bundled copy instead of the system one. The app got bigger, but the install went from three steps to zero. For a tool aimed at people who just want their file converted, that trade was worth it.

Batch and threading

Once one file worked, people wanted folders. Running conversions one at a time was slow, so I moved to a worker setup that processes several files at once and reports progress per file. The lesson I did not expect: I had to add a clean way to cancel a running job. If you kill the process mid write, you get a half-written .mp4 that looks real until someone tries to play it. Now a cancel deletes the partial output instead of leaving garbage behind.

The part nobody warns you about: unsigned apps

This one cost me the most time. My builds are not code signed yet, so:

  • On macOS, Gatekeeper blocks the app on first open and hides the real "Open" button behind Privacy and Security settings.
  • On Windows, SmartScreen throws up a blue "unknown publisher" screen.

Users read that as "this app is broken" or "this app is malware." Neither is true, but the operating system does not give me a friendly way to explain that. For now I wrote a short first launch note in the README and added a small helper so people can get past the warning once. Proper signing is on my list, but certificates cost money and I wanted the tool out the door.

What I would tell past me

The converter was a weekend. The packaging, the cancel logic, and the "why is my OS scaring my users" problem took far longer. If you are shipping a desktop tool built on an existing binary, budget your time for the wrapper, not the core.

Repo is here if you want to poke at it: https://github.com/MaybeSomeone-arc18/mov2mp4

Here's the website link if you want to use it:
mov2mp4.vercel.app

Top comments (2)

Collapse
 
raknaos profile image
Raknaos

"A cancel deletes the partial output instead of leaving garbage behind" — this is the kind of lesson that only exists because someone found a broken .mp4 in their folder two days later. The stronger version of the same idea is writing to a temp name and doing an atomic rename on success, so even a crash (not just a polite cancel) leaves the directory as it was found; killed processes don't always get the cleanup handler.

And your "budget your time for the wrapper, not the core" matches every desktop thing I've shipped: the conversion logic was a weekend, the notary/signing/SmartScreen story is the actual product work. The README first-launch note is the honest bootstrap, but I'm curious whether you're planning Apple notarization first (cheaper, kills most Gatekeeper scare) or the Windows certificate — because those two costs are wildly asymmetric.

Collapse
 
sansk_ya profile image
Sanskar Kharya

Great point on the atomic rename — you're right that the cancel path is the easy case and a hard crash blows right past the cleanup handler. I'll switch to writing a temp file and renaming on success so the only failure mode is a leftover temp file instead of a corrupt "real" output. Cheap change, strictly better.

And yeah, the signing/notarization story is turning out to be the actual product. Plan is Apple notarization first for exactly the reason you said — it's the cheaper path and kills the Gatekeeper scare that hits the most users. The Windows cert is on the list but I'm sitting on the README first-launch note for now until the cost makes sense. Curious if you went the OV or EV route on Windows, and whether it was worth it?