If you look at it as more of a "composable" interface (as the sibling poster suggested), it makes a lot more sense.

No one is going to type out this one-liner from scratch, or have an easy time understanding what it means by reading it, but as it's made up of a series of smaller, more easily understood commands, in a shell or Python script it could be vastly more legible and, dare I say it, usable.

This is also the reason why there are so many frontends to ffmpeg, to simplify various specific tasks. I can't count how many one-off apps I've seen that do one thing and do it well, and just ship a full copy of ffmpeg to do that one thing. Making an actual GUI for all of this would be just... insane, really, but it's so versatile and flexible that you can basically do anything with it.

> Making an actual GUI for all of this would be just... insane, really, but it's so versatile and flexible that you can basically do anything with it.

Challenge accepted! (No seriously, that's what I'm working on)

The problem with calling ffmpeg multiple times in a script is you often waste compute time.

If you can manage to cobble together a single command (as illegible as that may be), you might be able to do what you're looking to do in far less time

No to mention you also loss quality (the generation loss) unless you use lossless format as intermediate.

Maybe what's missing is some kind of ffmpeg shell where you can build pipelines and then run them? A bit like spark-shell, or avisynth on windows?

I've been working on making "pre-baked recipes" for a while to help with simple tasks like cutting/merging a video [0]. I recently made an npm package for making time lapses with effects from the command line with FFmpeg as well [1].

[0] https://github.com/zvakanaka/ffeasy [1] https://www.npmjs.com/package/mklapse

I'd recommend looking at something like kdenlive, it generates the ffmpeg command and script for you. It's still complex and difficult to do somethings but it can be much nicer than trying to work out the command line interface for something you want to do. It's also nice because you can save the project at a higher level and reopen it later without having to do all the work of figuring things out again.

> I'd recommend looking at something like kdenlive, it generates the ffmpeg command and script for you.

Doesn't kdenlive use melt [0] instead of ffmpeg directly?

[0] https://www.mltframework.org

The syntax is very difficult to wrap your head around, but beyond that, it is the implicit behavior that makes it difficult to reason about. I find that the short ffmpeg commands that take advantage of automatic stream selection and omit the inputs/outputs of filters because ffmpeg can hook them up automatically to be much harder to reason about than the fully written out, fully explicit ffmpeg command lines.

It almost seems like the best way to understand an ffmpeg complex filter graph is to actually draw a graph...

I actually made my own CLI frontend just because I didn't want to try and memorize ffmpeg options to do the simple things that I want to do most of the time. Now I can just do `--h264 -s X -e Y` to do a h.264 encode from X timecode to Y timecode.

Is -s X -e Y really much easier than -ss X -t $((Y-X)) ?

Every couple of years worth of not using an option I need to look it up again. But it's usually not too hard.

Yes, because that doesn't actually work proper. In order to seek fast while having the ability to start encoding at any point without issues with keyframes, I need to actually do `ffmpeg -ss X1 -i FILE -ss X2 -t (Y-X)` where X1 + X2 = X.

Compare:

    frontend -s 05:28:38.667 -e 05:28:58.767 input.ts
    ffmpeg -ss 05:28:28.667 -i input.ts -ss 10 -t 20.100 -pass 1
    ffmpeg -y -ss 05:28:28.667 -i input.ts -ss 10 -t 20.100 -pass 2

I wrap it in shell scripts or batch files.