[Ffmpeg-devel] Bug, new format, and question =)

[Rich Felker]

On Wed, Nov 16, 2005 at 08:59:44AM -0700, Mike Melanson wrote:
> Rich Felker wrote:
> >On Tue, Nov 15, 2005 at 03:10:46PM -0700, Mike Melanson wrote:
> >
> >>>Many Linux programs uses getopts() for argument handling. How can it be
> >>>that ffmpeg and mplayer doesn't?
> >>
> >>	Uh oh... please don't rock the boat by suggesting certain accepted 
> >>programming practices. This is what I predict: The Guru will say, "send 
> >>a patch" indicating that you are welcome to revise the program to use 
> >>the getopt facility. "He whose name ends in 3" will flame back and 
> >>rabidly denounce all that is GNU (gcc, autotools, getopt, etc.) and the 
> >>situation will just degenerate from there.
> >>
> >>	The short answer for not using getopt: That's just the way it is. :)
> >
> >
> >mans' answer was much better: it just does not do what we need.
> 
> 	I find that hard to believe. Is it just because MPlayer/FFmpeg likes 
> 	to use "-op=j:u:n::k" style parameters and getopt does not usually follow 
> that convention?

No. It's because in both mplayer and ffmpeg, the order of options is
very important. ffmpeg does this so that you can use the same options
both for specifying properties of the input stream (for raw input, or
to override broken files) and for selecting how the output stream
should be formatted. This is just a matter of convenience, but for
mplayer it's much more fundamental. The command line looks like:

mplayer [global options] file1 [file1 options] file2 [file2 options] ...

The getopt system is not at all well-suited to this, nor does it
provide any sane way, as far as I know, to implement per-file options.

Maybe you think its not important, but these per-file options are very
useful for kiosk-type setups, and totally essential for mencoder's
multifile support where it may be necessary to process input files
differently in order to convert them all to a suitable common output
format.

Rich