[FFmpeg-devel] on the hard state of ffmpeg command line options
nicolas.george at normalesup.org
Mon Oct 29 20:10:32 CET 2012
L'octidi 8 brumaire, an CCXXI, Michael Bradshaw a écrit :
> I'm also worried aliases might lead to more confusion, as two
> documents might specify the same thing with different commands.
That was exactly my reaction when I read the suggestion of aliases. You will
get on the mailing lists and webforums people who answer in the line of "you
should not use -i:foo, you should use -vfoo instead", while both are
equivalent, you will find tutorials and examples that use one syntax and
tutorials and examples that use the other syntax, and when you try to use
snippets of information from both, you will have to figure out why the
options cancel each other, etc.
> a clear, concise "Beginners Guide" would be sufficient that just
> explains the bare necessities, but I don't know.
Better documentation is always good. And the nice thing about documentation
is that you do not have to be a developer to write it.
Eliminating the cases where ffmpeg accepts ambiguous options, or ignores
options because they are not relevant would also help.
Another side of the problem is, IMHO, that ffmpeg uses default values
extensively, even when they are totally arbitrary. The examples of the
image2 demuxer in this thread is a typical case:
ffmpeg -i foo%03d.png -r 30 ...
should just fail with an error message "image2: no frame rate specified";
same goes for quality level (why is my video so bad quality? you did not
specify a bitrate, what do you expect?), codec, etc.
Unfortunately, the decided policy goes the other way around, and changing it
would probably break a lot of existing programs, which is not acceptable. At
least, printing very visible warnings "image2: sample rate not specified,
using default 25 FPS" would help.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel