8 ms·

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

by qbow883 9mo ago

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.

Forgeties79 9mo ago
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.
- hnarn 9mo ago
  > 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.
  - wpm 9mo ago
    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.
  - foodevl 9mo ago
    > > 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.
  - Forgeties79 9mo ago
    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).
deleted 9mo ago
[deleted]
e-Minguez 9mo ago
If you use it from time to time it would be very challenging to remember the million of different options ffmpeg has.
- account42 8mo ago
  You only need to remember the few options you actually need more than once.
kristopolous 9mo ago
so you know how to swap audio with -map without having to look it up?
- qbow883 9mo ago
  I do, yes. Though that's not really the point, it'd already be enough to know where to look it up.
  - kristopolous 9mo ago
    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
    - qbow883 9mo ago
      > 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.
      - 9mo ago
juujian 9mo ago
Yes, I use ffmpeg about once a year, in about 350 years I really ought to have all the syntax figure out.
WhitneyLand 9mo ago
“It's really not that hard” I’m going to guess your job does not involve much UX design?
- qbow883 9mo ago
  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.
- christstopit 9mo ago
  [dead]
fleroviumna 9mo ago
[dead]
Tempest1981 9mo ago
> 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.
- there_is_try 9mo ago
  Empathy is really not that hard.
  - josephg 9mo ago
    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.
  - ranger_danger 9mo ago
    With so many people lacking emotional intelligence, I would strongly disagree with you.
- MattDaEskimo 9mo ago
  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.
  - russfink 9mo ago
    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?
ninalanyon 9mo ago
> 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.
- larodi 9mo ago
  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…
- crazygringo 9mo ago
  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 https://github.com/denisidoro/navi
christstopit 9mo ago
[dead]
Gud 9mo ago
“It’s really not that hard”, well a lot of people have better things to do than remember parameters to commands we barely use.
BeetleB 9mo ago
> 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.
deleted 9mo ago
[deleted]
mhuffman 9mo ago
>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/6e2d456a9897f55025e25035478a3a50 https://gist.github.com/tayvano/6e2d456a9897f55025e25035478a...
ubercow13 9mo ago
Totally disagree, I have a wrapper I wrote myself for converting things, often for sharing the odd little clip online or such. It produces a complex command that is not easy to just type out, that does multiple things to maximise compatibility like - making sure pixel are square while resizing if the video resolution is too large ("scale=w=if(gt(iw*sar\\,ih)\\,min(ceil(iw*sar/2)*2\\,{})\\,ceil(iw*sar*min(ih\\,{})/ih/2)*2):h=if(gt(ih\\,iw*sar)\\,min(ceil(ih/2)*2\\,{})\\,ceil(ih*min(iw*sar\\,{})/iw/sar/2)\*2):out_range=limited,zscale,setsar=1") - dealing with some HDR or high gamut thing I can't really remember that can result from screen recording on macos using some method I was using at some point - setting this one tag on hevc files that macos needs for them to be recognised as hevc but isn't set by default - calculating the target bitrate if I need a specific filesize and verifying the encode actually hit that size and retrying if not (doesn't always work first time with certain hardware encoders even if they have a target or max bitrate parameter) - dealing with 2-pass encoding which is fiddly and requires two separate commands and the parameters are codec specific - correctly activating hardware encoding for various codecs - etc And this is just for the basic task of "make this into a simple mp4"
- qbow883 9mo ago
  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.
  - plufz 9mo ago
    > 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.
- ranger_danger 9mo ago
zzzeek 9mo ago
sure here's a command that a program I wrote to record my practicing and produce different mixes uses /usr/bin/ffmpeg -i "/path/to/musicfile.mp3" -i "/path/to/covertune.mp3" \ -filter_complex [1:a]volume=1[track1];[0a][track1]amix=normalize=false[output] \ -map [output] -b:a 192k -metadata title=15:17:01 -metadata "artist=Me, 2025" \ -metadata album=2025-12-23 "/path/to/file.mix.mp3" chance of my coming up with that without deep poring over docs and tons of trial and error, or using claude (which is pretty much what I do nowadays): zero
- qbow883 9mo ago
  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.
  - zzzeek 9mo ago
    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
koyote 9mo ago
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...).
- qbow883 9mo ago
  Thank you, this explains my thoughts really well.
- CamperBob2 9mo ago
  Usually when AI hallucinates an option that doesn't exist, the option really should exist. So then I tell it to add it. Then, several days later, I crawl away from fighting robots in a rabbit hole, and finally get around to doing what I set out to do in the first place....
deleted 9mo ago
[deleted]
msla 9mo ago
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.)
zahlman 9mo ago
> 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).
C4K3 9mo ago
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.guide/graph/demo https://web.archive.org/web/20230131140736/https://ffmpeg.gu...
- robertheadley 9mo ago
  Different project, but similar vibe. https://ffstudio.app/ https://ffstudio.app/
  - zymhan 9mo ago
    This is awesome, thank you so much for posting it.
- zymhan 9mo ago
  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.
stevage 9mo ago
> 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.
tombert 9mo ago
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.
jayd16 9mo ago
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.
UqWBcuFx6NV4r 9mo ago
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”.
memset 9mo ago
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?
agentifysh 9mo ago
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.
guntis_dev 9mo ago
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 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.

by qbow883 9mo ago

Forgeties79 9mo ago

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.

hnarn 9mo ago
> 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.
- wpm 9mo ago
  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.
- foodevl 9mo ago
  > > 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.
- Forgeties79 9mo ago
  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).

deleted 9mo ago

[deleted]

e-Minguez 9mo ago

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

account42 8mo ago
You only need to remember the few options you actually need more than once.

kristopolous 9mo ago

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

qbow883 9mo ago
I do, yes. Though that's not really the point, it'd already be enough to know where to look it up.
- kristopolous 9mo ago
  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
  - qbow883 9mo ago
    > 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.
    - 9mo ago

juujian 9mo ago

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

WhitneyLand 9mo ago

“It's really not that hard” I’m going to guess your job does not involve much UX design?

qbow883 9mo ago
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.
christstopit 9mo ago
[dead]

fleroviumna 9mo ago

[dead]

Tempest1981 9mo ago

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

there_is_try 9mo ago
Empathy is really not that hard.
- josephg 9mo ago
  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.
- ranger_danger 9mo ago
  With so many people lacking emotional intelligence, I would strongly disagree with you.
MattDaEskimo 9mo ago
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.
- russfink 9mo ago
  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?

ninalanyon 9mo ago

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

larodi 9mo ago
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…
crazygringo 9mo ago
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 https://github.com/denisidoro/navi

christstopit 9mo ago

[dead]

Gud 9mo ago

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

BeetleB 9mo ago

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

deleted 9mo ago

[deleted]

mhuffman 9mo ago

>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/6e2d456a9897f55025e25035478a3a50 https://gist.github.com/tayvano/6e2d456a9897f55025e25035478a...

ubercow13 9mo ago

Totally disagree, I have a wrapper I wrote myself for converting things, often for sharing the odd little clip online or such. It produces a complex command that is not easy to just type out, that does multiple things to maximise compatibility like - making sure pixel are square while resizing if the video resolution is too large ("scale=w=if(gt(iw*sar\\,ih)\\,min(ceil(iw*sar/2)*2\\,{})\\,ceil(iw*sar*min(ih\\,{})/ih/2)*2):h=if(gt(ih\\,iw*sar)\\,min(ceil(ih/2)*2\\,{})\\,ceil(ih*min(iw*sar\\,{})/iw/sar/2)\*2):out_range=limited,zscale,setsar=1") - dealing with some HDR or high gamut thing I can't really remember that can result from screen recording on macos using some method I was using at some point - setting this one tag on hevc files that macos needs for them to be recognised as hevc but isn't set by default - calculating the target bitrate if I need a specific filesize and verifying the encode actually hit that size and retrying if not (doesn't always work first time with certain hardware encoders even if they have a target or max bitrate parameter) - dealing with 2-pass encoding which is fiddly and requires two separate commands and the parameters are codec specific - correctly activating hardware encoding for various codecs - etc And this is just for the basic task of "make this into a simple mp4"

qbow883 9mo ago
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.
- plufz 9mo ago
  > 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.
ranger_danger 9mo ago

zzzeek 9mo ago

sure here's a command that a program I wrote to record my practicing and produce different mixes uses /usr/bin/ffmpeg -i "/path/to/musicfile.mp3" -i "/path/to/covertune.mp3" \ -filter_complex [1:a]volume=1[track1];[0a][track1]amix=normalize=false[output] \ -map [output] -b:a 192k -metadata title=15:17:01 -metadata "artist=Me, 2025" \ -metadata album=2025-12-23 "/path/to/file.mix.mp3" chance of my coming up with that without deep poring over docs and tons of trial and error, or using claude (which is pretty much what I do nowadays): zero

qbow883 9mo ago
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.
- zzzeek 9mo ago
  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

koyote 9mo ago

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

qbow883 9mo ago
Thank you, this explains my thoughts really well.
CamperBob2 9mo ago
Usually when AI hallucinates an option that doesn't exist, the option really should exist. So then I tell it to add it. Then, several days later, I crawl away from fighting robots in a rabbit hole, and finally get around to doing what I set out to do in the first place....

deleted 9mo ago

[deleted]

msla 9mo ago

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

zahlman 9mo ago

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

C4K3 9mo ago

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.guide/graph/demo https://web.archive.org/web/20230131140736/https://ffmpeg.gu...

robertheadley 9mo ago
Different project, but similar vibe. https://ffstudio.app/ https://ffstudio.app/
- zymhan 9mo ago
  This is awesome, thank you so much for posting it.
zymhan 9mo ago
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.

stevage 9mo ago

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

tombert 9mo ago

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.

jayd16 9mo ago

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.

UqWBcuFx6NV4r 9mo ago

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

memset 9mo ago

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?

agentifysh 9mo ago

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.

guntis_dev 9mo ago

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