I would have been fine with this, but now I want to add another flag,
and the duplication would become more messy than having a strange
function for deduplication.
The property observation mechanism turns properties into integer IDs for
fast comparison. This means if two properties get the same ID, they will
receive the same notifications. Use this to make properties under
options/ receive notifications. The option-property bridge marks
top-level properties with the same name as the options.
This still might not work in cases the C code sets values on options
structs directly.
On x11, you can change the fullscreen via the window manager and without
mpv's involvement. In these cases, the internal fullscreen flag has to
be updated.
The hack used for this didn't really work properly. Change it
accordingly. The important thing is that the shadow copy of the option
is updated. This is still not really ideal.
Fixes#3570.
The documentation claims that --video-unscaled will still perform
anamorphic adjustments, and it rightfully should. The current reality is
that it does not, because the video-unscaled size was based on the wrong
set of variables. (encoded width/height instead of nominal display
width/height)
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".
The intention is to give libmpv users as much flexibility to load
scripts as using mpv from CLI, but without restricting libmpv users from
having to decide everything on creation time, or having to go through
hacks like recreating the libmpv context to update state.
Basically, make use of all the new code.
Unfortunately, the new code and it's "compromise semantics" with the old
behavior before the options/properties merge bites back: this
vid/aid/sid, deinterlace, and video-aspect properties have neutral
default settings (such as "auto"), but return the current value during
playback, so we would unnecessarily force this value when playback is
resumed. So leave those as they are.
Also, the colormatrix options were removed a long time ago.
Add this flag where needed. You shouldn't be able to set e.g. config-dir
in these situations.
Remove the mpctx->initialized check from the property/option bridge,
since it's in use strictly only after initialization. Likewise, the
apply-profile command doesn't need to check this.
When we rotate the inmage by 90° or 270°, chroma width and height need
to be swapped.
Fixes#3568.
But is the chroma sub location correct? Who the hell knows...
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.
mp_new_client() blatantly accessed some mutex-protected state outside of
the mutex.
The destruction code is in theory OK, but with changes in the following
commits it'll be a bit hard to guarantee that it stays this way. Add a
simple flag that makes adding new clients impossible, so that having no
clients after shutdown_clients() remains guaranteed.
Instead of rechecking the timers every time after an event is read, do
it only once the event queue is empty. This is probably slightly more
efficient, and facilitates the next commit.
This is the actual decoder output, with no overrides applied. (Maybe
video-params shouldn't contain the overrides in the first place, but
damage done.)
This really shouldn't be in vd_lavc.c - move it to dec_video.c, where it
also applies aspect overrides. This makes all overrides in one place.
The previous commit contains some required changes for resetting the
image parameters change detection (i.e. it's not done only on video
aspect override changes).
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).
A recent change merged the window-scaler option and property, but forgot
that the option is float for some reason, while the property uses
double. This led to undefined behavior. Fix it by changing the option
to double too.
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).
My original idea was making mpv_initialize() a no-op, but it seems this
can't happen after all. The problem is especially with subtle
interactions in option parsing (basically all pre-parse options).
Instead, I might go into the opposite direction, and add a new API
function that takes over the role of mpv_create+mpv_initialize, and
which will take a list of options. This list will be for the purpose
of setting options that can be set only at initialization time (such
as config-dir). This would also make it more uniform with the command-
line player initialization.
Maybe.
In any case, for now revert parts of commit 453fea87 to remove the
initialization-related freedoms it added. Fortunately, this wasn't
released yet, so we remove it from the API as if it never happened.
(The rest of that commit is still fine, just not the additional
freedom.)
Move the MPV_LEAK_REPORT env query to mp_create(), where it will also be
used by the client API (it might be helpful, so why not). The same
applies to MPV_VERBOSE.
The prepare_playlist() call doesn't need to be in mp_initialize() and
can just be in mp_play_files() to reduce the size of mp_initialize().
Also, remove wakeup_playloop(), which is 100% redundant with
mp_wakeup_core_cb().
So client API users don't have to care about whether to set this before
or after mpv_initialize().
We still don't enable terminal at any point before mpv_initialize(),
because reasons.
This also subtly changes some behavior how terminal options are applied
while parsing. This essentially reverts the behavior as it was reported
in issue #2588. Originally, I was hoping to get rid of the pre-parse
option pass, but it seems this is absolutely not possible due to the way
config and command line parsing are entangled. Command line options take
priority over configfile options, so they have to be applied later - but
we also want to apply logging and terminal options as specified on the
command-line, but _before_ parsing the config files. It has to be this
way to see config file error messages on the terminal, or to hide them
if --no-terminal is used. libmpv considerations also factor into this.
Until now, the terminal thread always sent a quit command if the
terminal thread was torn down (whether it happened via terminal_uninit()
or a quit signal). This is not so good if we want to enable toggling
terminal use at runtime, since disabling the terminal would always make
the player quit. So we want terminal_uninit() not to send quit.
This can be easily fixed by using the "death byte" sent to the pipe used
for thread tear-down to indicate whether it was caused by a signal or
terminal_uninit().
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.
--quiet can be always set - the playloop checks it whenever rendering
the status line. Nothing special about it.
The ytdl- options are simply refetched by the Lua script every time a
stream is opened, so it makes sense to be able to change them at runtime
as well.
The VO options don't have a real reason to be marked with it anymore.
For audio files, this is identical to time-pos (except read-only).
For audio-video files, this returns the audio position. Unlike
time-pos, this is not quantized to a video frame.
For video-only files, this property is unavailable.
This was in the parser code all along. As far as I can tell, *cp was
intended. There is no need to check cp for NULL (nor does it make any
sense to do so every time around the loop) for AF_CONTROL_COMMAND.
However, s->matrixstr can be NULL, so checking for that separately is in
order.
For stereo and typical L/R-first channel arrangements, this avoids
undesirable phasing artifacts, especially obvious when speed is changed
and then reset. Without this, there is a very audible change in the
stereo field even when librubberband is no longer actually making any
speed changes.
