Comment by qbow883

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

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.

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

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?

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

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

- dealing with some HDR or high gamut thing I can't really remember that can result from screen recording on macos using some method I was using at some point

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

> 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 really not that hard”, well a lot of people have better things to do than remember parameters to commands we barely use.

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 without deep poring over docs and tons of trial and error, or using claude (which is pretty much what I do nowadays): zero

I think there's a reason these wrappers keep appearing - different tools for different use cases. Not everyone needs to become an ffmpeg expert, especially if they only need it occasionally.

For example this one is also ffmpeg wrapper, https://lorem.video and built for devs and QAs who just need a quick placeholder video without diving into ffmpeg syntax. It's optimized for that narrow use case to generate test video by typing a URL.

Nothing wrong with learning ffmpeg properly if you use it regularly, but purpose built tools have their place too.

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

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

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

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?

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.

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

[dead]

[dead]