[DANK_YACHT]

The issue with FFmpeg is that it's complex, so you need to understand what all the options do, but the interface is also complex, so you need to understand how to format what you want to do, even if you already have a good understanding of what you want from FFmpeg. E.g. the order of different options matter, applying some options to one stream vs. another, chaining filters together, formatting the filters, specifying the output options, etc.

[dylan604]

^An issue with FFMPEG

This isn't THE only issue with FFMPEG. There are many many problems with FFMPEG, but it's the best thing we have in this area. Warts and all, I would probably, no, definitely would not have been able to achieve many of the career accomplishments I have without it.

As you start to reveal the multitude of switches/options/etc available to FFMPEG via GUI, the GUI becomes gnarly and complicated very quickly. This then becomes just as daunting to the avg user as trying to build the command itself. There are many practical uses for a very simplified GUI to achieve a limited set of functionality. There's nothing wrong with it. In fact, I'd be willing to guess that if a UI came along that exposed every single thing that FFMPEG could do, fewer people would use it than a much more simplified version.

[paulmd]

Yeah "modules that mostly work, usually, mostly" is no joke. And it's not that anyone really could do anything significantly better than ffmpeg, it is probably one of the best examples besides the kernel of an astonishingly complex library that is run extremely competently but the task space is just maddeningly complex and full of wild edge-cases. Especially when dealing with "legacy" formats and codecs from the 90s and early 00s - even today, have fun transcoding RealVideo or ASF files with some weird color space that nobody has used in 20 years.

There are infamously a lot of tasks that "look easy upfront but have a lot of underlying complexity" and ffmpeg is not one of them. It's a task that looks hard upfront and then when you get down into the weeds it's an eye-bleeding eldritch monstrosity.

The consensus around MP4 and MKV containers and some relatively small number of codecs (H264, H265, VP1, AV1, etc) has substantially eased things but video codecs, audio codecs, and container files are just complicated af.

And believe it or not - this is still way, way better than it used to be! Flaskmpeg was never stable, Virtualdub was nice but development ended with avi container files, there were some forks that added various features, etc, but ffmpeg and OBS Studio both actually just work incredibly well compared to what came before.

[dylan604]

>has substantially eased things

except not everyone has decided to use that easing of the things. it seems like they go out of their way to make things difficult

My favorite is in how MP4s are not all the same. A video captured on a DSLR or other acquisition camera source might have +/- in the video/audio sync when imported into an NLE. Yes, the container utilizes PTS syncing to playback the video/audio streams in sync, but this +/- slop in sync is annoying AF to professionals capable of seeing the sync slop. Average consumers probably never notice. I thank all the gawds in all the heavens that I no longer have to edit MP4 source captured content and all of the manual slipping in the NLE.

[scottlamb]

If you want a single tool/library that does all the things ffmpeg does, I agree. ffmpeg does lots of things, some of them are inherently extremely complex, and it puts them together cohesively. That's impressive! I think the closest competition is gstreamer, and gstreamer ends up calling into ffmpeg for software H.264 decoding...

But...sometimes you want one particular thing, that thing is relatively simple (compared to e.g. H.264 decoding), and you have needs ffmpeg doesn't meet. Then you probably can do better. A couple examples that have come up for me:

* specialized .mp4 muxing. My NVR project does this in a way where it can do HTTP range serving, so put the moov up front, produce the length quickly, and produce a given byte range without iterating through all the bytes before. ffmpeg can't do that, understandably. Hard to do in a general-purpose library; the container muxing input interface doesn't expect all the necessary information is available up front. But it's not that bad as a one-off. As you say, the consensus around a small number of containers really helps.

* RTSP. Consistent with your "modules that mostly work, usually, mostly", ffmpeg has various long-standing bugs in its RTSP handling (e.g. https://trac.ffmpeg.org/ticket/5018), has the risk associated with protocol handling in a non-memory-safe language, doesn't have much of a test framework for this, etc. This problem is relatively approachable (though hardly trivial), so I had success making my own library.

[DANK_YACHT]

GStreamer has a much more sane CLI interface. FFmpeg generally works better than GStreamer, but it's definitely possible to make a better command line interface.

[paulmd]

This is, btw, a great time to plug "bropages". Manpages give you in-depth documentation on what each option does, bropages the idea is to give you a synthesis of an actual task being done with those command options, then you can mix-n-match to fit your use-case (if necessary).

http://bropages.org/ffmpeg

The antidote to ffmpeg's arcane command-line has always been finding someone else who already did it and seeing what they did differently. There are, of course, many ways to skin the cat in ffmpeg, but you often just need to see some finished, working commands and start from there.

You could of course build that on a wiki somewhere, ffmpeg does have various examples in their docs, but bropages is a place to curate that sort of stuff.

[thrtythreeforty]

For even more brevity, there's tldr [1], which is short-n-sweet "how do I do the most common things with this tool."

You'll need a client for it (tldr itself is just the database). I recommend tealdeer [2].

Example:

    $ tldr tar

      Archiving utility.
      Often combined with a compression method, such as gzip or bzip2.
      More information: <https://www.gnu.org/software/tar>.

      [c]reate an archive and write it to a [f]ile:

          tar cf target.tar file1 file2 file3

      [c]reate a g[z]ipped archive and write it to a [f]ile:

          tar czf target.tar.gz file1 file2 file3

[1]: https://tldr.sh/

[2]: https://github.com/dbrgn/tealdeer

[thaumasiotes]

    Often combined with a compression method, such as gzip or bzip2.

    [...]

    [c]reate a g[z]ipped archive and write it to a [f]ile:

       tar czf target.tar.gz file1 file2 file3

That helpful bracketing notation is going to break down as soon as you actually want to deal with bzip2.

There's no real problem, but I never like it when I'm given an example that seems to be going out of its way to suggest something untrue.

[thrdbndndn]

Agreed. At this point probably just use CLI.

One thing I hate about CLI tool though, is that it's very hard to edit long commands in terminal.

For example, to replace the input filename from the previous command. I can do it in one second with my keyboard + mouse (use the mouse to select the old one, and type in the new one which would replace) in editor but you can't do so in terminal.

Another example is to change the order of some switches. Again very easy in text editor, not so much in terminal.

So, everytime I use FFMPEG for some complex one (especially when I need to go through trial and error, I have to write the thing in a text editor and them paste them into terminal.

[noir_lord]

ctrl-x e

> It's a small key sequence: ctrl-x e . What's this do? It takes the existing command that you currently have on your command line and opens it in your shell's editor

[remram]

It's ctrl-x ctrl-e

[paulmd]

> One thing I hate about CLI tool though, is that it's very hard to edit long commands in terminal.

Apart from the "wrap it in a shell script" advice, I would also note that in a bash-like terminal, home and end will jump to the start or the end of the current command buffer, and ctrl-del (or alt-del maybe?) or ctrl-arrow keys usually delete or move the cursor a whole word at a time, which makes it somewhat quicker to work rather than sitting there holding an arrow key or backspce.

Many here probably already know this, some may not!

[thrdbndndn]

Thanks, yeah I know these since I use them heavily in editor as well.

Now this got me thinking: the main problem with terminal is that it doesn't seem to support "cut" (and consequently, "paste to replace selection"). So re-arranging a command string is always gonna be a pain regardless the complexity.

I can see why it was this way historically, but not exactly sure why no modern terminal emulator gives this feature, even as optional.

[paulmd]

one analogy might be the "cut and accumulate" feature in nano (and probably others) where a line is removed and appended to the clipboard, then you can paste and all those lines will be pasted off the clipboard at once. You could do that at a character level in the shell, if you wanted. No idea if any shells do though.

[wtch98]

ctrl-a and ctrl-e to start/end of line

[dylan604]

>One thing I hate about CLI tool though, is that it's very hard to edit long commands in terminal.

Only a madman would do this. I don't know anyone that's in the middle of R&D that builds directly in the CLI that's sane. Everyone tries it, and just at the point of losing sanity, does the rational thing of building the command in a text editor for a simple copy&paste into the CLI later.

[benfrancom]

Yep, or turn it into a script and use an IDE/Vim/etc and test in the terminal.