Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Ez FFmpeg – Video editing in plain English

npmjs.com

Post reply on HN
Print view View original

161–170 of 210 posts

Re: Show HN: Ez FFmpeg – Video editing in plain English

#161

Post by jimbobthrowawy »

naikrovek wrote: post #156

Small English nitpick: > ff slow down video.mp4 by 2x How do you slow something down by 2x? x is a multiplier. 2 is a number greater than 1. Multiplying by a number greater than 1 makes the result LARGER. If you’re talking about “stretch movie duration to 2x”, say that instead . Saying something is 2x smaller or 2x shorter or 2x cheaper doesn’t make sense. 2x what? What is the unit of “cheap” or “short” or “small”? H…

Reminds me of a thing Steve Mould mentioned in a video about a claim in a book "The temperature outside an aeroplane is six times colder than the temperature inside a freezer."

https://www.youtube.com/watch?v=C91gKuxutTU - Stand-up comedy routine about bad science

Re: Show HN: Ez FFmpeg – Video editing in plain English

#162

Post by crazygringo »

darrenf wrote: post #153
crazygringo wrote: post #144

Earlier quoted context omitted.

I swear I want this as a general tool for all command-line tools. Start the tool, and just list all of the options in order of usage popularity to toggle on as desired, with a brief explanation, and a field to paste in arguments like filenames or values when needed. If an option is commonly used with another (or requires it), provide those hints (or automatically add the necessary values). If a value itself has struc…

I’m trying to understand the “In order of usage popularity” thing — this implies telemetry in CLIs, doesn’t it? Wouldn’t the order of options change/fluctuate over time? Or if no telemetry but based on local usage, it would promote/reinforce the options you already can recall and do use, hiding the ones you can’t/don’t?

You could make it opt-in telemetry in the tool itself, that would probably be good enough.

But also, you could probably be just as accurate by asking an LLM to order the options by popularity based on their best guess based on all the tutorials they've trained on.

Or just scrape Stack Overflow for every instance of a command-line invocation for each tool and count how many times each option is used.

Ranking options by usage is the least complicated part of this, I think. (And it only matters for the popular options anyways -- below a certain threshold they can just be alphabetical.)

Re: Show HN: Ez FFmpeg – Video editing in plain English

#164

Post by zahlman »

qbow883 wrote: post #57

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 co…

> 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.

I'm usually the one telling everyone else that various Python packaging ecosystem concepts (and possibly some other things) are "really not that hard". Many FFMpeg command lines I've encountered come across to me like examples of their own, esoteric programming language.

> 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.

That sounds like a bug report / feature request rather than a problem with the approach.

> The quality settings are also hardcoded and hidden from the user.

This is intended so that users don't have to understand what quality settings are available and choose a sensible default.

> and that some of this complexity is necessary in order to not make stupid mistakes

For example, the case of avoiding re-encodes to switch between container formats could be handled by just maintaining a mapping.

In fact, I've felt the lack of that mapping recently when I wanted to extract audio from some videos and apply a thumbnail to them, because different audio formats have different rules for how that works (or you might be forced to use some particular container format, and have to research which one is appropriate).

Re: Show HN: Ez FFmpeg – Video editing in plain English

#165

Post by zahlman »

crazygringo wrote: post #162
darrenf wrote: post #153

Earlier quoted context omitted.

I’m trying to understand the “In order of usage popularity” thing — this implies telemetry in CLIs, doesn’t it? Wouldn’t the order of options change/fluctuate over time? Or if no telemetry but based on local usage, it would promote/reinforce the options you already can recall and do use, hiding the ones you can’t/don’t?

You could make it opt-in telemetry in the tool itself, that would probably be good enough. But also, you could probably be just as accurate by asking an LLM to order the options by popularity based on their best guess based on all the tutorials they've trained on. Or just scrape Stack Overflow for every instance of a command-line invocation for each tool and count how many times each option is used. Ranking options b…

> But also, you could probably be just as accurate by asking an LLM to order the options by popularity based on their best guess based on all the tutorials they've trained on.

> Or just scrape Stack Overflow for every instance of a command-line invocation for each tool and count how many times each option is used.

Even trusting the developer's intuition is better than nothing, at least if you make sure the developer is prompted to think about it. (For major projects, devs might also be aware that certain features are associated with a large fraction of issue reports, for example.)

Re: Show HN: Ez FFmpeg – Video editing in plain English

#166

Post by nextstep »

This is very nice. When I use ffmpeg recently I usually ask an LLM first but it often takes a few tries to get the exact incantation right.

On a side note (I’m not a web developer), why would a command line tool like this be written and distributed using node.js? Seems like an unnecessary risk to use JavaScript for a basic (local) command line tool. Couldn’t this be written more simply in like Rust or something?

Re: Show HN: Ez FFmpeg – Video editing in plain English

#167

Post by phil294 »

PaulDavisThe1st wrote: post #148
phil294 wrote: post #111

I like it and would like to see an entire Linux OS being done in a similar manner. Or shell / wrapper / whatever. A sane homogeneous cli for once, that treats its user as a human instead of forcing them to remember the incompatible invocation options of `tar` and `dd` for absolutely no reason. zip my-folder into my-zip.tar with compression level 9 write my-iso ./zip.zip onto external hard drive git delete commit 1a4d…

> write my-iso ./zip.zip onto external hard drive Dang! not that one , the other one! > zip my-folder into my-zip.tar with compression level 9 What do you mean, I don't have write permissions in the current working directory? I meant for you to put the output in $HOME, i mean /tmp, i mean /var/tmp, i mean on the external hard drive, no other other one. > git delete commit 1a4db4c What did you do? I didn't mean delete…

Things that definitely need interactive prompts before running or fail out of ambiguity otherwise. Let's not pretend these are impossible problems to overcome design-wise.

Re: Show HN: Ez FFmpeg – Video editing in plain English

#168

Post by zzzeek »

qbow883 wrote: post #157
zzzeek wrote: post #149

Earlier quoted context omitted.

sure here's a command that a program I wrote to record my practicing and produce different mixes uses /usr/bin/ffmpeg -i "/path/to/musicfile.mp3" -i "/path/to/covertune.mp3" \ -filter_complex [1:a]volume=1[track1];[0a][track1]amix=normalize=false[output] \ -map [output] -b:a 192k -metadata title=15:17:01 -metadata "artist=Me, 2025" \ -metadata album=2025-12-23 "/path/to/file.mix.mp3" chance of my coming up with that…

But the chances of you being able to achieve the same with the linked tool are also zero. That's all I am really saying. I'm not arguing that ffmpeg can get very complex (I was talking about "basic" ffmpeg usage in my original comment), just that `ff convert inputfile to ext` is not really simpler than `ffmpeg -i inputfile -o outputfile.ext`, which is all that this ( this specific ) tool is really doing.

Oh, well yes the ff tool shown here is a classic 80% kind of thing for sure . Claude OTOH will get you about 98% and can explain the options to you as well

Re: Show HN: Ez FFmpeg – Video editing in plain English

#169

Post by nulltype »

naikrovek wrote: post #156

Small English nitpick: > ff slow down video.mp4 by 2x How do you slow something down by 2x? x is a multiplier. 2 is a number greater than 1. Multiplying by a number greater than 1 makes the result LARGER. If you’re talking about “stretch movie duration to 2x”, say that instead . Saying something is 2x smaller or 2x shorter or 2x cheaper doesn’t make sense. 2x what? What is the unit of “cheap” or “short” or “small”? H…

Isn’t it somewhat common to say something like “slow this down by a factor of 2”?

Re: Show HN: Ez FFmpeg – Video editing in plain English

#170

Post by navane »

ninalanyon wrote: post #104
qbow883 wrote: post #57

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 co…

> It's really not that hard, if you are doing it often that's true. But for people like me who do it once every month or two it really is hard to memorize, especially if it's not exactly the same task. What I would love would be an interactive script that asked me what I was trying to do and constructed a command line for me while explaining what it would do and the meaning of each argument. And of course it should f…

I also use ffmpeg once a month. My new plan: build my own scripts like the ones in op. But self built, only for that operation or three that I do.
Post reply on HN