Since for mpv CLI, the player state is a singleton, full prefetching is
a bit tricky. We do it only on the demuxer layer.
The implementation reuses the old "open thread". This means there is
significant potential for regressions even if the new option is not
used. This is made worse by the fact that I barely tested this code.
The generic mpctx_run_reentrant() wrapper is also removed - this was its
only user, and its remains become part of the new implementation.
The property calls will always succeed anyway. On the other hand, the
error handling is kind of incomplete (doesn't check setting ab-loop-a
when ab-loop-b is also set), so drop this code.
Was intended to show a "nice" message on edition switching. In practice,
the message was never visible. The OSD code checks whether a demuxer is
loaded, and if not, discards the message - meaning if the OSD code
happened to run before the demuxer was fully loaded, no message was
shown. This is apparently a regression due to extensions to the OSD and
the situations in which it can be used.
Remove the broken code since it's too annoying to fix. Instead, a
default property message will be shown, which is a bit uglier, but
actually not too unuseful.
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.
For some reason, some types of accesses didn't warn, for example when
using mp.observe_property() in Lua. This was because the deprecation
handling code explicitly checks certain accesses. I'm not quite certain
why it was done this way. Just make it warn always.
This could be backported to the current release, if we cared.
As threatened by the API changes document.
We can actually keep the deprecated --playlist-pos and --cache options,
since they are aliases and not used by the corresponding properties.
They are inconsistent, but do no harm. Keep them for now for the sake of
the command line user.
mpv_identify.sh partially stopped working, because it was never updated.
The shell magic can't deal with property names that contain "/", so we
can't replace "samplerate" with "audio-params/samplerate" - just remove
these properties. (How about you use ffprobe?)
Run "playlist-remove current" while the last playlist entry is being
played stopped playback. Fix this and return to the first entry instead.
Fixes#3808.
--reset-on-next-file=all triggers m_config_backup_all_opts(), which
backups all options (even deprecated ones). Later, when the option
values are reset with m_config_restore_backups(), mp_on_set_option() is
called, which in turn calls mp_property_do_silent(), which in turn will
call mp_property_generic_option() and m_config_get_co(), which triggers
the deprecation message.
Unfortunately there's no good way to determine whether an option has
actually changed (there's no option value compare operation), so the
deprecated options have to be set no matter what. On the other hand, we
can't pass through additional flags through the property layer. So we
add a dumb global flag to silence the deprecation warnings in these
cases.
Fortunately m_config_get_co_raw() works to silence the warnings.
m_config_get_co() also resolves aliases (deprecated and non-deprecated),
but aliased options are handled differently by the option-property
bridge, so we don't need to do that here, so the only purpose of it is
to trigger a warning for deprecated (non-alias) options.
The tv-freq options and properties use different types, thus must be
treated as incompatible. Fixes an assertion with reset-on-next-file=all,
which tries to set the option.
Fixes#3708.
Don't require special property code for handling updates, and simply use
the UPDATE_AUDIO flag instead. Also make runtime changes to
--audio-client-name take effect.
Now a reload requested by an AO behaves in exactly the same way as
changing an AO-related options (like --audio-channels or
--audio-exclusive). This is good for testing and uniform behavior. (You
could go as far as saying it's a necessity, because the spotty and
obscure AO reload behavior is hard to reproduce and thus hard to test at
all.)
This affects changing audio configuration options. Explicitly flush and
uninitialize the audio output first before doing the rest. This should
ensure all state attached to the audio output is discarded and not used
during the reconfiguration.
Also add a comment to the reinit_audio_filters() call. It doesn't
necessarily restore the audio chain fully, but makes sure a seek is
issued if the amnount of buffered audio discarded was huge enough to
cause "problems".
If we really want client API users to use mpv_set_property() instead of
mpv_set_option(), then compatibility handling of deprecated options
should be included. Otherwise, there's the danger that client API users
either break too early (and without a warning), or mpv_set_option() will
continue to have a reason to exist.
"seek -10 absolute" will seek to 10 seconds before the end. This more or less
matches the --start option and negative seeks were otherwise useless (they just
clipped to 0).
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.
The last commit was fine - just making some enhancements.
Rename the function to parse_node_chapters(), since it really has not
much to do with Lua.
Don't use len<0 as check whether it makes sense to set chapters, and
instead check for mpctx->demuxer (that includes the possibility to set
chapters e.g. within a preload hook, but after chapters are initialized
from the demuxer).
Return M_PROPERTY_ERROR instead of M_PROPERTY_OK if the mpv_node has the
wrong type.
It's ok if a chapter has no title, so change the checks accordingly.
Remove a Yoda condition.
Notify that chapter metadata might have changed with mp_notify() (the
chapter list itself is already taken care by generic code).
Fix leaking the metadata allocations of the new chapter list.
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.
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.
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.
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.)
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).
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.
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.
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.
Some properties had a different type from their equivalent options (such
as mute, volume, deinterlace, edition). This wasn't really sane, as raw
option values should be always within their bounds. On the other hand,
these properties use a different type to reflect runtime limits (such as
range of available editions), or simply to improve the "UI" (you don't
want to cycle throuhg the completely useless "auto" value when cycling
the "mute" property).
Handle this by making them always return the option type, but also
allowing them to provide a "constricted" type, which is used for UI
purposes. All M_PROPERTY_GET_CONSTRICTED_TYPE changes are related to
this.
One consequence is that you can set the volume property to arbitrary
high values just like with the --volume option, but using the "add"
command it still restricts it to the --volume-max range.
Also deprecate --chapter, as it is grossly incompatible to the chapter
property. We pondered renaming it to --chapters, or introducing a more
powerful --range option, but concluded that --start --end is actually
enough.
These changes appear to take care of the last gross property/option
incompatibilities, although there might still be a few lurking.
For some odd reason, value ranges for the window-scale option and
property are different, and the property has a more narrow range. Change
it to the option range.
Also store the window-scale value into the option value when setting the
property, so it will be persistent if the window is closed and reopened.
Conflicts with the "playlist-pos" property. They're really a bit too
different, and since the --playlist-pos option is relatively new and
obscure, just rename it to get this out of the way.
Make the option type exactly the same as the underlying option's one. I
think this has no user-visible consequences, but makes more sense for
the option-property bridge.
These are not mapped as property, so the option-property bridge has to
skip them. Do this automatically if a property is not found. I know that
this affects --quiet and --really-quiet, but in theory there could be
more.
All option write accesses are now put through the property interface,
which means runtime option value verification and runtime updates are
applied. This is done even for command line arguments and config files.
This has many subtle and not-so-subtle consequences. The potential for
unintended and intended subtle or not-subtle behavior changes is very
large.
Architecturally, this is us literally jumping through hoops. It really
should work the other way around, with options being able to have
callbacks for value verification and applying runtime updates. But this
would require rewriting the entirety of command.c. This change is more
practical, and if anything will at least allow incremental changes.
Some options are too incompatible for this to work - these are excluded
with an explicit blacklist.
This change fixes many issues caused by the mismatch between properties
and options. For example, this fixes#3281.
This does 3 kinds of changes:
- change sleeptime=x to mp_set_timeout()
- change sleeptime=0 to mp_wakeup_core() calls (to be more explicit)
- change commands etc. to call mp_wakeup_core() if they do changes that
require the playloop to be rerun
This is preparation for the following changes. The goal is to process
client API requests without having to rerun the playloop every time. As
of this commit, the changes should not change behavior. In particular,
the playloop is still implicitly woken up on every command.
