| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
This works by first parsing a config file into the default profile, and
applying it once parsing the whole file is finished.
This won't work across config files (not even if you include other
config files via "include=file.conf").
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vo_opengl sub-option were always rather annoying to handle. It seems
better to make them global options instead. This is simpler and easier
to use. The only disadvantage we are aware of is that it's not clear
that many/all of these new global options work with vo_opengl only.
--vo=opengl-hq is also deprecated.
There is extensive compatibility with the old behavior. One exception is
that --vo-defaults will not apply to opengl-hq (though with opengl it
still works). vo-cmdline is also dysfunctional and will be removed in a
following commit.
These changes also affect opengl-cb.
The update mechanism is still rather inefficient: it requires syncing
with the VO after each option change, rather than batching updates.
There's also no granularity (video.c just updates "everything", and if
auto-ICC profiles are enabled, vo_opengl.c will fetch them on each
update).
Most of the manpage changes were done by Niklas Haas <git@haasn.xyz>.
|
| |
|
|
| |
To be used by the following commits.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The way option runtime changes are handled is pretty bad in the current
codebase. There's a big option struct (MPOpts), which contains almost
everything, and for which no synchronization mechanism exists. This was
handled by either making some options read-only after initialization,
duplicating the option struct, using sub-options (in the VO), and so on.
Introduce a mechanism that creates a copy of the global options (or
parts of it), and provides a well-defined way to update them in a
thread-safe way.
Most code can remain the same, just that all the component glue code has
to explicitly make use of it first.
There is still lots of room for improvement. For example, the update
mechanism could be better.
|
| |
|
|
|
|
|
|
| |
Normally I'd prefer a bunch of smaller functions with fewer parameters
over a single function with a lot of parameters. But future changes will
require messing with the parameters in a slightly more complex way, so a
combined function will be needed anyway. The now-unused "global"
parameter is required for later as well.
|
| |
|
|
|
|
|
|
|
|
|
| |
Now options are accessible through the property list as well, which
unifies them to a degree.
Not all options support runtime changes (meaning affected components
need to be restarted for the options to take effects). Remove from the
manpage those properties which are cleanly mapped to options anyway.
From the user-perspective they're just options available through the
property interface.
|
| |
|
|
| |
Well, almost unused.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a really old weird MPlayer feature. While the MPlayer requires
you to use the sub-option syntax in these cases, mpv "flattens" them to
normal options. The still-supported alternate sub-option syntax remains
a weird artifact that hopefully nobody uses.
For example you can do "-sub-text font=Foo:color=0.5" instead of using
"--sub-text-font=Foo --sub-text-color=0.5". For --sub-text this is an
accidental feature, but it used to be documented for
--demuxer-rawaudio and some others.
This should just be removed, but for now only print a warning to preempt
complaints from weird users wanting this feature back.
|
| |
|
|
|
|
| |
More appropriate. Originally it really was for automatically added
options, but now it even needed some stupid comments to indicate that
it was used for simply hiding options.
|
| |
|
|
|
|
|
| |
Targeted at scripts, which can do whatever they want with it. This comes
with the promise that they could get randomly broken any time.
See #977.
|
| |
|
|
|
|
|
|
|
|
|
| |
Update msg.c state immediately if a terminal or logging setting is set.
Until now, this was delayed until mp[v]_initialize() was called. When
using the client API, you could easily miss logged error messages, even
when logging was initialized early on by calling
mpv_request_log_messages().
(Properties can't be used for this either, because properties do not
work before mpv_initialize().)
|
| |
|
|
| |
Fixes #2165, more or less.
|
| |
|
|
| |
Is simpler and avoids exposing profile structs to a degree.
|
| |
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
| | |
|
| |
|
|
| |
Needed to copy the global option struct in the next commit.
|
| |
|
|
|
|
|
|
|
| |
bstr.c doesn't really deserve its own directory, and compat had just
a few files, most of which may as well be in osdep. There isn't really
any justification for these extra directories, so get rid of them.
The compat/libav.h was empty - just delete it. We changed our approach
to API compatibility, and will likely not need it anymore.
|
| |
|
|
| |
This is probably the last one, at least with my current configuration.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The code paths for setting options by string and by direct "raw" value
were too different, which resulted in some weird code. Make the code
paths closer to each other.
Also, use this to remove the weirdness in the mpv_set_option()
implementation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should fix some issues, such as not being able to set the
"no-video" option with MPV_FORMAT_FLAG.
Note that this changes semantics a bit. Now setting an option strictly
overwrite it, even if the corresponding command line option does not.
For example, if we change --sub to append by default, then setting the
"sub" option via the client API would still never append. (Oddly, this
also applies to --vf-add, which will overwrite the old value when using
the client API.)
I'm doing this because there's no proper separation between the command
line parser and setting an option using the MPV_FORMAT_STRING format.
Maybe the solution to this mess would be adding format aware code (i.e.
m_option_set_node) to every option type, and falling back to strings
only if needed - but this would mean that you couldn't set e.g. an
integer option using MPV_FORMAT_STRING, which doesn't seem to be ideal
either.
In conclusion, the current approach seems to be most robust, but I'm
open to suggestions should someone find that these semantics are a
problem.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This is only half-implemented: actually the option will first be
converted from mpv_node to its native type, then it's converted to a
string, and then back to its native type. This is because the option
API was made for strings and not anything else.
Other than being grossly inelegant, the only downside is probably with
string lists and key/value lists, which don't escape strings containing
syntax elements correctly.
|
| |
|
|
|
|
|
|
| |
Always pass around mp_log contexts in the option parser code. This of
course affects all users of this API as well.
In stream.c, pass a mp_null_log, because we can't do it properly yet.
This will be fixed later.
|
| | |
|
| | |
|
|
|
Since m_option.h and options.h are extremely often included, a lot of
files have to be changed.
Moving path.c/h to options/ is a bit questionable, but since this is
mainly about access to config files (which are also handled in
options/), it's probably ok.
|
