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.
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.
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.
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.
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?
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.
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.)
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.
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.)
> 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.)
> 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.
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 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.
> 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.
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.
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.
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 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).
> 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.
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.
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
- 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"
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.
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.
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?
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.
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).
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.
>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.
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
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.
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
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).
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.
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.
This seems like a glib one liner but I do think it is profoundly insightful as to how some people approach thinking about LLMs.
It is almost like there is hardwiring in our brains that makes us instinctively correlate language generation with intelligence and people cannot separate the two.
It would be like if for the first calculators ever produced instead of responding with 8 to the input 4 + 4 = printed out "Great question! The answer to your question is 7.98" and that resulted in a slew of people proclaiming the arrival of AGI (or, more seriously, the ELIZA Effect is a thing).
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."
I agree apart from the learning part. The thing is unless you have some very specific needs where you need to use ffmpeg a lot, there’s just no need to learn this stuff. If I have to touch it once a year I have much better things to spend my time learning than ffmpeg command
Agreed. I have a bunch of little command-line apps that I use 0.3 to 3 times a year* and I'm never going to memorize the commands or syntax for those. I'll be happy to remember the names of these tools, so I can actually find them on my own computer.
* - Just a few days ago I used ImageMagick for the first time in at least three years. I downloaded it just to find that I already had it installed.
The thing about ffmpeg is there's no substitute for learning. It's pretty common that something simple like "ff convert" simply doesn't work and you have to learn about resolution, color space, profiles, or container formats. An LLM can help but earlier this year I spent a lot of time looking at these sorts of edge cases, and I can easily make any LLM wildly hallucinate by asking questions about how to use ffmpeg to handle particular files.
Do most devs even look at the source code for packages they install? Or the compiled machine code? I think of this as just a higher level of abstraction. Confirm it works and not worry about the details of how it works
For the kinds of things you’d need to reach for an LLM, there’s no way to trust that it actually generated what you actually asked for. You could ask it to write a bunch of tests, but you still need to read the tests.
It isn’t fair to say “since I don’t read the source of the libraries I install that are written by humans, I don’t need to read the output of an llm; it’s a higher level of abstraction” for two reasons:
1. Most Libraries worth using have already been proven by being used in actual projects. If you can see that a project has lots of bug fixes, you know it’s better than raw code. Most bugs don’t show up unless code gets put through its paces.
2. Actual humans have actual problems that they’re willing to solve to a high degree of fidelity. This is essentially saying that humans have both a massive context window and an even more massive ability to prioritize important things that are implicit. LLMs can’t prioritize like humans because they don’t have experiences.
> You can’t verify LLM’s output. And thus, any form of trust is faith, not rational logic.
Well, you can verify an LLM's output all sorts of ways.
But even if you couldn't, its still very rational to be judicious with how you use your time and attention. If I spent a few hours going through the ffmpeg documentation I could probably learn it better than chatgpt. But, its a judgement call whether its better to spend 5 minutes getting chatgpt to generate an ffmpeg command (with some error rate) or spend 2 hours doing it myself (with maybe a lower error rate).
Which is a better use of my time depends on lots of factors. How much I care. How important it is. How often that knowledge will be useful in the future. And so on. If I worked in a hollywood production studio, I'd probably spend the 2 hours (and many more). But if I just reach for ffmpeg once a year, the small% error rate from chatgpt's invocations might be fine.
Your time and attention are incredibly limited resources. Its very rational to spend them sparingly.
I don't install 3rd party dependencies if I can avoid them. Why? Because although someone could have verified them, there's no guarantee that anybody actually did, and this difference has been exploited by attackers often enough to get its own name, a "supply-chain attack".
With an LLM’s output, it is short enough that I can* put in the effort to make sure it's not obliviously malicious. Then I save the output as an artefact.
* and I do put in this effort, unless I'm deliberately experimenting with vibe coding to see what the SOTA is.
> Because although someone could have verified them, there's no guarantee that anybody actually did
In the case of npm and the like, I don't trust them because they are actually using insecure procedures, which is proven to be so. And the vectors of attacks are well known. But I do trust Debian and the binaries they provide as the risks are for the Debian infrastructure to be compromised, malicious code in in the original source, and cryptographic failures. All threes are possibles, but there's more risk of bodily harm to myself that them happening.
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?
Because FFmpeg is a swiss army knife with a million blades and I don't think any easy interface is really going to do the job well. It's a great LLM use case.
But you only need to find the correct tool once and mark it in some way. Aka write a wrapper script, jot down some notes. You are acting like you’re forced to use the cli each time.
One can do that with LLM as well. Honestly, I almost always just save the command if I think I am going to use it later. Also, I can just look back at the chat history.
I know everybody uses a subscription for these things, but doesn't it at least feel expensive to use an LLM like this? Like turning on the oven to heat up a single slice of pizza.
No, LLMs are extremely useful for dealing with ffmpeg. Also I don't think they're sufficient, they get confused too easily and ffmpeg is extremely confusing.
Because the porcelain is purpose built for a specific use case. If you need something outside of what its author intended, you'll need to get your hands dirty.
And, realistically, compute and power is cheap for getting help with one-off CLI commands.
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 1a4db4c
convert ./video.mp4 and ./audio.mp3 into ./out.mp4
merge ./video.mp4 and ./audio.mp3 to ./out.mp4 without re-encoding
And add amazing autocomplete, while allowing as many wordings as possible. No need for LLMs.
> 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!
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.
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
...
This originated from an ffmpeg wrapper I wrote but then realized it could be used for all commands:
The github repo link from the npm page doesn't work, so I guess the author had second thoughts.
I was just fighting ffmpeg earlier today, or rather Gemini and Claude were fighting it. Task: create a video that is a pan across a photo, followed by a scale/zoom.
Probably easy for some people, but I had no clue and the LLMs weren't doing that well either. Things took a turn for the better when I asked Gemini for an alternative tool.
Again, the LLM did the work, but it was able to do so. Since Vapoursynth is driven by python scripts (though with the extension .vpy), it was easy for me to make adjustments.
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.
LLMs are a great interface for ffmpeg. Sometimes it takes 2-3 attempts/fixes ("The subtitles in the video your command generated are offset: i see the subtitles from the beginning of the movie but the video is cut from the middle of the movie as requested, fix the command") but it generally creates complex commands much more quickly than manual work (reading the man page, crafting the command, debugging it) would.
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
Yeah, no, that's a pale imitation that only addresses the one specific example given. But, like, how would you even know what target formats are supported? Break the flow and look it up or simply read the drop-down list?
The free type-any-text interface with poor helpers is the worst in accessibility
Which format is the default if no argument is given?
Or more complicated contextual knowledge - if you cut 1sec of a video file, does fish autocomplete to tell you whether the video is reencoded or cut (otherwise) losslessly
the flow that doesn't require you to open a different tab or cancel a command to `man` your way through dozens of poorly searchable pages of documentation, but allows you to continue translating what you want in your mind into the interface command with delay potentially subsecond interrupts
Is there kind of rewards for speed running typing ffmpeg flags? Like an advent of ffmpeg?
I know what I want to do, I don't know how it's being done, but there's a wealth of information that is very accessible. So I just read it.
It's very easy to type `apropos ffmpeg`. And even if you typed `man ffmpeg`, if you go to the end, you will find related manuals name for more information. And you can always use the pager (`less` in most case) facility for quick search.
I believe that a lot of frustration comes from people unwilling to learn the conceptual basis of the tools they are using.
What's the reward for trivializing real issues and coming up with broken "solutions"?
> It's very easy to type `apropos ffmpeg`
No it's not. First, that's not a Windows command, so right off the bat you've cut off the largest OS.
Second, your command is naively empty and it's telling that you've given it instead of an actual search query because you wouldn't be able to come up with a great one right away that would result in the correct result at the top - while the correct resuls is "hardcoded" in the field type in the UI.
So yeah, go on, find that perfect query and then explain why you think every single user should be able to do the same quickly. Then you can think about how justified your other beliefs are about basic workflow issues you don't understand
> What's the reward for trivializing real issues and coming up with broken "solutions"
Then any solutions is broken in this way. Even my bluetooth speaker comes with a manual. Not reading it and saying the speaker is broken, because you can't figure how to connect is pure delusion. Same as not reading ffmpeg manual and expecting to know how to use it.
> First, that's not a Windows command, so right off the bat you've cut off the largest OS.
ffmpeg on Window is so far the beaten path that it may as well be in Mordor. I would gladly bet that someone that knows how to run ffmpeg on windows also knows how to find the documentation for it.
> So yeah, go on, find that perfect query
Why would I find the perfect query? Do you go in the library and then find the correct line of the correct book in one go? Or do you consult the list of books of books for a theme, select a few candidates, consult their index, and then read the pages?
Then all of that is left to do is to note down the reference if you need to consult the book again (no need to remember everything).
Nope, you're just doing the same thing - purposefully ignoring the issue to make your non-solution comparable...
> Even my bluetooth speaker comes with a manual.
... in this case - the length and scope of the manual. First, you can operate the speaker without the manual or with just a single read of the manual- so spend a few seconds to learn how to pair (but you might not even need that as "hold to pair" might be something you remember from other devices), then the power/volume buttons require no manual because you've operated such buttons your whole life.
> Same as not reading ffmpeg manual
Of course it's not the same, the ffmpeg manual isn't a tiny page of 5 items, and no other apps will help you learn the peculiarities of ffmpeg. Also, the whole point of intuitive UI with "typed info" is that you don't need to read that huge manual to do the basics as you can simply follow the structure laid out by someone more knowledgeable
> ffmpeg on Window is so far the beaten path that it may as well be in Mordor. I would gladly bet that someone that knows how to run ffmpeg on windows also knows how to find the documentation for it.
Who would take that irrelevant bet? The issue isn't in finding! the manual!
> Why would I find the perfect query?
To prove that your solution works. I know it doesn't and challenge you to prove otherwise. Your suggestion is worse than asking users to Google, because at least there users will likely get the correct top result in a few tries for common needs
> Do you go in the library and then find the correct line of the correct book in one go?
No, I open an app and pick the correct format from the drop-down menu correctly in one go
> Or do you consult the list of books of books for a theme, select a few candidates, consult their index, and then read the pages?
Oh man, even in your fantasies you can't come up with a good workflow! No wonder you're fine suggesting everyone wastes a lot of time aproposing empty queries
If you take the set of possible ffmpeg invocations, it's very huge. Yes, it's possible to create some kind of wrapper that serve some common cases. And there are many of such wrappers or alternative tools like Xld (macOS) or Handbrake. But when you do need to use ffmpeg, that means that such wrapper is unfit for some reason or another. And in that case, it's not that much of an effort to read the manual which is very comprehensive.
It's the same with video viewers or music players. Often the default app of the OS is enough and they are very intuitive. But sometimes you need a bit more control and that's when using something like vlc or mpv which their extensive filter capabilities (which requires to have the doc at hand) is mandatory.
ffmpeg interface is ok for what it does. Any of your suggestion would be complex to implement if it aims to support the whole feature set of ffmpeg.
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.
It is a bit of a catch-22, a plain english wrapper opens up the tool to be more widely used by novices, but also prevents those novices from actually learning the tool.
Nothing, but after becoming reliant on an LLM they may simply become overwhelmed and give up once they outgrow it's capabilities. I've seen this happen to several people I know.
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.
Love the simplification of ffmpeg flags. I noticed some comments about Node.js dependencies. Are there plans to make this a standalone binary for faster server-side processing?
This is extremely sexy and represents a great trade off where the ergonomics can be improved without sacrificing the incredible investments in a high performance library.
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
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.
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).
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
No AI is appealing but there is the cliff problem. If there is one small thing the mini language can't handle, the user would have no chance solving it themselves. They might as well start with an LLM solution first.
One workaround is that when there is syntax error, let user optionally switch to LLM?
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.
I actually just use Claude code. “Stabilize the video x.mp4 and keep my daughter Astra as the subject. Convert it to a GIF that is under a megabyte”. It does a great job.
It will sample images from the video then go crop the video to that, stabilize if required, and then make me an optimized GIF that I can put in my weekly journal.
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
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.
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.
Yes, VLC works fine for playing. The user wanted to edit some mp4 videos with iMovie (vs ffmpeg).
I think it was an M4 Mac. Does iMovie need a codec pack? I know some PC OEMs don't ship an h.265 codec, pointing users to a $0.99 download. Thought Mac would include it, being aimed at content creators. Hoping for a cheaper solution than Adobe Premiere.
H265 is different codec, and exactly because of that license fee both VP9 and AV1 exist. Apple was hiding VP9 support for long time now and AV1 support is now official.
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.
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
FFMPEG is so goddamn cool, I was doing a mod for warcraft 3 where I restore the original Frozen Throne UI and one (especially useful before, Blizzard now restored the classic WEBM models so that part is now outdated but the blue buttons and other stuff are still relevant).
And virtually every method was failing in decoloring the "chains".webm video that Reforged has on the bottom corners (by default it has a very rusty feeling that fits reign of chaos more than the frozen throne)... but FFMPEG via commands did it perfectly fine, extremely easily by doing it frame by frame, actually incredible that this software is completely free.
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”?
How much is “1 slow down”? How many “slow down” are in the movie where you want twice as many of them? Doesn’t make sense does it? So how can something be slowed by 2x? That also doesn’t make sense.
I know what is trying to be said. I know what is meant. Please just say it right. Things like throw us autistic people for a freaking loop, man. This really rustles our jimmies.
Language is for communicating. If we aren’t all on the same page about how to say stuff, you spend time typing and talking and writing and reading and your message doesn’t make it across the interpersonal language barrier.
I don’t want to see people wasting their time trying to communicate good ideas with bad phrasing. I want people to be able to say what they mean and move on.
I also don’t want to nitpick things like this, but I don’t want phrases like “slow down by 2x” to be considered normal English, either, because they aren’t.
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."
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?
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.
> 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.
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.
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.
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?
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.
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
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.
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.)
> 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.)
Just do a best-guess list. Or do a survey. Or just scrape the most common features used across Github repos.
> 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.
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 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.
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.
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...
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.
> 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.
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.
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.
> 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).
> 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.
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?
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.
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”.
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
- 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.
“It’s really not that hard”, well a lot of people have better things to do than remember parameters to commands we barely use.
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?
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.
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.
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.
> 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.
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.
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
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): zeroBut 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
When converting video to gif, I always use palettegen, e.g.
See also: this blog post from 10 years ago [1][1] https://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html
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
Sometimes English is not swell as a specification format.
> ff trim video.mp4 from 0:30 to 1:00
Does this mean I keep the indicated section or does it mean I throw it away?
And many other examples of English sucking at ambiguity when precision matters. Maybe this is a corollary of " naming things is hard ".
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.
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
The confusion was thinking that language is the same thing as intelligence.
You and me are great examples of that. We are both extremely stupid and yet we can speak.
Can attest.
This seems like a glib one liner but I do think it is profoundly insightful as to how some people approach thinking about LLMs.
It is almost like there is hardwiring in our brains that makes us instinctively correlate language generation with intelligence and people cannot separate the two.
It would be like if for the first calculators ever produced instead of responding with 8 to the input 4 + 4 = printed out "Great question! The answer to your question is 7.98" and that resulted in a slew of people proclaiming the arrival of AGI (or, more seriously, the ELIZA Effect is a thing).
And reddit, that bastion of human achievement.
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.
I agree apart from the learning part. The thing is unless you have some very specific needs where you need to use ffmpeg a lot, there’s just no need to learn this stuff. If I have to touch it once a year I have much better things to spend my time learning than ffmpeg command
Agreed. I have a bunch of little command-line apps that I use 0.3 to 3 times a year* and I'm never going to memorize the commands or syntax for those. I'll be happy to remember the names of these tools, so I can actually find them on my own computer.
* - Just a few days ago I used ImageMagick for the first time in at least three years. I downloaded it just to find that I already had it installed.
There is no universe where I would like to spend brain power on learning ffmpeg commands by heart.
No one learns those. What people do is just learning the UX of the cli and the terminology (codec, opus, bitrate, sampling,…)
The thing about ffmpeg is there's no substitute for learning. It's pretty common that something simple like "ff convert" simply doesn't work and you have to learn about resolution, color space, profiles, or container formats. An LLM can help but earlier this year I spent a lot of time looking at these sorts of edge cases, and I can easily make any LLM wildly hallucinate by asking questions about how to use ffmpeg to handle particular files.
Do most devs even look at the source code for packages they install? Or the compiled machine code? I think of this as just a higher level of abstraction. Confirm it works and not worry about the details of how it works
For the kinds of things you’d need to reach for an LLM, there’s no way to trust that it actually generated what you actually asked for. You could ask it to write a bunch of tests, but you still need to read the tests.
It isn’t fair to say “since I don’t read the source of the libraries I install that are written by humans, I don’t need to read the output of an llm; it’s a higher level of abstraction” for two reasons:
1. Most Libraries worth using have already been proven by being used in actual projects. If you can see that a project has lots of bug fixes, you know it’s better than raw code. Most bugs don’t show up unless code gets put through its paces.
2. Actual humans have actual problems that they’re willing to solve to a high degree of fidelity. This is essentially saying that humans have both a massive context window and an even more massive ability to prioritize important things that are implicit. LLMs can’t prioritize like humans because they don’t have experiences.
I don’t because I trust the process to get the artifacts. Why? Because it’s easy to replicate and verify. Just like how proof works in math.
You can’t verify LLM’s output. And thus, any form of trust is faith, not rational logic.
> You can’t verify LLM’s output. And thus, any form of trust is faith, not rational logic.
Well, you can verify an LLM's output all sorts of ways.
But even if you couldn't, its still very rational to be judicious with how you use your time and attention. If I spent a few hours going through the ffmpeg documentation I could probably learn it better than chatgpt. But, its a judgement call whether its better to spend 5 minutes getting chatgpt to generate an ffmpeg command (with some error rate) or spend 2 hours doing it myself (with maybe a lower error rate).
Which is a better use of my time depends on lots of factors. How much I care. How important it is. How often that knowledge will be useful in the future. And so on. If I worked in a hollywood production studio, I'd probably spend the 2 hours (and many more). But if I just reach for ffmpeg once a year, the small% error rate from chatgpt's invocations might be fine.
Your time and attention are incredibly limited resources. Its very rational to spend them sparingly.
I don't install 3rd party dependencies if I can avoid them. Why? Because although someone could have verified them, there's no guarantee that anybody actually did, and this difference has been exploited by attackers often enough to get its own name, a "supply-chain attack".
With an LLM’s output, it is short enough that I can* put in the effort to make sure it's not obliviously malicious. Then I save the output as an artefact.
* and I do put in this effort, unless I'm deliberately experimenting with vibe coding to see what the SOTA is.
> Because although someone could have verified them, there's no guarantee that anybody actually did
In the case of npm and the like, I don't trust them because they are actually using insecure procedures, which is proven to be so. And the vectors of attacks are well known. But I do trust Debian and the binaries they provide as the risks are for the Debian infrastructure to be compromised, malicious code in in the original source, and cryptographic failures. All threes are possibles, but there's more risk of bodily harm to myself that them happening.
It you stretch it little further, those formal directives also include language and vocabulary of a particular domain (legalese, etc…).
The "provided" isn't provided, of course, especially the learning part, that's not what you'd turn to AI for vs more reliable tutoring alternatives
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.
Just tried it and got this, is it correct?
> Write an ffmpeg command that implements the "bounce" effect: play from 0:00 to 0:03, then backwards from 0:03 to 0:00, then repeat 5 times.
Thanks, but no luck. I tested it on a 3 second video, and got a 6 second video. I.e. it bounced 1 time, not 5 times.
Maybe this should be an AI reasoning test.
Here is what eventually worked, iirc (10 bounces):
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?
Requiring the installation of a massive kraken like node.js and npm to run a commandline executable hardly screams efficiency...
That's a deficiency with this particular implementation, not an inherent disadvantage to the method
Because FFmpeg is a swiss army knife with a million blades and I don't think any easy interface is really going to do the job well. It's a great LLM use case.
But you only need to find the correct tool once and mark it in some way. Aka write a wrapper script, jot down some notes. You are acting like you’re forced to use the cli each time.
One can do that with LLM as well. Honestly, I almost always just save the command if I think I am going to use it later. Also, I can just look back at the chat history.
I know everybody uses a subscription for these things, but doesn't it at least feel expensive to use an LLM like this? Like turning on the oven to heat up a single slice of pizza.
No, LLMs are extremely useful for dealing with ffmpeg. Also I don't think they're sufficient, they get confused too easily and ffmpeg is extremely confusing.
ChatGPTs free tier is just fine for me.
Nice
Because getting 90% might not be good enough, and the effort you need to expend to reach 97% costs much more than the energy the GPU uses.
Because the porcelain is purpose built for a specific use case. If you need something outside of what its author intended, you'll need to get your hands dirty.
And, realistically, compute and power is cheap for getting help with one-off CLI commands.
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.
And add amazing autocomplete, while allowing as many wordings as possible. No need for LLMs.One can dream.
> 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!
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.
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:
This originated from an ffmpeg wrapper I wrote but then realized it could be used for all commands:https://news.ycombinator.com/item?id=40410637
Can't access the githup repo https://github.com/josharsh/ezff
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
is this better than just ask any llm cli tool (warp, codex, gemini, claude code, etc.) to generate ffmpeg command for you?
The github repo link from the npm page doesn't work, so I guess the author had second thoughts.
I was just fighting ffmpeg earlier today, or rather Gemini and Claude were fighting it. Task: create a video that is a pan across a photo, followed by a scale/zoom.
Probably easy for some people, but I had no clue and the LLMs weren't doing that well either. Things took a turn for the better when I asked Gemini for an alternative tool.
The answer was Vapoursynth - https://www.vapoursynth.com/doc/introduction.html#introducti...
Again, the LLM did the work, but it was able to do so. Since Vapoursynth is driven by python scripts (though with the extension .vpy), it was easy for me to make adjustments.
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.
> 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
LLMs are a great interface for ffmpeg. Sometimes it takes 2-3 attempts/fixes ("The subtitles in the video your command generated are offset: i see the subtitles from the beginning of the movie but the video is cut from the middle of the movie as requested, fix the command") but it generally creates complex commands much more quickly than manual work (reading the man page, crafting the command, debugging it) would.
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
This is why we have fish tab completions. Does exactly that; list of possible commands with contextual help. Fish rules.
Yeah, no, that's a pale imitation that only addresses the one specific example given. But, like, how would you even know what target formats are supported? Break the flow and look it up or simply read the drop-down list? The free type-any-text interface with poor helpers is the worst in accessibility
Which format is the default if no argument is given?
Or more complicated contextual knowledge - if you cut 1sec of a video file, does fish autocomplete to tell you whether the video is reencoded or cut (otherwise) losslessly
Also, what does fish complete to on Windows?
Which flow is being broken here? Especially when the information is easily accessible with `man`.
the flow that doesn't require you to open a different tab or cancel a command to `man` your way through dozens of poorly searchable pages of documentation, but allows you to continue translating what you want in your mind into the interface command with delay potentially subsecond interrupts
Is there kind of rewards for speed running typing ffmpeg flags? Like an advent of ffmpeg?
I know what I want to do, I don't know how it's being done, but there's a wealth of information that is very accessible. So I just read it.
It's very easy to type `apropos ffmpeg`. And even if you typed `man ffmpeg`, if you go to the end, you will find related manuals name for more information. And you can always use the pager (`less` in most case) facility for quick search.
I believe that a lot of frustration comes from people unwilling to learn the conceptual basis of the tools they are using.
What's the reward for trivializing real issues and coming up with broken "solutions"?
> It's very easy to type `apropos ffmpeg`
No it's not. First, that's not a Windows command, so right off the bat you've cut off the largest OS. Second, your command is naively empty and it's telling that you've given it instead of an actual search query because you wouldn't be able to come up with a great one right away that would result in the correct result at the top - while the correct resuls is "hardcoded" in the field type in the UI. So yeah, go on, find that perfect query and then explain why you think every single user should be able to do the same quickly. Then you can think about how justified your other beliefs are about basic workflow issues you don't understand
> What's the reward for trivializing real issues and coming up with broken "solutions"
Then any solutions is broken in this way. Even my bluetooth speaker comes with a manual. Not reading it and saying the speaker is broken, because you can't figure how to connect is pure delusion. Same as not reading ffmpeg manual and expecting to know how to use it.
> First, that's not a Windows command, so right off the bat you've cut off the largest OS.
ffmpeg on Window is so far the beaten path that it may as well be in Mordor. I would gladly bet that someone that knows how to run ffmpeg on windows also knows how to find the documentation for it.
> So yeah, go on, find that perfect query
Why would I find the perfect query? Do you go in the library and then find the correct line of the correct book in one go? Or do you consult the list of books of books for a theme, select a few candidates, consult their index, and then read the pages?
Then all of that is left to do is to note down the reference if you need to consult the book again (no need to remember everything).
> Then any solutions is broken in this way.
Nope, you're just doing the same thing - purposefully ignoring the issue to make your non-solution comparable...
> Even my bluetooth speaker comes with a manual.
... in this case - the length and scope of the manual. First, you can operate the speaker without the manual or with just a single read of the manual- so spend a few seconds to learn how to pair (but you might not even need that as "hold to pair" might be something you remember from other devices), then the power/volume buttons require no manual because you've operated such buttons your whole life.
> Same as not reading ffmpeg manual
Of course it's not the same, the ffmpeg manual isn't a tiny page of 5 items, and no other apps will help you learn the peculiarities of ffmpeg. Also, the whole point of intuitive UI with "typed info" is that you don't need to read that huge manual to do the basics as you can simply follow the structure laid out by someone more knowledgeable
> ffmpeg on Window is so far the beaten path that it may as well be in Mordor. I would gladly bet that someone that knows how to run ffmpeg on windows also knows how to find the documentation for it.
Who would take that irrelevant bet? The issue isn't in finding! the manual!
> Why would I find the perfect query?
To prove that your solution works. I know it doesn't and challenge you to prove otherwise. Your suggestion is worse than asking users to Google, because at least there users will likely get the correct top result in a few tries for common needs
> Do you go in the library and then find the correct line of the correct book in one go?
No, I open an app and pick the correct format from the drop-down menu correctly in one go
> Or do you consult the list of books of books for a theme, select a few candidates, consult their index, and then read the pages?
Oh man, even in your fantasies you can't come up with a good workflow! No wonder you're fine suggesting everyone wastes a lot of time aproposing empty queries
If you take the set of possible ffmpeg invocations, it's very huge. Yes, it's possible to create some kind of wrapper that serve some common cases. And there are many of such wrappers or alternative tools like Xld (macOS) or Handbrake. But when you do need to use ffmpeg, that means that such wrapper is unfit for some reason or another. And in that case, it's not that much of an effort to read the manual which is very comprehensive.
It's the same with video viewers or music players. Often the default app of the OS is enough and they are very intuitive. But sometimes you need a bit more control and that's when using something like vlc or mpv which their extensive filter capabilities (which requires to have the doc at hand) is mandatory.
ffmpeg interface is ok for what it does. Any of your suggestion would be complex to implement if it aims to support the whole feature set of ffmpeg.
"why would one solve the problem with one drop-down menu if you can solve it with 20 minutes of browsing walls of text"
lol
npm? Have we learned nothing from the weekly node/npm security breaches? Not putting that hot mess anywhere near my dev box, thanks.
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.
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.
It is a bit of a catch-22, a plain english wrapper opens up the tool to be more widely used by novices, but also prevents those novices from actually learning the tool.
Not really, how are they prevented from using the manual or the copious amounts of examples out there?
Memorising command line options beyond the absolute basics has rarely been helpful to me. And I use FreeBSD, where arcane commands are plentiful.
Nothing, but after becoming reliant on an LLM they may simply become overwhelmed and give up once they outgrow it's capabilities. I've seen this happen to several people I know.
It's not so much being down on the work, as it is being down on 30 years of keyboard junkies proclaiming "Plain English" interfaces.
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.
Somehow it seems ffmpeg has become the "Can it run crysis" of UX design
Love the simplification of ffmpeg flags. I noticed some comments about Node.js dependencies. Are there plans to make this a standalone binary for faster server-side processing?
This is extremely sexy and represents a great trade off where the ergonomics can be improved without sacrificing the incredible investments in a high performance library.
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).
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.
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.
I like the idea, but a CLI utility dependent on Node.js is not a good thing frankly.
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.
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
No AI is appealing but there is the cliff problem. If there is one small thing the mini language can't handle, the user would have no chance solving it themselves. They might as well start with an LLM solution first.
One workaround is that when there is syntax error, let user optionally switch to LLM?
GitHub repo link returns 404.
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.
I actually just use Claude code. “Stabilize the video x.mp4 and keep my daughter Astra as the subject. Convert it to a GIF that is under a megabyte”. It does a great job.
It will sample images from the video then go crop the video to that, stabilize if required, and then make me an optimized GIF that I can put in my weekly journal.
Inspiring! I just asked Cursor to make llmwrap inspired by this, it's like rlwrap (readline wrap) but with LLMs!
https://github.com/sirodoht/llmwrap
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
Where's the public Git repository for this project? The GitHub link on the NPM page seems broken to me.
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?
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.
Yes, VLC works fine for playing. The user wanted to edit some mp4 videos with iMovie (vs ffmpeg).
I think it was an M4 Mac. Does iMovie need a codec pack? I know some PC OEMs don't ship an h.265 codec, pointing users to a $0.99 download. Thought Mac would include it, being aimed at content creators. Hoping for a cheaper solution than Adobe Premiere.
H265 is different codec, and exactly because of that license fee both VP9 and AV1 exist. Apple was hiding VP9 support for long time now and AV1 support is now official.
IMHO the de-facto video player for macOS is [IINA](https://iina.io/).
That exists, but it’s still VLC.
It's based on mpv, not vlc.
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.
Thanks, I can even somewhat remember that. AI gave me args like
"-c:v h264_videotoolbox -b:v 5000k" on macos, it will use hardware encoder.
vlc
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.
I would love to see something like this for OpenSSL
Thanks, will definitely check this out
Has anyone else been avoiding typing FFmpeg commands by using file:// URLs with yt-dlp
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
FFMPEG is so goddamn cool, I was doing a mod for warcraft 3 where I restore the original Frozen Throne UI and one (especially useful before, Blizzard now restored the classic WEBM models so that part is now outdated but the blue buttons and other stuff are still relevant).
And virtually every method was failing in decoloring the "chains".webm video that Reforged has on the bottom corners (by default it has a very rusty feeling that fits reign of chaos more than the frozen throne)... but FFMPEG via commands did it perfectly fine, extremely easily by doing it frame by frame, actually incredible that this software is completely free.
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”?
How much is “1 slow down”? How many “slow down” are in the movie where you want twice as many of them? Doesn’t make sense does it? So how can something be slowed by 2x? That also doesn’t make sense.
I know what is trying to be said. I know what is meant. Please just say it right. Things like throw us autistic people for a freaking loop, man. This really rustles our jimmies.
Language is for communicating. If we aren’t all on the same page about how to say stuff, you spend time typing and talking and writing and reading and your message doesn’t make it across the interpersonal language barrier.
I don’t want to see people wasting their time trying to communicate good ideas with bad phrasing. I want people to be able to say what they mean and move on.
I also don’t want to nitpick things like this, but I don’t want phrases like “slow down by 2x” to be considered normal English, either, because they aren’t.
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”?
There is no need for a wrapper or memorizing syntax in our new llm world.
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?
Uhm... Millibit, Millibyte, Megabit, Megabyte?
Good point, "mb" as used in the linked example would mean "millibit", which is almost certainly not what they meant.
claude cli for ffmpeg is op lol
See also:
https://github.com/dheera/scripts/blob/master/helpme
This evolved from an ffmpeg wrapper I wrote before:https://news.ycombinator.com/item?id=40410637