[FFmpeg-devel] on the hard state of ffmpeg command line options

[Roger Pack]

> What about the people who RTFM?.

I have used FFmpeg for several years and never read the manual (tried
a few times) because it is just too long and (sorry to say it, and
this isn't meant to offend) it's confusing for beginners.
I agree that the docs could/should be cleaned up, and I'd benefit from it.

For instance, after the synopsis (which appears to be "the tersest way
to describe FFmpeg"), the documentation immediately dives into a
description of "using -map" and "0 based indices".  Then it gives some
examples.  Which don't use -map and don't use indices.

That's where I historically give up and quit reading the docs.  I
don't even reach the examples, to be honest with you.  It seems that
it lacks an easy section "for beginners."

> What about long-time users?

I like the idea of keeping the current syntax but providing for future
options that seem "less ambiguous"

> What about people who like short command line options?

See above.

That being said, if the game plan is to keep the current style of
parameters (which I'm sure it is), I will try and submit some patches
to try and aide beginners more, in the documentation intro.  So I'd be
ok with keeping current behavior and trying to cleanup documentation.


On a different topic, I will disclose my secret, hidden, real gripe
that spawned my message originally (just to get it off my chest once
and for all).

Given this command line:

$ ffmpeg -i INPUT -r 24 OUTPUT

To me this (without reading docu) "means" 24 fps input (in reality,
it's ambiguous).  To me, natural flow is I specify an input, and then
parameters that apply to it. It feels awkward to specify input
parameters before the input (global parameters make sense...input
parameters that are basically in the same location as global
parameters? no).  I'm just saying this for discussion--I realize it's
very unlikely to change at this point.

That's the reason I initially proposed the (rather kludgey) -i "input
-r 24" type input.  It's unambiguous, and, allows me to do a command
line that makes sense to me.  I'm not suggesting it as a good idea,
just letting you know the reasoning behind the idea.
This type of syntax may make it "harder" to mess it up, even if you
haven't read the documentation.

I also wouldn't be averse to some type of indexed arguments (as
suggested earlier in the thread), to accomplish a similar goal
(removing ambiguity).

Though my fears have been lessened given our previous discussion on RTFM.

Thanks for the feedback.
More welcome :)
-roger-