I never had to use it since I never had anything complicated enough, but next time you relearn things, I've heard good things about ffmpeg-python [0] , it supports multiple inputs, outputs, custom filters, etc.

Their example from the readme:

    ffmpeg -i input.mp4 -i overlay.png -filter_complex "[0]trim=start_frame=10:end_frame=20[v0];\
    [0]trim=start_frame=30:end_frame=40[v1];[v0][v1]concat=n=2[v2];[1]hflip[v3];\
    [v2][v3]overlay=eof_action=repeat[v4];[v4]drawbox=50:50:120:120:red:t=5[v5]"\
    -map [v5] output.mp4

Which turns into

    import ffmpeg

    in_file = ffmpeg.input('input.mp4')
    overlay_file = ffmpeg.input('overlay.png')
    (
        ffmpeg
        .concat(
            in_file.trim(start_frame=10, end_frame=20),
            in_file.trim(start_frame=30, end_frame=40),
        )
        .overlay(overlay_file.hflip())
        .drawbox(50, 50, 120, 120, color='red', thickness=5)
        .output('out.mp4')
        .run()
    )

[0] https://github.com/kkroening/ffmpeg-python

At this point I'd prefer it if ffmpeg included Lua and allowed you to pass Lua scripts, kinda like what ZFS did[1].

[1]: https://zfsonlinux.org/manpages/0.8.3/man8/zfs-program.8.htm...

I feel like it's better to embed the tool in a language, or many community supported languages than embed a programming language in the tool.

Per the docs on zfs program:

    The entire script is executed atomically, with no other administrative operations taking effect concurrently. 

Which would be somewhat hard to ensure with an external language.

This just sounds like when the script is run, a lock is taken. It seems like a pretty fast and loose definition of "atomic" (as in, not the ACID sense), as it says below:

     If a fatal error is returned, the channel program may have not executed at all, may have partially executed, or may have fully executed but failed to pass a return value back to userland. 

If an external tool is allowed to acquire this kind of exclusive lock, I don't see the difference.

> If an external tool is allowed to acquire this kind of exclusive lock, I don't see the difference.

That's the whole point, as I understand it. The channel programs are executed in the kernel, in a way that cannot be done by external programs. Some more details here[1].

edit: I also think you should have included the note, which says

Note: ZFS API functions do not generate Fatal Errors when correctly invoked, they return an error code and the channel program continues executing.

So while it's not quite ACID-level, its not as bad as it sounds without that note.

[1]: https://openzfs.org/wiki/Projects/ZFS_Channel_Programs

My feeling is that they're already there with the command line (just look at the filter stuff). Might as well just go all the way and have something sane that's supported all over.

I find that ffmpeg's regular command lines are easier to mentally parse if I include additional \ to separate things out onto their own lines. That's what I've done in several shell scripts that do complicated things with ffmpeg, along with comment lines and echoing commentary on what it's doing to the terminal.

FTR, I also do that for regular shell scripts.

ffmpeg-python is great! easier to construct complex commands, and read / edit later

It's true, and I feel the same, but to give it some credit: wouldn't that apply to anything you don't use regularly? Programming languages or even regular languages. You have to use it or lose it.

If you don't perform a task frequently, a discoverable interface (e.g. GUI) is dramatically more productive than reading documentation.

Conversely, if you perform a task frequently you want to be able to script it out and automate it away.

Why not both? GUIs can be built that can emit the command-line equivalent.

In ffmpeg's case, I would be looking for a GUI beyond just "here's all the command line parameters, only in a form"... the hardest thing is taking something I already know what I want to do, and encoding it into the command line, because the way to encode a graph into a command line is not obvious. It is easy in principle but there are so many degrees of freedom in how it is done that I can never remember it all. This is a perfect time for a visual language.

there is winff(not sure of its state today) its totally just a gui frontend even shows you it working in console for an example of something already written. scripting can help with more complicated operations but just for common shorthand there are aliases which can be written out scripts single command lines and pointing to script files.

I use ffmpeg not infrequently, but rarely to do the same thing, so automation doesn't help. Knowing how filter chains work and having access to the filter documentation is great.

Well there are video editing GUIs, even straightforward ones. But they'll have footguns and surprising behaviour everywhere. Lossy or compressed video is a hard problem.

This really depends a lot on the quality of the GUI and the documentation.

IMO the best option is the best of both worlds. A GUI that outputs the CLI command along with good documentation would be ideal.

> wouldn't that apply to anything you don't use regularly?

Doesn't apply to well-designed GUI programs. In good GUIs features are discoverable, you don't need prior knowledge or documentation to use software.

Experience speeds things up, e.g. keyboard shortcuts are faster than menus or buttons. That's optional though, one can still use the software without these shortcuts.

There's a continuum, and yes that applies to human languages, both natural and constructed, and to other skills. But where you can choose (so, not natural languages really) you can design things to make this easier, or, I guess, harder.

For example English orthography is a horrible mess. The inventory of squiggles needed to write English isn't too bad, but the correspondence between the words you know and the correct sequence of squiggles to write them is unnecessarily complicated. No benefit accrues to us from this, and in some other written languages it's much easier.

I'd place ffmpeg somewhere in the not-bad but not-great part of the continuum. As with English orthography of course the problem is if you change things with the intent to make them better you actually introduce a cost for existing users which may be impossible to sustain.

You don’t lose it completely. It rusts over, but I had occasion recently to resurrect my 6502 assembler, and it was still in muscle memory.

Kinda like running into an old friend you haven’t seen in decades.

> My relation with it is almost identical to my relation with any bash scripting more than a one-liner: I have to relearn it every time I want to engage with it.

This is how I feel about jq, every time I want to parse some JSON I have to re-read their documentation. Their API is not very intuitive (at least to me).

I just grep through my bash history ;)

I have shortcuts to save last (sl) executed command and another to grep that file.

    alias sl='fc -ln -1 | sed "s/^\s*//" >> ~/.saved_commands.txt'
    alias slg='< ~/.saved_commands.txt grep'

You can also add a comment to the command before saving. For ex:

    $ foo_cmd args #this command does this awesome thing
    $ sl

I have a $HOME/bin folder full of bash scripts invoking imagemagick or ffmpeg one liners.

One handy idiom I like to use after typing out a long command that I might want to save is

    echo ‘!!’ > ~/bin/name-of-script

where !! is the previous command

care to share? :D

This one for instance to grab my desktop quickly without starting another program when I want to make a quick demo for a colleague:

  #!/bin/bash

  size=${1:-"1920x1080"}
  offset=${2:-"0,0"}
  name=${3:-"video"}

  ffmpeg -video_size $size -framerate 25 -f x11grab -i :0.0+$offset -c:v libx264 -crf 0 -preset ultrafast "$name.mkv"
  ffmpeg -i "$name.mkv" -movflags faststart -pix_fmt yuv420p "$name.mp4"

I remember when mencoder wasn't just a frontend for ffmpeg, I literally just saved a text file with the ridiculous command required to convert a DVD to an avi.

Their man page even had a like three line long example for basic stuff. ffmpeg is at least a bit more consistent with syntax though only barely!

Feels like a nice & typed Haskell eDSL on top of ffmpeg would be helpful.

It would be hard to be expressive enough considering there’s a lot of exceptions where things don’t really quite work.

eg copying without conversion between different formats isn’t really possible when it looks like it should be, because there’s a lot of incorrect handling of timestamps both in libavformat and in files themselves.

> I have to relearn it every time I want to engage with it

That's my relation with regex.

I’ve heard this a few times. I’m the opposite, I think I learned it once and never forgot it, it seems impossible. Do you understand regex in terms of a state machine? Draw it out. It’s a very simple language.

Its the syntax, not the idea that I forget. I use it rarely which is why I have to relearn from some cheat sheet what each symbol means.