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.)
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.
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.
They're useless, and I have no idea what they're actually supposed to do
(wrt. pending input processing changes).
Also remove their implicit uses from the IPC handlers.
This also lets you just do "mpv --hwdec file.mkv", with the minor caveat
that the legacy syntax "--hwdec val" or "-hwdec val" (without "=") does
not work as expected anymore.
Minimal support just for testing.
Only the window surface creation (including size determination) is
really platform specific, so this could be some generic thing with
platform-specific support as some sort of sub-driver, but on the other
hand I don't see much of a need for such a thing.
While most of the fbdev usage is done by the EGL driver, using this
fbdev ioctl is apparently the only way to get the display resolution.
The cuvid decoder already knows how to copy back to system memory
if NV12 frames are requested, and this will happen if the decoder
is used without the hwdec.
For convenience, let's add a wrapper hwdec so people don't have
to explicitly pick the cuvid decoder if they want this behaviour.
Mostly untested.
This is not compatible. It removes the URL fields for track range and
cdrom speed (what did this even do). The device is not not to be
prefixed with an additional "/" if it's put into the URL. I can't be
bothered to keep these things compatible, just rip your damn CDs
instead.
And introduce a global option which does this. Or more precisely, this
deprecates the global wasapi and coreaudio options, and adds a new one
that merges their functionality. (Due to the way the sub-option
deprecation mechanism works, this is simpler.)
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.
Whitelisting supported codecs is (probably) still better than just
allowing everything, given the weird FFmpeg API. I'm also assuming
Libav doesn't even have the codec ID, but I didn't check.
Also add a --teletext-page option, since otherwise it decodes every
teletext page and shows them in succession.
And yes, we can't use av_opt_set_int() - instead we have to set it as
string. Because FFmpeg's option system is terrible.
With the recent vo_opengl changes it doesn't do anything anymore.
I don't think a deprecation period is necessary, because the command
was always marked as experimental.
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>.
And replace the sort-of duplicated explanations.
(It's a bit funny to use weblinks to the generated web version of itself
instead of proper RST links, but I think I don't care.)
The --cache option and cache property conflict, so one of them has to be
renamed. The option is probably used frequently, so initiate
deprecation/rename of the property.
Deprecated in favor of user-shaders, which are functionally equivalent
but superior. (Except in the case of scaler-shader, which has no direct
replacement, but it turned out to be a very unpopular feature either way
- most custom scalers don't fit into the mpv kernel infrastructure and
are therefore implemented as user shaders either way)
Signed-off-by: wm4 <wm4@nowhere>
Make some existing properties behave more like options. This mostly
means they don't deny access if the associated component is not active,
but redirects to the option.
One kind of fishy change is that we apply --brightness etc. only if
they're not set to the default value. This won't necessarily work with
--vo=xv, but affects only cases where 1. the Xv adapter has been changed
to non-defaults, and 2. the user tries to reset them with mpv by passing
e.g. --brightness=0. We don't care about Xv, and the noted use-case is
dumb, so this change is acceptable.
