4 ms·

FFmpeg is infamous for absurdly complex command options. It's really too much for a "one-liner" CLI. When I use it, I just look for "pre-baked recipes" otherwi

FFmpeg is infamous for absurdly complex command options. It's really too much for a "one-liner" CLI. When I use it, I just look for "pre-baked recipes" otherwise it's a really unpleasant rabbit hole to get into.

simcop2387 6y ago
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.
- shakna 6y ago
  > 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 https://www.mltframework.org
danudey 6y ago
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.
- dmerrick 6y ago
  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
  - innocenat 6y ago
    No to mention you also loss quality (the generation loss) unless you use lossless format as intermediate.
- rezonant 6y ago
  > 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)
  - deleted 6y ago
    [deleted]
- lmm 6y ago
  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?
Hamuko 6y ago
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.
- asveikau 6y ago
  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.
  - Hamuko 6y ago
    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
quintonish 6y ago
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 https://github.com/zvakanaka/ffeasy [1] https://www.npmjs.com/package/mklapse https://www.npmjs.com/package/mklapse
rezonant 6y ago
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...
scooter_de 6y ago
I wrap it in shell scripts or batch files.

simcop2387 6y ago

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.

shakna 6y ago
> 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 https://www.mltframework.org

danudey 6y ago

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.

dmerrick 6y ago
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
- innocenat 6y ago
  No to mention you also loss quality (the generation loss) unless you use lossless format as intermediate.
rezonant 6y ago
> 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)
- deleted 6y ago
  [deleted]
lmm 6y ago
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?

Hamuko 6y ago

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.

asveikau 6y ago
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.
- Hamuko 6y ago
  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

quintonish 6y ago

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 https://github.com/zvakanaka/ffeasy [1] https://www.npmjs.com/package/mklapse https://www.npmjs.com/package/mklapse

rezonant 6y ago

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

scooter_de 6y ago

I wrap it in shell scripts or batch files.