HN Explorer

Show HN: Ez FFmpeg – Video editing in plain English (npmjs.com)

420 points by josharsh ↗ HN
I built a CLI tool that lets you do common video/audio operations without remembering ffmpeg syntax.

Instead of: ffmpeg -i video.mp4 -vf "fps=15,scale=480:-1:flags=lanczos" -loop 0 output.gif

You write: ff convert video.mp4 to gif

More examples: ff compress video.mp4 to 10mb ff trim video.mp4 from 0:30 to 1:00 ff extract audio from video.mp4 ff resize video.mp4 to 720p ff speed up video.mp4 by 2x ff reverse video.mp4

There are similar tools that use LLMs (wtffmpeg, llmpeg, ai-ffmpeg-cli), but they require API keys, cost money, and have latency.

Ez FFmpeg is different: - No AI – just regex pattern matching - Instant – no API calls - Free – no tokens - Offline – works without internet

It handles ~20 common operations that cover 90% of what developers actually do with ffmpeg. For edge cases, you still need ffmpeg directly.

Interactive mode (just type ff) shows media files in your current folder with typeahead search.

npm install -g ezff

57 comments

[ 3.0 ms ] story [ 71.5 ms ] thread
HelloUsername
The one good usecase I've found for AI chatbots, is writing ffmpeg commands. You can just keep chatting with it until you have the command you need. Some of them I save as an executable .command, or in my .txt note.
corobo
LLMs are an amazing advance in natural language parsing.

The problem is someone decided that and the contents of Wikipedia was all something needs to be intelligent haha

Tempest1981
I was surprised that macOS (QuickTime/Preview, iMovie) can't read .mp4 files. Not sure if it was due to H.265 or the audio codec. I tried using ffmpeg to convert to .mov but that also failed to open, since I guess MOV is just another container format.

Is there an easier way?

andrewf
Try something like: ffmpeg -i in.mp4 -c:v h264 -c:a aac out.mp4

To re-encode the content into H.264+AAC, rather than simply "muxing" the encoded bitstreams from the MP4 container into a new MOV container.

mmahemoff
Very cool idea since ffmpeg is one of those tools that has a few common tasks but most users would need to look up the syntax every time to implement them (or make an alias). In line with the ease of use motivation, you might consider supporting tab completion.
dllu
When converting video to gif, I always use palettegen, e.g.

    ffmpeg -i input.mp4 -filter_complex "fps=15,scale=640:-2:flags=lanczos,split[a][b];[a]palettegen=reserve_transparent=off[p];[b][p]paletteuse=dither=sierra2_4a" -loop 0 output.gif
See also: this blog post from 10 years ago [1]

[1] https://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html

xattt
Those command flags just roll off the tongue like two old friends catching up!

/s

dspillett
Does ffmpeg's gif processing support palette-per-frame yet? Last time I compared them (years ago, maybe not long after that blog post), this was a key benefit of gifski allowing it to get better results for the same filesize in many cases (not all, particularly small images, as the total size of the palette information can be significant).
foltik
It’s a shame this isn’t the default.
BoingBoomTschak
I use `split[s0][s1];[s0]palettegen=max_colors=64[p];[s1][p]paletteuse=dither=bayer` personally, limiting the number of colors is a great way to transparently (to a certain point, try with different values) improve compression, as is bayer (ordered) dithering which is almost mandatory to not explode output filesizes.
dceddia
In many cases today “gif” is a misnomer anyway and mp4 is a better choice. Not always, not everywhere supports actual video.

But one case I see often: If you’re making a website with an animated gif that’s actually a .gif file, try it as an mp4 - smaller, smoother, proper colors, can still autoplay fine.

Kwpolska
GitHub repo link returns 404.
eviks
That's the problem ideally solved by typed data, i.e., some UI where instead of trying to memorize whether it's thumb/s/nails you can read the closed list of alternatives, read contextual help and pick one
bdbdbdb
Sometimes an idea comes along thats so obvious it makes me angry. I have been struggling with ffmpeg commands for over well a decade. All the time I wasted googling and creating scripts so I wouldn't have to regoogle and this could have existed literally from day one
petterroea
Somehow it seems ffmpeg has become the "Can it run crysis" of UX design
spullara
I have a little script that I use on the CLI to do this kind of stuff (calls an LLM to figure out how to do CLI stuff) but you can just as easily now use any of the coding agents.
pdyc
interesting approach, i solved similar problem by creating visual tool to generate ffmpeg commands but its not the same(it cant do conversion etc.)

I like that you took no AI approach, i am looking for something like this i.e. understanding intent and generating command without using AI but so far regex based approaches have proved to be inadequate. I also tried indexing keywords and creating index of keywords with similar meaning that improved the situation a bit but without something heavy like bert its always a subpar experience.

broken-kebab
I like the idea, but a CLI utility dependent on Node.js is not a good thing frankly.
Joyfield
Uhm... Millibit, Millibyte, Megabit, Megabyte?
gamer191
Thanks, will definitely check this out

Has anyone else been avoiding typing FFmpeg commands by using file:// URLs with yt-dlp

ramigb
That's beautiful! I see a .claude folder in your code, I am curious if you've "vibecoded" the whole project or just had claude there for some tasks! not that it matters or takes away from your work but just pure curiosity as someone who enjoys betting on the LLM output XD
ramon156
> it handles 20 common patterns ... that cover 90%

Could you elaborate on this? I see a lot of AI-use and I'm wondering if this is claude speaking or you

alexellisuk
This looks handy.. along with the odd gist of "convert mkv to mp4" that I have to use every other week.

Quite telling that these tools need to exist to make ffmpeg actually usable by humans (including very experienced developers).

qbow883
Days since last ffmpeg CLI wrapper: 0

It's incredible what lengths people go to to avoid memorizing basic ffmpeg usage. It's really not that hard, and the (F.) manual explains the basic concepts fairly well.

Now, granted, ffmpeg's defaults (reencoding by default and only keeping one stream of each type unless otherwise specified) aren't great, which can create some footguns, but as long as you remember to pass `-c copy` by default you should be fine.

Also, hiding those footguns is likely to create more harm than it fixes. Case in point: "ff convert video.mkv to mp4" (an extremely common usecase) maps to `ffmpeg -i video.mkv -y video.mp4` here, which does a full reencode (losing quality and wasting time) for what can usually just be a simple remux.

Similarly, "ffmpeg extract audio from video.mp4" will unconditionally reencode the audio to mp3, again losing quality. The quality settings are also hardcoded and hidden from the user.

I can sympathize with ffmpeg syntax looking complicated at first glance, but the main reason for this is just that multimedia is really complicated and that some of this complexity is necessary in order to not make stupid mistakes that lose quality or waste CPU resources. I truly believe that these ffmpeg wrappers that try to make it seem overly simple (at least when it's this simple, i.e. not even exposing quality settings or differentiating between reencoding and remuxing) are more hurtful than helpful. Not only can they give worse results, but by hiding this complexity from users they also give users the wrong ideas about how multimedia works. "Abstractions" like this are exactly how beliefs like "resolution and quality are the same thing" come to be. I believe the way to go should be educating users about video formats and proper ffmpeg usage (e.g. with good cheat sheets), not by hiding complexity that really should not be hidden.

Edit: Reading through my comment again, I have to apologize for the slightly facetious opening statement, even if I quality it later on. The fact that so many ffmpeg wrappers exists is saying something about its apparent difficulty, but as I argue above, a) there are reasons for this (namely, multimedia itself just being complicated), and b) I believe there are good and bad ways to "fix" this, with oversimplified wrappers being more on the "bad" side.

vivzkestrel
I would love to see something like this for OpenSSL
gcanyon
I can only speak to my experience, but I spent a long time being puzzled by video editor user interfaces, until I ran into ScreenFlow about ten years ago. For whatever reason, the UI clicked, and I've used it ever since. It's a single purchase, not monthly, and relatively affordable. https://www.telestream.net/screenflow/overview.htm
karmakaze
I would definitely use an LLM, to see what the suggested options do and tweak them.

Using a different package name could be helpful. I searched for ezff docs and found a completely different Python library. Also ez-ffmpeg turns up a Rust lib which looks great if calling from Rust.

btbuildem
npm? Have we learned nothing from the weekly node/npm security breaches? Not putting that hot mess anywhere near my dev box, thanks.
Workaccount2
The total upheaval of the current computing paradigm that AI will bring, if nothing else, is

"Hey computer, can you convert that funny kitchen cooking scene in this movie to a .gif I can share online?"

You're wasting your time on a dead man walking paradigm doing anything else. "Plain English" actually means plain English now.