Instead of clamping property values to the valid range in each property
implementation, handle it in the property layer. The functionality to
handle clamping for each type is in m_option.c.
It's not really clear whether this is really needed. Normally, the raw
values for M_PROPERTY_SET come only from m_option_type.parse (setting
properties as string) or from m_option_parse.add (using the "switch"
input command). However, since this was already done before, and since
we _really_ want to be sure only to write valid values, add this code
anyway. The newly added warnings/error messages should never actually
be printed during normal operation and are for debugging (if they
happen, we definitely want to see them).
This removes the alternative values like "off", "0", "false" etc., and
also the non-English versions of these.
This is done for general consistency. It's better to have a single way
of doing things when multiple ways don't add singificant value.
Also update some choices for consistency.
Use the m_option code by default to format property values, instead of
having separate code in m_property.
To facilitate that, add a pretty_print callback to option types. These
format values in a more human readable and user friendly way, as opposed
to the print callback, which produces parseable values.
This also changes the strings used with flags. Instead of "enabled" and
"disabled", flags are formatted as "yes" and "no". (We could use the
pretty_print callback to deal with this, but we don't for consistency.)
Instead of forcing each property implementation implement its own logic
for M_PROPERTY_STEP_UP/M_PROPERTY_STEP_DOWN, handle it in the generic
property code.
Rename the M_PROPERTY_STEP_UP command to M_PROPERTY_SWITCH (the other
property command, M_PROPERTY_STEP_DOWN, isn't needed anymore: stepping
downwards is done by passing a negative argument). Always use double as
argument type; it makes the code easier, and covers all property types.
Move the code which does the actual type-specific value stepping to
m_option.c (the idea is that m_option handles types).
Some properties still have custom handlers implemented with
M_PROPERTY_SWITCH. They can't be mapped to the generic mechanism,
because their value range is dynamic or entirely unknown.
For some properties, the default step stride is changed to 1. This is no
issue, because the default bindings in input.conf all use an explicit
stride in the affected cases.
This was the option parser for the off_t C type. These days, off_t is
always int64_t, so replace all its uses by int64_t and CONF_TYPE_INT64.
Fix the --sstep option. It used CONF_TYPE_INT with an off_t variable,
which will result in invalid memory accesses. Make it use type double
instead, which seems to make more sense for this option.
The --loop option takes slightly different parameters now. --loop=0
used to mean looping forever. Now it means looping is disabled (this is
more logical: 2 means playing 2 more times, 1 means playing 1 more time,
and 0 should mean playing not again).
Now --loop=inf must be used to enable looping forever.
Extend choice types to allow an optional range of integers as values.
If CONF_RANGE is added to the flags of a m_option_type_choice option,
m_option.min/max specify a range of allowed integer values. This can be
used to remove "special" values from make integer range options. These
special values are unintuitive, and sometimes expose mplayer internals
to the user. The (internal) choice values can be freely mixed with the
specified integer value range. If there are overlaps, the choice values
are preferred for conversion to/from strings.
Also make sure the extension to choice options works with properties.
Add the ability to step choice properties downwards, instead of just
upwards.
This was to make an option without value use the option's default value
(e.g. --term-osd is the same as --term-osd=auto). Make it simpler by
handling this case as an empty choice.
The flag was probably needed when option handling still did ambiguous
argument parsing.
af_format.h declares some symbols which are defined in format.c. The
fact that af_format.c is a completely unrelated file is rather
confusing. Having the header and implementation file use the same base
name is more uniform. (af_format.c is the audio conversion filter, while
af_format.h and format.c are about audio formats and their properties.)
Also fix all source files which include this file.
Remove the duplicated list of audio format names from m_option.c. Remove
"long" audio format names, and let af_fmt2str() print the usual short
format names. The long names were overly verbose, and were actually
rarely user visible. The only difference between af_fmt2str() and
af_fmt2str_short() is that the former prints unknown format values as
hexadecimal string as fallback.
Remove the duplication of image format name lists from codec-cfg.c
and img_format.c. Remove the list of "long" image format names from
img_format.c.
One user visible change is that now mplayer won't print "long" format
names anymore: e.g. instead of "Planar 420P 10-bit little-endian",
the name "420p10le" is used. This is consistent with the names used
by the option parser, and also less noisy.
Partially based on mplayer2 commit f98e47574de15, with some differences.
Given your option struct has a field that is a pointer to another
struct, this commit allows you to declare options that write into that
other struct. The code in m_config will dereference the pointer field
on its own if such an option is accessed. If the field is NULL on
initialization of the containing m_config, the struct is automatically
allocated.
OPT_SUBSTRUCT() can be used to declare such a field.
struct m_sub_options is used to describe the pointed-to struct, and
includes size and defaults if the struct has to be allocated by
m_config.
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.)
This reverts commit 48f0692ab9 "options: make option struct the talloc parent of options".
This made things actually more complicated. It introduced a new
parameter to the option parse and copy functions, which was used
inconsistently. Some code passed a parent, some not. Morever, you have
to call m_option_free() anyway, because not all options actually
respect the talloc parent. There is also the question whether passing
NULL as parent is supposed to work, or if you still have to implement
m_config_free().
On the other hand, this simplifies nothing. I assume the intention was
being able to free all option values with a single talloc_free() call,
but the same goal can be reached by simply freeing the m_config struct.
(The m_config talloc destructor will free each option values.)
Get rid of the talloc parent context parameter. This essentially
reverts commit 48f0692ab9 ("options: make option struct the talloc parent of options").
In video_out.c, make the VO priv struct the talloc parent for the
m_config object, so that destroying the VO will free the options.
The ability to free the m_config struct and all its managed options was
introduced in commit 89a17bcda6.
For some reason only 9-bit 422 wasn't added before.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34524 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
Conflicts:
.gitignore
bstr.c
cfg-mplayer.h
defaultopts.c
libvo/video_out.c
The conflict in bstr.c is due to uau adding a bstr_getline function in
commit 2ba8b91a97. This function already existed in this branch.
While uau's function is obviously derived from mine, it's incompatible.
His function preserves line breaks, while mine strips them. Add a
bstr_strip_linebreaks function, fix all other uses of bstr_getline, and
pick uau's implementation.
In .gitignore, change vo_gl3_shaders.h to use an absolute path
additional to resolving the merge conflict.
Specifying a string option with no parameter, as in "--dumpfile" with
no '=', erroneously set the corresponding variable to NULL. Fix this
to give an error about missing parameter instead.
Suboption parsing explicitly treated empty option values as if the
option had been specified with no value (no '='). Thus it was not
possible to specify empty strings as values. I think this behavior was
originally added only because of other limitations in the old
implementation. Remove it, so that suboptions now behave the same as
top-level ones in this regard.
Document the NULL-distinguishing property of bstrdup0() that the code
depends on, and also make bstrdup() behave consistently.
Allocate dynamically-allocated option values as talloc children of the
option struct. This will allow implementing per-object (VO etc)
options so that simply freeing the object will free associated options
too.
This doesn't change quite every allocation in m_option.c, but the
exceptions are legacy types which will not matter for new per-object
options.
Add an alternate mode for option parser objects (struct m_config)
which is not inherently tied to any particular instance of an option
value struct. Instead, this type or parsers can be used to initialize
defaults in or parse values into a struct given as a parameter. They
do not have the save slot functionality used for main player
configuration. The new functionality will be used to replace the
separate subopt_helper.c parsing code that is currently used to parse
per-object suboptions in VOs etc.
Previously, option default values were handled by initializing them in
external code before creating a parser. This initialization was done
with constants even for dynamically-allocated types like strings.
Because trying to free a pointer to a constant would cause a crash
when trying to replace the default with another value, parser
initialization code then replaced all the original defaults with
dynamically-allocated copies. This replace-with-copy behavior is no
longer supported for new-style options; instead the option definition
itself may contain a default value (new OPTDEF macros), and the new
function m_config_initialize() is used to set all options to their
default values. Convert the existing initialized dynamically allocated
options in main config (the string options --dumpfile, --term-osd-esc,
--input=conf) to use this. Other non-dynamic ones could be later
converted to use this style of initialization too.
There's currently no public call to free all dynamically allocated
options in a given option struct because I intend to use talloc
functionality for that (make them children of the struct and free with
it).
Each option type had three separate operations to copy option values
between memory locations: copy between general memory locations
("copy"), copy from general memory to active configuration of the
program ("set"), and in the other direction ("save"). No normal option
depends on this distinction any more. Change everything to define and
use a single "copy" operation only. Change the special options
"include" and "profile", which depended on hacky option types, to be
special-cased directly in option parsing instead. Remove the now
unused option types m_option_type_func and m_option_type_func_param.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34245 b3059339-0415-0410-9bf9-f77b7e298cf2
Note: ffmpeg first introduced PIX_FMT_GBR24P, which was used in this
commit. Later, it was renamed to PIX_FMT_GBRP in ffmpeg and libav. This
was updated in revision 34492 in mplayer, but the mplayer specific
names (such as IMGFMT_GBR24) were left unchanged.
If an m_option_type_choice option is declared with M_OPT_IMPLICIT_DEFAULT
in its flags, it doesn't require a parameter. For example, if --opt is
such an option, it can be invoked as "--opt=val", "-opt", or "--opt".
The last two will set the option to the first choice the option declares.
Note that "-opt val" (using the old option syntax) is not allowed in this
case, as it would be ambiguous.
Normal option parsing should be unaffected.
Video filter help output was printed twice since it used a MSGT type
that was not suppressed during preparsing. Fix. This removes a
"ID_VIDEO_FILTERS" line that was printed --identify, but I'm not aware of
anything using that and other things like audio filters have no such
ID_ output either. Also change some printf() calls to mp_msg() in code
printing filter-specific help.
A trailing separator in string list options was ignored after recent
commit e873d703e9 ("options: change option parsing to use bstr"),
which broke uses such as "-vo vdpau,". Fix.
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".
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.
Allocate data structures for dynamic option values with talloc.
Hopefully there's no code left that tries to modify those dynamic
option values outside the option parser and relies on them being
malloc-allocated. Currently talloc functionality isn't used much and
the allocations are not hierarchical, so the main practical use for
now is just to allow very easy checking for memory leaks.
Add new internal 9/10-bit IMGFMT values and mappings to the
corresponding libav* PIX_FMT_* values.
Partially based on a patch from Arne Bochem <arneb.mp@ccan.de>.
Commit 2db33ab48c ("options: support string list separators other
than ','") started using the "priv" field in options of string list
type to store the separator character. However, the "profile" option
has a custom type which uses the same parsing function but uses the
"priv" field for another purpose. As a result "-profile" parsing used
a "random" character as the separator instead of ','; at least uses
which depended on ',' working were likely to fail, and if the
separator used happened to be a character occurring in the profile
name then any use of -profile could break. Fix by adding a check in
the parsing function to only read the priv field if the option type is
normal string list.
Allow specifying a custom separator character for options of string
list type, and use that to define OPT_PATHLIST which takes a list of
strings separated by ':' (or ';' on Windows).
vo_zr was the last user of the "func_full" option type. I think it's
better if future features are implemented using more straightforward
option functionality. Delete the func_full implementation.
Add a special option "-leak-report" that enables talloc leak
reporting. It only works if it's given as the first argument.
The code abuses the CONF_TYPE_PRINT option type to make main option
parsing ignore the option. The parser incorrectly consumed the
following commandline argument as a "parameter" for options of this
type when they had the flag to not exit after printing the message.
Fix this. It makes no difference for any previously existing option I
think.
* hr-seek:
input: add default keybindings Shift+[arrow] for small exact seeks
input: support bindings with modifier keys for X input
core: audio: make ogg missing audio timing workaround more complex
core: add support for precise non-keyframe-limited seeks
core: add struct for queued seek info
commands: add generic option -> property wrapper
options: add "choice" option type, use for -pts-association-mode
core: remove looping in update_video(), modify command handling a bit
core: seek: use accurate seek mode with audio-only files
core: avoid using sh_video->pts as "current pts"
libvo: register X11 connection fd in input event system
core: timing: add special handling of long frame intervals
core: move central play loop to a separate function
Conflicts:
DOCS/tech/slave.txt
Add a "choice" option type. Options of this type take a string as
input and set an int option variable to the value corresponding to the
string. The string->int mapping is option-specific and is given in the
option definition. Strings not found in the mapping are rejected as
invalid option values.
Change the option -pts-association-mode to use this new option type
and accept values "auto, decoder, sort" instead of "0, 1, 2". The
change in accepted values shouldn't cause problems as this option is
not appropriate to use in normal user config files.
Make the parse_timestring public, with a slightly extended API.
As a consequence, "2 hours" is no longer recognized as a valid timestamp
meaning "2 seconds".
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32514 b3059339-0415-0410-9bf9-f77b7e298cf2
Found by the Debian QA tool 'lintian'
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31913 b3059339-0415-0410-9bf9-f77b7e298cf2
reintroduce typo in genres.h that was fixed fixed r31913 to match the id3v2 spec
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31920 b3059339-0415-0410-9bf9-f77b7e298cf2
wm4
mplayer-svn
wm4
Uoti Urpala
cehoyos
reimar
Clément Bœsch
Uoti Urpala
diego
cigaes
siretart