> It's really not that hard,

I've learned not to say this. Different things are easy/hard for each of us.

Reminds me of a discussion where someone argued, "why don't all the poor/homeless people just go get good jobs?"

Edit: I know your comment was meant to inspire/motivate us to try harder. Maybe it's easier than it appears.

> 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 favour commands that do not re-encode where possible.

Yes, I use ffmpeg about once a year, in about 350 years I really ought to have all the syntax figure out.

>It's really not that hard

It is only a couple of thousand options[0], just memorize them! It super simple, barely an inconvenience!

[0]https://gist.github.com/tayvano/6e2d456a9897f55025e25035478a...

> It's incredible what lengths people go to to avoid memorizing basic ffmpeg usage. It's really not that hard

It's not hard - just not a good use of our time. For 99% of HN users, ffmpeg is not a vital tool.

I have to use it less than twice a year. Now I just go and get an LLM to tell me the command I need.

And BTW, I spend a lot of time memorizing things (using spaced repetition). So I'm not averse to memorizing. ffmpeg simply doesn't warrant a place in my head.

You're getting a lot of flak due to how you started off your comment, but I mostly agree with you.

In my opinion there are two kinds of users: 1. Users who use FFmpeg regularly enough to know/understand the parameters. 2. Users who only use FFmpeg once in a while to do something specific.

This wrapper is superfluous for users in group number 1. But group number 2 does not really get much out of it either, for the reasons you've mentioned.

As a member of group 2, I usually want to do something very specific (e.g. remove an audio track, convert only the video, remux to a different container, etc.). A simple English wrapper does not help me here because it is not powerful enough; the defaults are usually not what I want. What I need is a tool that will take a more detailed English statement of what I want to achieve and spit out the FFmpeg command with explanations for what each parameter does and how it achieves my goal. We have this today: AI; and it mostly works (once you've gone through several iterations of it hallucinating options that do not exist...).

> It's really not that hard, and the (F.) manual explains the basic concepts fairly well.

Not that hard for you maybe. These things are not universal. You might wish to reconsider your basic assumption that everyone is too lazy to do this easy thing.

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

There was an ffmpeg drag-and-drop GUI that let you create ffmpeg commands visually instead of having to remember all the right arguments. Inputs, filters and outputs are all nodes in a graph, and then you connect them together. When done you would export it as an ffmpeg command to run.

As an occasional user this was a lot easier to use than having to remember all of the commands, and it did it all without hiding the complexity from the user.

Unfortunately it looks like they tried to monetize it but then later shut down. It doesn't look like they posted the source code anywhere.

https://web.archive.org/web/20230131140736/https://ffmpeg.gu...

well if i follow your logic then assembly looks complicated at first glance and if people spent more time and effort they could get used to it.

Here I was trusting my own experience. Silly me. I should’ve been listening to some HN user’s assertion as to what is “easy” and “hard”.

If you use it from time to time it would be very challenging to remember the million of different options ffmpeg has.

“It's really not that hard”

I’m going to guess your job does not involve much UX design?

Isn’t this the nature of all software abstractions? They often introduce a less performant way of executing a task at the tradeoff of user convenience?

Totally disagree, I have a wrapper I wrote myself for converting things, often for sharing the odd little clip online or such. It produces a complex command that is not easy to just type out, that does multiple things to maximise compatibility like

- making sure pixel are square while resizing if the video resolution is too large

    ("scale=w=if(gt(iw*sar\\,ih)\\,min(ceil(iw*sar/2)*2\\,{})\\,ceil(iw*sar*min(ih\\,{})/ih/2)*2):h=if(gt(ih\\,iw*sar)\\,min(ceil(ih/2)*2\\,{})\\,ceil(ih*min(iw*sar\\,{})/iw/sar/2)\*2):out_range=limited,zscale,setsar=1")

- setting this one tag on hevc files that macos needs for them to be recognised as hevc but isn't set by default

- calculating the target bitrate if I need a specific filesize and verifying the encode actually hit that size and retrying if not (doesn't always work first time with certain hardware encoders even if they have a target or max bitrate parameter)

- dealing with 2-pass encoding which is fiddly and requires two separate commands and the parameters are codec specific

- correctly activating hardware encoding for various codecs

- etc

And this is just for the basic task of "make this into a simple mp4"

Yeah, a decade or so ago, I was constantly looking for GUIs to drive ffmpeg, but eventually I kind of realized I was spending more time playing with GUIs compared to just learning the basics of ffmpeg.

I will admit that I still do need to occasionally look up specific stuff, but for the most part I can do most of the common cases from memory.

“It’s really not that hard”, well a lot of people have better things to do than remember parameters to commands we barely use.

It's not hard, but it's one of those tools where the user has to think about how the tool is implemented.

Even if the abstractions get leaky, people yern for goal/workflow oriented UX.

Some people just want to use an intuitive tool with better QoL, even if it leads to compromises, to do a job swiftly without going over documentation/learning a ton of new things. Not everything has to be an educational experience. ffmpeg exists in its original form like you prefer, but some folks want to use lossless cut. Nothing wrong with that IMO.

Personally I think it’s great that it’s such a universally useful tool that it has been deployed in so many different variations.

so you know how to swap audio with -map without having to look it up?

You know, writing code that doesn't leak memory is really not that hard.

There. I've debunked Java, Python, PHP, Perl, and Rust.

(Or maybe, just maybe, tools should make our lives easier.)

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"

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.

I've been thinking of integrating pngquant as an ffmpeg filter, it would make it possible to generate even better pallettes. That would get ffmpeg on par with gifski.

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

Gifski (https://gif.ski/) might be a good alternative to look to that's gif-pallete aware.

It’s a shame this isn’t the default.

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.

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

/s

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

As pessimistic about it as I am, I do think LLMs have a place in helping people turn their text description into formal directives. (Search terms, command-line, SQL, etc.)

... Provided that the user sees what's being made for them and can confirm it and (hopefully) learn the target "language."

Tutor, not a do-for-you assistant.

One that older AI struggled with was the "bounce" effect: play from 0:00 to 0:03, then backwards from 0:03 to 0:00, then repeat 5 times.

But doesnt something like this interface kind of show the inefficiency of this? Like we can all agree ffmpeg is somewhat esoteric and LLMs are probably really great at it, but at the end of the day if you can get 90% of what you need with just some good porcelain, why waste the energy spinning up the GPU?

> 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 it and erase it from the reflog and run gc! I just mean "delete it" the way any one would ever mean that! I can never get it back now!

I think you may enjoy [Nushell](https://www.nushell.sh)

Why not use Windows or macOS then? You don't need to use shells there.

I would prefer not to change the technical aspects of Linux. I actually cherish it.

> One can dream

That was the promise of COBOL. And SQL. And AppleScript. And ABAP. And...

It never works out the way you want it.

See my more generalized CLI helper which does exactly this:

https://github.com/dheera/scripts/blob/master/helpme

Example usage:

    helpme ffmpeg assemble all the .jpg files into an .mp4 timelapse video at 8fps
    helpme zip my-folder into my-zip.tar with compression level 9
    helpme git delete commit 1a4db4c
    ...

https://news.ycombinator.com/item?id=40410637

Same here, I get a 404 from github. The said link is at the bottom of the submitted npmjs page.

yeah me too but npm has the code tab https://www.npmjs.com/package/ezff?activeTab=code

This is why we have fish tab completions. Does exactly that; list of possible commands with contextual help. Fish rules.

You're not wrong, but also there is value in a tool that will behave the same way consistently and has been vetted. I wouldn't be so down on this work.

If you think a developer creating something /they/ thought would be useful (or even just a fun exercise) is a waste of time because there are “better” options already available, then you really are so out of touch with what developing software means that you are in absolutely no position to make such judgment.

i figure out the niche ffmpeg commands various chain filters, etc then expose them from my python cli tool with words similar to what this gentleman above has done.

If one has fewer such commands its as simple as just bash aliases and just adding it to ~/.bashrc

alias convertmkvtomp4='ffmpeg command'

then just run it anytime with just that alias phrase i use ffmpeg a lot so i have my own dedicated cli snippet tool for me, to quickly build out complex pipeline in easier language

the best part is i have --dry-run then exposes the flow + explicit commands being used at each step, if i need details on whats happening and verbose output at each step

I have a text file with some common commands, so no tools needed.

But yea ffmpeg is awesome software, one of the great oss projects imo. working with video is hellish and it makes it possible.

I agree. Apart from having to use npm (and its package repository being susceptible to security issues), I’d prefer something a lot simpler. Could’ve been a Rust program or a Go program (a single executable) that could be built locally or installed (using several different methods and offering a choice).

That ship sailed some time ago.

MP4 is container, not format, so if you have unsupported format packed into MP4 container it won’t be played. Example is trying to play AV1 video codec on devices with M2 chip or older. It won’t play. But it will play on devices with M3 chip and newer. Easiest solution is to use other player so that you can watch any MP4 file but with software decoding where hardware decoding is not available. Examples of such players are MPV or VLC.

IMHO the de-facto video player for macOS is [IINA](https://iina.io/).

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.

vlc

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

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

Good point, "mb" as used in the linked example would mean "millibit", which is almost certainly not what they meant.