Hacker News Reader

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

Empathy is really not that hard.

It is that hard for some. Empathy requires actually going out and talking to people. And then listening to them describe their experiences, without editorialising or interrupting.

I've met plenty of engineers who would rather spend 2 weeks programming than spend 5 minutes talking to their users. I used to struggle a lot with this myself when I was younger. Social anxiety isn't easy to overcome.

With so many people lacking emotional intelligence, I would strongly disagree with you.

I would agree with this statement before LLMs. Reading manuals can take time, be messy, and are sometimes hard to understand.

Now, I can simply ask any LLM to write the command, and understand any following issues or questions.

For example, my OS records videos as WEBM. Using the default settings for transforming to MP4 usually fails from a resolution ratio issue. I would be deadlocked using this library.

It really isn't that hard anymore.

Except what if you don’t really grok those ffmpeg flags and the LLM tells you something wrong - how will you know? Or more common, send you down a re-encode rabbit hole when you just needed a simple clipping off the end?

I sometimes use LLMs to generate commands, and it generally works. But a common issue is that it throws in extra options because they are very commonly used - even if they're not necessary or relevant to my actual situation. So if you don't go through and check them all, you get this kind of unchecked cruft in your scripts that may later cause a problem.

ChatGPT is pretty good at generative commands

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

Indeed why not have —tui option and some basic menu? Even a simplified scripting with reasonable API would be better.

I find myself bothering exactly zero times to memorise this obnoxiously long command line. Claude fills in, and I can explore features better. What’s not to like? That I’m getting dumber for not memorising pages of cli args?

Love the project, but as with every Swiss knife this conversation is a thing and relevant. We had similar one reg JQ syntax and I’m truly convinced JQ is wonderful and useful tool. But I’m not gonna bother learning more DSLs…

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 structure (e.g. is itself a shell command), drill down recursively. Ensure that quotes and spaces and special characters always get escaped correctly.

In other words, a general-purpose command-line builder. And while we're at it, be able to save particular "templates" for fast re-use, identifying which values should be editable in the future.

I can't be the first person to think of this, but I've never come across anything like it and don't understand why not. It doesn't require AI or anything. Maybe it's the difficulty involved in creating the metadata for each tool, since man pages aren't machine-readable. But maybe that's where AI can help -- not in the tool itself, but to create the initial database of tool options, that can then be maintained by hand?

(Navi [1] does the templating part, but not the "interactive builder" part.)

[1] https://github.com/denisidoro/navi

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?

Just do a best-guess list. Or do a survey. Or just scrape the most common features used across Github repos.

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

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

The problem is always going to be that everyone has their own way of structuring arguments and providing help text. You could probably do it with PowerShell.

And they change quite frequently, from our POV.

That said, I started wrtiting scripts when I use ffmpeg some time ago. At least then I have a non-zero starting point next time.

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.

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

My ChatGPT history is full of conversations like this.

I have mixed feelings about using chatgpt to write code. But LLMs certainly make an excellent ffmpeg frontend. And you can even ask them to explain all the ffmpeg arguments they used and why they used them.

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

Thank you, this explains my thoughts really well.

Usually when AI hallucinates an option that doesn't exist, the option really should exist. So then I tell it to add it.

Then, several days later, I crawl away from fighting robots in a rabbit hole, and finally get around to doing what I set out to do in the first place....

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.

> Some people just want to use a tool to do a job swiftly. Not everything has to be educational.

> some folks want to use lossless cut

In that case I would encourage you to ruminate on what the following in the post you're replying to means and what the implications are:

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

Depending on the size of the video, the time it would take you to "do the job swiftly" (i.e. not caring about how the tools you are using actually work) might be more than just reading the ffmpeg manual, or at the very least searching for some command examples.

> > some folks want to use lossless cut > In that case I would encourage you to ruminate on what the following in the post you're replying to means and what the implications are:

You may have misunderstood the comment: "lossless cut" is the name of an ffmpeg GUI front end. They're not discussing which exact command line gives lossless results.

The thing is that when a video is being re-encoded, so long as I'm not trying to play games on my computer at the same time, I'm free to go do something else. It does not command any of my attention while its working, whereas sitting and reading the man pages commands my attention absolutely.

As the other person said (and this is my mistake for not capitalizing), Lossless Cut is a popular CLI wrapper for ffmpeg with a (somewhat) intuitive interface. Someone is going to be able to pick up and use that a lot faster than they are ffmpeg. I think a lot of folks forget how daunting most people find using a terminal, yet a lot of those people still want something to do a simple lossless trim of an existing video or some other little tweak. It’s good that they have both options (and more).

Looks like a GUI wrapper in fact, no?

Yes thank you I can get a little clumsy with my acronyms. Downside of not being a proper coder/engineer!

No problem. I only asked because if there were a CLI version I wanted to know about it.

Yes, I am not opposed to ffmpeg wrappers in and of themselves. Some decent ffmpeg wrappers definitely exist. But I argue in my comment above that this specific tool does not have better QoL - again, since it reencodes unconditionally with quality settings that are usually not configurable.

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

Not really sure how else I was supposed to interpret your comment but clarification taken.

> But I argue in my comment above that this specific tool does not have better QoL

For some folks it may be better/more intuitive. It doesn’t hurt anybody by existing.

We all compromise with different tools in our lives in different ways. It just reads to me like an odd axe to grind.

Simply put: What is so bad about the existence of this project?

> Not really sure how else I was supposed to interpret your comment

Yes, that was a bit facetious of me, I apologize for that.

> What is so bad about the existence of this project?

Being very blunt: The fact that it reinforces the extremely common misconception that a) converting between containers like mkv and mp4 will always require reencoding and that b) there is a single way to reencode a video (hence suggesting that there is no "bad" way to reencode a video), seeing as next to no encoding settings are exposed.

I get what you’re saying but at the end of the day you just need to think about how most people use a tool like this. They’re looking for a simple solution to some specific problem and then they’re likely never using it again. They don’t want to deal with a full-on NLE and iMovie or whatever they have stocked is not cutting it. It’s not worth getting bent out of shape about it ultimately. There are tons of people who use ffmpeg as intended in its original form and more or less understand everything that is going on. The reason we have so many wrappers and variations all centered around ffmpeg is because of how useful it is, so it’s clearly here to stay.

I personally use lossless cut more than ffmpeg in the terminal just because I don’t have to really think about it and it can do most of what I need, which is simply removing or attaching things together without re-encoding. I use it maybe once every month or two, because it’s just not something I need to use a ton, so it doesn’t make sense for me to get down and dirty with the original. Ultimately I get what I need and I’m happy!

You are overthinking this way too much, to the point that it is sounding like you are purposefully creating out-of-context problems to justify your way too long rant.

As the kids these days say: just take the L, man.

I completely disagree. The rant is a problem but the complaint about reencoding is quite valid.

It’s a classic “forest for the trees” scenario. The use case 90% of the time for these tools is “I have a format problem and I need something to solve it quickly.” Rarely do they care if it’s lossless or not.

Anyone who knows what lossless vs. lossy means and when it matters knows what tools to look for and what the limitations of each tool are.

The average person can easily understand "the copy looks worse when it could look identical". The issue is not even thinking to check.

And I bet most of them do care, even if it's not caring a lot.

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

Different project, but similar vibe. https://ffstudio.app/

This is awesome, thank you so much for posting it.

I recently went looking for that site since I got into tdarr, and I was sad to see it go. It definitely isn't great for "prod" use, but I find that a GUI listing options makes it easier to understand the thought process behind software.

Kills me that they didn't even bother open sourcing it.

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

You only need to remember the few options you actually need more than once.

“It's really not that hard”

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

I'm not saying it couldn't be better (and I even gave examples), my point is that the drawbacks of such a wrapper outweigh the benefits, at least when it's such an oversimplified one. I've said in other replies how I'd be very interested in e.g. an alternative libav* frontend with better defaults and more consistent argument syntax, but I don't think that this invalidates my criticism of the linked project.

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

Yes, absolutely. Multimedia is complicated.

But my issue with the linked tool is that it does none of the things you mentioned. All it does it make already very easy things even easier. Is it really that much harder to remember `ffmpeg -i inputfile outputfile.ext` than `ff convert inputfile to ext`?

I've explained this in other replies here but I am neither saying that ffmpeg wrappers are automatically bad, nor that ffmpeg cannot be complicated. I am only saying that this specific tool does not really help much.

> Multimedia is complicated.

I mean you saw the code above? It looks like gibberish and regex had a child. Many things in computing are complicated, but doesn’t look like that code. I make my living in media related programming and the code above is messy and extremely hard to read.

And even if you memorized all that, another task that IMO should be simple, you probably haven't also memorized yourself, such as inserting or extracting a thumbnail from a container.

> 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

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

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?

I do, yes. Though that's not really the point, it'd already be enough to know where to look it up.

no the point is that there are some things I've done a hundred times and I never remember it because it's designed in a wildly bad way. ffmpeg, gpg, openssl and git has those things all over the place. Is it -c:v or -v:c? I don't know. used to be -vcodec so it's -v:c now? no it's -c:v I think because they swapped it?

There isn't internal consistency to really hold on to ... it's just a bunch of seemingly independent options.

The biggest problem is open source teams really don't get people on board that focus on customer and product the way commercial software does. This is what we get as a result

> Is it -c:v or -v:c?

Sure, I agree with all of this. Like I said above, the syntax (and, even more, the defaults) isn't great. I'm just arguing that "improving the syntax" should not mean "hiding complexity that should not be hidden", as the linked project does. An alternative ffmpeg frontend (i.e. a new CLI frontend using the libav* libraries like ffmpeg is, not a wrapper for the ffmpeg CLI program) with better syntax and defaults but otherwise similar capabilities would be a very interesting project.

(The answer to your question is that both -vcodec and -c:v are valid, but I imagine that's not the point.)

> The biggest problem is open source teams really don't get people on board that focus on customer and product the way commercial software does.

I believe in this case it may be more of a case of backwards compatibility, with options being added incrementally over time to add what was needed at the moment. Though that's just my guess.

ffmpeg doesn't go away. it's still there. people can use tig and git, having something that isn't insane can live in harmony with the other thing.