Handling this was accidentally forgotten when command line parsing was
refactored. The added recursive call should be a tail recursion with
all reasonable compilers, and it shouldn't be possible to provoke a
stack overflow.
When the internal mplayer MPEG demuxer was removed (commit 1fde09db),
the default demuxer when using dvdnav was set to libavformat. Now it
turns out that this doesn't work with libavformat. It will terminate
playback right after the audio runs out (instead of looping it like the
video, or whatever it's supposed to do). I'm not sure what exactly the
problem is, but since 1. even mplayer-svn can't handle DVD menus
directly (missing highlights), 2. DVD menus are essentially worthless,
and 3. I don't directly watch DVDs, don't bother with it and remove it.
For basic playback, there's still libdvdread support.
Also, use pkg-config for libdvdread, and drop support for in-tree
libdvdread. Remove support for in-tree libdvdcss as well.
Options parsing used to be ambiguous, as in the splitting into option
and values pairs was ambiguous. Example:
-option -something
It wasn't clear whether -option actually takes an argument or not. The
string "-something" could either be a separate option, or an argument
to "-option". The code had to call the option specific parser function
to resolve this.
This made everything complicated and didn't even have a real use. There
was only one case where this was actually used: string lists
(m_option_type_string_list) and options based on it. That is because
this option type actually turns a single option into a proxy for several
real arguments, e.g. "vf*" can handle "-vf-add" and "-vf-clr". Options
suffixed with "-clr" are the only options of this group which take no
arguments.
This is ambiguous only with the "old syntax" (as shown above). The "new"
option syntax always puts option name and value into same argument.
(E.g. "--option=--something" or "--option" "--something".)
Simplify the code by making it statically known whether an option takes
a parameter or not with the flag M_OPT_TYPE_OLD_SYNTAX_NO_PARAM. If it's
set, the option parser assumes the option takes no argument.
The only real ambiguity left, string list options that end on "-clr",
are special cased in the parser.
Remove some duplication of the logic in the command line parser by
moving all argument splitting logic into split_opt(). (It's arguable
whether that can be considered code duplication, but now the code is a
bit simpler anyway. This might be subjective.)
Remove the "ambiguous" parameter from all option parsing related code.
Make m_config unaware of the pre-parsing concept.
Make most CONF_NOCFG options also CONF_GLOBAL (except those explicitly
usable as per-file options.)
Now the command line parser sets the m_config object into file local
mode, so that m_config can check for this condition. Makes trying to
set global options from a profile fail.
Note: global options can be considered read-only by m_config, so maybe
there should be an additional check for this. Reusing the file-
local check is more practical for now, though.
Summary:
- There is no playtree anymore. It's reduced to a simple list.
- Options are now always global. You can still have per-file options,
but these are optional and require special syntax.
- The slave command pt_step has been removed, and playlist_next
and playlist_prev added. (See etc/input.conf changes.)
This is a user visible incompatible change, and will break slave-mode
applications.
- The pt_clear slave command is renamed to playlist_clear.
- Playtree entries could have multiple files. This is not the case
anymore, and playlist entries have always exactly one entry. Whenever
something adds more than one file (like ASX playlists or dvd:// or
dvdnav:// on the command line), all files are added as separate
playlist entries.
Note that some of the changes are quite deep and violent. Expect
regressions.
The playlist parsing code in particular is of low quality. I didn't try
to improve it, and merely spent to least effort necessary to keep it
somehow working. (Especially ASX playlist handling.)
The playtree code was complicated and bloated. It was also barely used.
Most users don't even know that mplayer manages the playlist as tree,
or how to use it. The most obscure features was probably specifying a
tree on command line (with '{' and '}' to create/close tree nodes). It
filled the player code with complexity and confused users with weird
slave commands like pt_up.
Replace the playtree with a simple flat playlist. Playlist parsers that
actually return trees are changed to append all files to the playlist
pre-order.
It used to be the responsibility of the playtree code to change per-file
config options. Now this is done by the player core, and the playlist
code is free of such details.
Options are not per-file by default anymore. This was a very obscure and
complicated feature that confused even experienced users. Consider the
following command line:
mplayer file1.mkv file2.mkv --no-audio file3.mkv
This will disable the audio for file2.mkv only, because options are
per-file by default. To make the option affect all files, you're
supposed to put it before the first file.
This is bad, because normally you don't need per-file options. They are
very rarely needed, and the only reasonable use cases I can imagine are
use of the encode backend (mplayer encode branch), or for debugging. The
normal use case is made harder, and the feature is perceived as bug.
Even worse, correct usage is hard to explain for users.
Make all options global by default. The position of an option isn't
significant anymore (except for options that compensate each other,
consider --shuffle --no-shuffle).
One other important change is that no options are reset anymore if a
new file is started. If you change settings with slave mode commands,
they will not be changed by playing a new file. (Exceptions include
settings that are too file specific, like audio/subtitle stream
selection.)
There is still some need for per-file options. Debugging and encoding
are use cases that profit from per-file options. Per-file profiles (as
well as per-protocol and per-VO/AO options) need the implementation
related mechanisms to backup and restore options when the playback file
changes.
Simplify the save-slot stuff, which is possible because there is no
hierarchical play tree anymore. Now there's a simple backup field.
Add a way to specify per-file options on command line. Example:
mplayer f1.mkv -o0 --{ -o1 f2.mkv -o2 f3.mkv --} f4.mkv -o3
will have the following options per file set:
f1.mkv, f4.mkv: -o0 -o3
f2.mkv, f3.mkv: -o0 -o3 -o1 -o2
The options --{ and --} start and end per-file options. All files inside
the { } will be affected by the options equally (similar to how global
options and multiple files are handled). When playback of a file starts,
the per-file options are set according to the command line. When
playback ends, the per-file options are restored to the values when
playback started.
Handle -v flags as a special case in command line preparsing stage,
and change the option entry into a dummy one. Specifying "v" in config
file no longer works (and the dummy entry shows an error in this
case); "msglevel" can still be used for that purpose. Because the flag
is now interpreted at an earlier parsing stage, it now affects the
printing of some early messages that were only affected by the
MPLAYER_VERBOSE environment variable before.
The main motivation for this change is to get rid of the last
CONF_TYPE_FUNC option.
When parsing the command line, map "--no-foo" to "--foo=no" if an
option named "foo" exists and is a flag option. Non-empty parameters
are not allowed with this syntax ("--no-foo=no" is invalid).
This implementation is different from the existing "--nofoo" variants
for most flag options. Those are implemented as completely separate
options; there's an option named "fs" and a separate option named
"nofs" (thus "--no-nofs" actually works after this change...). The
reason for adding the new syntax is to support the much more standard
"--no-" prefix and to allow eventually cleaning up the option handling
(though the "nofoo" variants of existing options can't be removed soon
due to backwards compatibility).
The command line parsing code recorded the next commandline argument,
if any, as the parameter of any option recorded to playtree. Thus a
command line like "mplayer file -fs -aid 1" would record option "-fs"
with a bogus argument "-aid". Historically this triggered no visible
problems because such bogus arguments were silently ignored when
interpreting the options later. However after recent commit 507fa7e2c2
("options: indicate ambiguous option parameters explicitly")
parameters to flag options are no longer ignored, and the bogus values
now triggered parsing errors. Add a check to stop recording parameters
for old-style single-dash options if m_config_check_option() says the
option did not consume any arguments.
If parsing an option fails, print a string corresponding to the parse
function return value (M_OPT_MISSING_PARAM etc). The primary
motivation is that the parsing code already outputs messages
explaining most problems, but does not itself print anything in the
missing parameter case. Before double-dash --options such errors were
rare (or rather they resulted in the next commandline argument being
silently misinterpreted as an argument to the previous option
instead); but now an argument like "--ss" should give a better
indication about the problem than just "Error parsing option".
Allow writing commandline options with two leading dashes. In this
mode a parameter for the option, if any, follows after a '=';
following separate commandline arguments are never consumed as a
parameter to a previous double-dash option.
Flag options may omit parameter and behave like old single-dash
syntax. "--fs=yes", "--fs=no" and "--fs" are all valid; the first two
behave like configuration file "fs=yes" and "fs=no", and last is the
same as old "-fs" (same effect as "--fs=yes").
A "--" argument on the command line is used to indicate that all
following arguments should be interpreted as filenames, not options.
Specifying it as the last argument was considered an error. I see no
particular reason to forbid the following filename list to be empty,
nor do other programs with similar functionalitly I know about treat
it that way. So just ignore a "--" with no more arguments.
Command line options like "-foo xyz" are ambiguous: "xyz" may be a
parameter to the option "foo" or an unrelated argument. Instead of
relying on the struct m_config mode field (commandline/file) pass
parameters to specify ambiguous mode explicitly. Meant for "--foo"
options which are never ambiguous on command line either.
The global was used in the function cfg_include which handles the
-include option. Make the address available in that function by
creating a new dynamically allocated option in m_config_new that has
the address in the option's private data.
asxparser.c also used the global. Making it available through all ways
the code could get called required a number of relatively straightforward
changes to playtree and menu code.
Include the corresponding .h file in command.c, parser-cfg.c and
parser-mpcmd.c. This allows the compiler to check that the
declarations in the .h file match the actual defition.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@26295 b3059339-0415-0410-9bf9-f77b7e298cf2
fixes MPlayer exiting without message for e.g. "mplayer -ao"
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@18149 b3059339-0415-0410-9bf9-f77b7e298cf2
This one makes
mplayer -vo help -ao help -ac help -vc help -pphelp -af help -vfm help -vf help -afm help -fstype help
produce the desired output.
From the thread:
Date: Jul 16, 2005 8:25 PM
Subject: [MPlayer-dev-eng] [PATCH] allow multiple help clauses on the command line
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@16346 b3059339-0415-0410-9bf9-f77b7e298cf2
