The internal stereo3d filter was removed due to being GPL only, and due
to being a mess that somehow used libavfilter's filter. Without this
filter, it's hard to remove our internal stereo3d image attribute, so
even using libavfilter's stereo3d filter would not work too well (unless
someone fixes it and makes it able to use AVFrame metadata, which we
then could mirror in mp_image).
This was never well thought-through anyway, so just drop it. I think
some "downsampling" support would still make sense, maybe that can be
readded later.
Signed-off-by: wm4 <wm4@nowhere>
Rename --stats to --load-stats-overlay and add an entry to options.rst
over the original commit.
Signed-off-by: wm4 <wm4@nowhere>
This removes all GPL only code from it, and that's the whole purpose.
Also happens to be much simpler.
The "deinterlace" option still sort of exists, but only as runtime
changeable option. The main change in behavior is that the property will
not report back the actual deint state. Or in other words, if inserting
or initializing the filter fails, the deinterlace property will still
return "yes". This is in line with most recent behavior changes to
properties and options.
So far, we had a thread-safe way to read options, but no option update
notification mechanism. Everything was funneled though the main thread's
central mp_option_change_callback() function. For example, if the
panscan options were changed, the function called vo_control() with
VOCTRL_SET_PANSCAN to manually notify the VO thread of updates. This
worked, but's pretty inconvenient. Most of these problems come from the
fact that MPlayer was written as a single-threaded program.
This commit works towards a more flexible mechanism. It adds an update
callback to m_config_cache (the thing that is already used for
thread-safe access of global options).
This alone would still be rather inconvenient, at least in context of
VOs. Add another mechanism on top of it that uses mp_dispatch_queue, and
takes care of some annoying synchronization issues. We extend
mp_dispatch_queue itself to make this easier and slightly more
efficient.
As a first application, use this to reimplement certain VO scaling and
renderer options. The update_opts() function translates these to the
"old" VOCTRLs, though.
An annoyingly subtle issue is that m_config_cache's destructor now
releases pending notifications, and must be released before the
associated dispatch queue. Otherwise, it could happen that option
updates during e.g. VO destruction queue or run stale entries, which is
not expected.
Rather untested. The singly-linked list code in dispatch.c is probably
buggy, and I bet some aspects about synchronization are not entirely
sane.
Tends to be somewhat glitchy if subtitles are enabled, and you enable
and disable tracks.
On error, this will disable --lavfi-complex, which will result in
whatever behavior.
The changes to path list options is basically getting rid of the need to
pass multiple paths to a single option. Instead, you can use the option
multiple times. The old behavior can be used by using the -set suffix
with the option.
Change some options to path lists. For example --script is now append by
default, and if you use --script-set, you need to use ":"/";" as
separator instead of ",".
--sub-paths/--audio-file-paths is a deprecated alias now, and will break
if the user tries to pass multiple paths to it. I'm assuming that if
these are used, most users will pass only 1 path anyway.
--opengl-shaders has more compatibility handling, since it's probably
rather common that users pass multiple options to it.
Also document all that in the manpage.
I'll probably regret this later, as it somewhat increases the complexity
of the option parser, rather than increasing it.
This affects options like --vf or --display-tags. These used a "*"
suffix to match all options starting with a specific name, and handled
the rest in the option parser. Change this to remove the "*" special
case, and require every option parser to declare a list of allowed
suffixes via m_option_type.actions.
The new way is conceptually simpler, because we don't have to account
for the "*" in a bunch of places anymore, and instead everything is
centrally handled in the CLI part of the option parser, where it's
actually needed.
It automatically enables suffixes like -add for a bunch of other
stringlist options.
This was an annoying option type. And still is. But at least it's on the
same level as m_option_type_print_fn now, and can probably cleaned up
further like it. Both types are for options that are only on the command
line, always have special handling (i.e. do something with them in
parse_commandline.c before passing them to the generic
m_config.c/m_option.c layers), and are m_options only for --list-options
and (oddly) the split_opt_silent() function.
Before this, options with co->data==NULL (i.e. no storage) were not
added to the bridge (except alias options). There are a few options
which might make sense to allow via the bridge ("profile" and
"include"). So allow them.
In command_init(), we merely remove the co->data check, the rest of the
diff is due to switching the if/else branches for convenience.
We also must explicitly error on M_PROPERTY_GET if co->data==NULL. All
other cases check it in some way.
Explicitly exclude options from the property bridge, which would be
added due this, and the result would be pointless.
All authors of the current code have agreed (as far as this commit
requires).
options.c/options.h will take more effort, because it contains all the
option declarations, and thus is touched extremely often.
m_option.c is technically still GPL, because of commit 2c82d5a1d8
(michael has agreed to LGPL, but only once the core of mpv is LGPL).
The geometry parsing code in m_option.c was originally by someone who
could not be reached. However, it was heavily rewritten anyway, and only
the syntax remains (i.e. not copyright-relevant).
parse_commandline.c contains a change by "adland" (commit 1d0ac71ae8),
who could not be reached - this this specific part is GPL only.
Fortunately, it matters only for DVD (and even then is more like a hack,
but whatever).
There are some other relevant changes, but they have all been reverted,
moved somewhere else, deleted, or replaced.
af_volume is deprecated, and so are its replaygain sub-options. To make
it possible to use replaygain without deprecated options (and of course
to make it available at all after af_volume is dropped), reintroduce
them as top-level options.
This also means that they are easily changeable at runtime by using them
as properties. Change the "volume" property to use the new update
mechanism as well.
We don't actually bother sharing the implementation between new and
deprecated mechanisms, as the deprecated one will simply be deleted.
For the from_dB() functions, we mention anders' copyright, although I'm
not sure if a mere formula is copyrightable. This will have to be
determined later.
This whole change is mostly untested. Our distributed human CI will take
care of it.
Also "announce" the plans to undeprecate it with changed semantics
later. The deprecation period is needed to warn script authors and
client API users (etc.) of the change.
This is done because everyone seems to expect --loop to loop the current
file, not the playlist. Even in cases when only 1 file is on the
playlist, the --loop-file semantics seem to be preferred.
Basically, see the example in input.rst.
This is better than the "old" vf-toggle method, because it doesn't
require the user to duplicate the filter string in mpv.conf and
input.conf.
Some aspects of this changes are untested, so enjoy your alpha testing.
Remove more stuff that was needed only for legacy suboptions.
One user-visible change is that parent-options like --tv are now not
visible anymore. They lead to a special error message when used before,
but now they're simply not part of the option list anymore.
Long planned. Leads to some sanity.
There still are some rather gross things. Especially g_groups is ugly,
and a hack that can hopefully be removed. (There is a plan for it, but
whether it's implemented depends on how much energy is left.)
Move the screensaver enable/disable determination to a central place,
and call it if the stop-screensaver property is changed.
Also, do not stop the screensaver when in idle mode (i.e. no file is
loaded).
Fixes#3615.
I'm not sure if this option affects anything or if it's a placebo,
especially since the VO thread is now registered with MMCSS. Still, I
think --priority=high may have helped back when I used mplayer2 on a
netbook. It's also possible that encoding-mode users would want to set
--priority=idle.
Anyway, it was one of the last M_OPT_FIXED options, so fix that.
If one of the audio output format options is set, brually reinit the
audio chain.
Since the audio-channels property is still mapped to the deprecated
read-only property, "options/audio-channels" currently has to be used,
e.g. "cycle-values options/audio-channels 2 7.1".
With the merging of options and properties, the mpv_set_option()
function is close to being useless, and mpv_set_property() can be used
for everything instead. There are certain conflicts remaining, which are
explained in depth in the docs. For now, none of this should affect
existing code using the client API.
Make mpv_set_property() redirect to mpv_set_option() before
initialization.
Remove some options marked as M_OPT_FIXED. The "pause" and "speed"
options cannot be written anymore without the playloop being notified by
it, so the M_OPT_FIXED does nothing. For "vo-mmcss-profile", the problem
was lack of synchronization, which has been added. I'm not sure what the
problem was with "frames" - I think it was only marked as M_OPT_FIXED
because changing it during playback will have no effect. Except for
pause/speed, these changes are needed to make them writable as
properties after mpv_initialize().
Also replace all remaining uses of CONF_GLOBAL with M_OPT_FIXED.
Use the new mechanism, instead of wrapped properties. As usual, extend
the update handling to some options that were forgotten/neglected
before. Rename video_reset_aspect() to video_reset_params() to make it
more "general" (and we can amazingly include write access to
video-aspect as well in this).
Setting the osc or ytdl properties will now load/unload the associated
scripts. (For ytdl this does not mean the currently played URL will be
reloaded.)
Also add a changelog entry for this, which also covers the preceding
work for --terminal.
Remove wrapper properties for OSD and video position updates, use the
new mechanism for them. We can mark the options directly. Update
behavior will work for more options (since I've casually marked more
affected options than the old less direct mechanism covered).
Extend the flag-based notification mechanism that was used via
M_OPT_TERM. Make the vo_opengl update mechanism use this (which, btw.,
also fixes compilation with OpenGL renderers forcibly disabled).
While this adds a 3rd mechanism and just seems to further the chaos, I'd
rather have a very simple mechanism now, than actually furthering the
mess by mixing old and new update mechanisms. In particular, we'll be
able to remove quite some property implementations, and replace them
with much simpler update handling. The new update mechanism can also
more easily refactored once we have a final mechanism that handles
everything in an uniform way.
There were multiple values under M_OPT_EXIT (M_OPT_EXIT-n for n>=0).
Somehow M_OPT_EXIT-n either meant error code n (with n==0 no error?), or
the number of option valus consumed (0 or 1). The latter is MPlayer
legacy, which left it to the option type parsers to determine whether an
option took a value or not. All of this was changed in mpv, by requiring
the user to use explicit syntax ("--opt=val" instead of "-opt val").
In any case, the n value wasn't even used (anymore), so rip this all
out. Now M_OPT_EXIT-1 doesn't mean anything, and could be used by a new
error code.
This meant "cannot be used as per-file option" (wrt. playlist items).
Doesn't make too much sense anymore, especially given how obscure
per-file options are.
I decided that it's too much work to convert all the VO/AOs to the new
option system manually at once. So here's a shitty hack instead, which
achieves almost the same thing. (The only user-visible difference is
that e.g. --vo=name:help will list the sub-options normally, instead of
showing them as deprecation placeholders. Also, the sub-option parser
will verify each option normally, instead of deferring to the global
option parser.)
Another advantage is that once we drop the deprecated options,
converting the remaining things will be easier, because we obviously
don't need to add the compatibility hacks.
Using this mechanism is separate in the next commit to keep the diff
noise down.
Instead of requiring each VO or AO to manually add members to MPOpts and
the global option table, make it possible to register them automatically
via vo_driver/ao_driver.global_opts members. This avoids modifying
options.c/options.h every time, including having to duplicate the exact
ifdeffery used to enable a driver.
With the conversion from sub-options to global options, this becomes
useless. This change also comes slightly too soon, because not all VOs
have been changed yet.
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>.
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.
Positional parameters cause problems because they can be ambiguous with
flag options. If a flag option is removed or turned into a non-flag
option, it'll usually be interpreted as value for the first sub-option
(as positional parameter), resulting in very confusing error messages.
This changes it into a simple "option not found" error.
I don't expect that anyone really used positional parameters with --vo
or --ao. Although the docs for --ao=pulse seem to encourage positional
parameters for the host/sink options, which means it could possibly
annoy some PulseAudio users.
--vf and --af are still mostly used with positional parameters, so this
must be a configurable option in the option parser.
Instead, add a hacky OPT_ASPECT option type, which only exists to accept
a "no" parameter, which in combination with the "--no-..." handling code
makes --no-video-aspect work again.
We can also remove the code in m_config.c, which only existed to make
"--no-aspect" (a deprecated alias) to work.
OPT_ALIAS redirects the options at a higher level, instead of
introducing "duplicate" options with different name but same backing
storage. This uses the OPT_REPLACED mechanisms - only the deprecation
warning had to be made conditional. Note that e.g. --no-video still
works, because the "--no-..." redirection and OPT_ALIAS are orthogonal.
The deprecated --sub -> --sub-file alias had to be dropped, because it
essentially conflicts with --no-sub. If anyone complains, this could
probably still be undone by letting m_config_find_negation_opt do a
special mapping for --no-sub. (Which would be dumb, but simple and
effective.)
This is basically dead code, and even the commit that added this code 4
years ago said that this should be for debugging only.
(Though it is possible that the clamp callback was used for something
else, and then unused again. Also, some of the clamping code remains and
is used for internal checking, e.g. clamp_double().)
It's actually redundant with whether m_option_type.free is set. Some
option types were flagged inconsistently. Its only use was for running
an additional sanity check without any real functionality.
This commit adds an --audio-channel=auto-safe mode, and makes it the
default. This mode behaves like "auto" with most AOs, except with
ao_alsa. The intention is to allow multichannel output by default on
sane APIs. ALSA is not sane as in it's so low level that it will e.g.
configure any layout over HDMI, even if the connected A/V receiver does
not support it. The HDMI fuckup is of course not ALSA's fault, but other
audio APIs normally isolate applications from dealing with this and
require the user to globally configure the correct output layout.
This will help with other AOs too. ao_lavc (encoding) is changed to the
new semantics as well, because it used to force stereo (perhaps because
encoding mode is supposed to produce safe files for crap devices?).
Exclusive mode output on Windows might need to be adjusted accordingly,
as it grants the same kind of low level access as ALSA (requires more
research).
In addition to the things mentioned above, the --audio-channels option
is extended to accept a set of channel layouts. This is supposed to be
the correct way to configure mpv ALSA multichannel output. You need to
put a list of channel layouts that your A/V receiver supports.
We have a warning mechanism for removed and for replaced options, but
none yet for options which have been simply deprecated.
For the following commit.
(Fun fact: just adding the m_option field increases binary size by
14KB.)
If a mpv_node wrapped a string, the behavior was different from calling
mpv_set_property() with MPV_FORMAT_STRING directly. Change this.
The original intention was to be strict about types if MPV_FORMAT_NODE
is used. But I think the result was less than ideal, and the same change
towards less strict behavior was made to mpv_set_option() ages ago.
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().)
Use OPT_CHOICE_C() instead of the custom parser. The functionality is
pretty much equivalent.
(On a side note, it seems --video-stereo-mode can't be removed, because
it controls whether to "reduce" stereo video to mono, which is also the
default. In fact I'm not sure how this should be handled at all.)
Remove the colorspace-related top-level options, add them to vf_format.
They are rather obscure and not needed often, so it's better to get them
out of the way. In particular, this gets rid of the semi-complicated
logic in command.c (most of which was needed for OSD display and the
direct feedback from the VO). It removes the duplicated color-related
name mappings.
This removes the ability to write the colormatrix and related
properties. Since filters can be changed at runtime, there's no loss of
functionality, except that you can't cycle automatically through the
color constants anymore (but who needs to do this).
This also changes the type of the mp_csp_names and related variables, so
they can directly be used with OPT_CHOICE. This probably ended up a bit
awkward, for the sake of not adding a new option type which would have
used the previous format.
In the past it happened quite often that flag options (yes/no) were
changed to choice options (yes/no/some more). The problem with this was
that while flag options don't need a parameter, this wasn't the case
with choice options. A hack was introduced to compensate for this:
setting M_OPT_OPTIONAL_PARAM on the option, and an empty string ("") was
added as choice, so that the choice could be used like a flag. So, for
example, "--mute" would set the choice "".
Fix this by 1. not requiring a parameter if there's a "yes" choice, and
2. redirect an empty parameter to "yes". The effect is that a choice
option with the choices ["yes", "no"] is pretty much equivalent to a
flag option.
