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

I do, yes. Though that's not really the point, it'd already be enough to know where to look it up.

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 a day ago | parent [-]

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

	▲	kristopolous a day ago \| parent [-]
		ffmpeg doesn't go away. it's still there. people can use tig and git, having something that isn't insane can live in harmony with the other thing.