Disabled by default because it breaks sub-seek and playback in cases
where the user changes play-dir from + to - during runtime and past
"seen" events need to be re-rendered.
Available since dcc9eb722e
Elements are not parented to the add list, as they are directly copied
to the target list. Therefore, we need to clean them up manually.
Fixes: 1f5a67d8fa
Some properties, like `${decoder-list}`, are resource-intensive to
expand. Prevent fuzzing from generating strings with excessive
expansions to encourage shorter test cases.
Expanding properties on each playback frame for `osd-msg1` can be
demanding. However, in regular use cases, this typically isn’t an issue,
so implementing a caching solution wouldn’t be practical in real
scenarios.
Fixes timeouts on OSS-Fuzz.
This adds --osd-bar-marker-style option which can be used to
customize OSD bar marker style. In addition to the existing triangle
style, a new style option is added to draw markers as lines.
c4e8c36071 made any usage of --geometry
implicitly center the window on the screen after a resize even if the
user did not pass any x/y arguments to the option. At the time, this was
probably wanted since --geometry was primarily a startup option and
likely the window wouldn't be centered on x11 without moving
coordinates. Times have changed since then and we support full runtime
--geometry changes on all the relevant platforms but it comes with this
automatic window centering behavior (except on wayland of course hah).
It's better to make such window centering optional and user controllable
since it is entirely reasonable that someone wants --geometry=50% to
just resize and not move anything. It's already trivial for a person
that does want to move the window to just add their coordinates to the
--geometry command so there's no reason to continue to force this
behavior since it is less flexible.
Instead, move the window centering stuff out of m_geometry_apply into
vo_calc_window_geometry. We give the power to the caller to whether or
not to force centering the window here and all usage of the function is
updated to simply call it with false for now. Additionally,
--force-window-position being set will also center the window like
before. All that is left is for the windowing code to take advantage of
this. See subsequent commits.
Since f411f3145b, these properties
no longer change with each loop. This however caused a regression
on the behavior of resetting loop count by resetting these
properties.
Previously, after the loop count is decreased, it is possible to
reset these properties back their original values and thus reset
the remaining loop count. Currently, because setting properties
has no effect if the new value is the same as the existing value
(which no longer changes), resetting these properties does nothing,
and remaining-*-loops (which are read-only) remain unchanged.
There is no way to reset them other than temporarily setting them
to a different value, which is awkward.
Fortunately, this can be fixed by marking these properties as
force_update, which always notifies changes when being set.
It is unclear whether there actually is any usecase for this option
which isn't better served by sub-ass-use-video-data and/or LayoutRes
overrides, but prior to the introduction of sub-ass-use-video-data
it was possible to pass along storage resolution while faking an
aspect ratio of 1:1.
sub-ass-video-aspect-override=1 combined with sub-ass-use-video-data=all
now makes this possible again.
The uper limit of a 10:1 aspect matches
the general video-aspect-override option.
The naming for "blur-compat" was misleading since the setting
actually affects more than just blur affects. Additionally
forwarding storage resolution but forcing an aspect ratio
of 1.0 for the video is likely to result in odd rendering
and there’s no known usecase for it.
Both options control which video properties are exposed to libass
so to fix the aforementioned issues merge these settings into one
tri-state sub-ass-use-video-data.
The default V keybind now cycles through all states of
use-video-data instead of toggling vsfilter-aspect-compat.
Resolves: https://github.com/mpv-player/mpv/issues/10680
This makes --input-ipc-client work on Windows.
To use this feature, a parent process needs to create a connected named pipe,
wrap the server handle in a CRT fd, and then spawn mpv as a child process
with the fd as the --input-ipc-client parameter.
The process can then communicate through the client handle.
The named pipe must be created duplex with overlapped IO and inheritable
handles.
Unlike most other platforming backends, wayland has its own specific
sub_options struct. 027ca4fb85 originally
introduced this and some more options were added later, but in
retrospect it's an unneccesary complication. There are already x11,
and windows-specific options within vo_opts. In fact, there actually is
a wayland one in there already as well (wayland-content-type) so it's
split btween two places. The wayland code already has to handle vo_opts
and it is already handles callbacks if needed. There is no advantage to
having a separate wayland-specific sub_options struct which is stuck
with whatever you set at init time.
So solve everything by deleting the old sub_options struct, moving it to
vo_opts and make some minor option naming changes for clarity (i.e.
adding a 'wl_' in front of the name). This simplifies the wayland common
code and also makes it have more functionality since you get runtime
updates for free.
This will allow reiniting the VO when more options are changed without
hardcoding them in options.c
Also reinit the VO when changing --gpu-debug and --gpu-sw.
These were all deprecated in mpv 0.37.0 or earlier and are not
considered common enough options to warrant keeping the deprecated
mapping longer. Since demux_cue had only a single option in it, the
entire option substract is removed. This can be readded later if someone
wants to introduce a specific option to it again.
Previously, using m_option_type_alias required that the alias have the
full name of the option value. This is limited if you are reusing the
same opts struct in different sub options. Fix this by add an additional
field to m_option to signal whether or not prefixes should be taken into
account for the alias option. Instead of blindly using whatever is
stored in opt->priv as the name, we can construct the desired option
name for either case (using the prefix or not).
It makes sense to allow the first part of the list. There are
warnings about excessive elements already. This also allows overriding
elements with the same label.
Since 995c47da9a, setting --mute=auto has
been equivalent to --mute=no. It was formally documented later in
79e20ff485. This is an old legacy relic
and the auto choice popping up during auto completion could be confusing
to users who aren't aware of the history. Remove it for good and convert
the option to a proper boolean.
Limit list entries to 100. obj_settings_list is not designed to hold
more items, and it quickly starts taking ages to add all items. 100 is
more than enough.
Fixes 30s timeout on OSS-Fuzz and generally fixes possible DoS on mpv.
Allow configuring whether to print the media-title, the filename or both
(as `<title> (<filename>)`) in show-text ${playlist}, the OSC playlist
and in the playlist selector.
Showing only titles hides information when files are badly tagged, or
when it hides the track numbers of album songs. But showing filenames is
not as useful as titles e.g. when playing URLs with media titles. This
option lets the user choose which one to show, or show both if switching
is inconvenient.
The OSC's playlist_media_title script-opt is removed because this option
is better since it works everywhere after configuring it once.
Closes#11653.
Also show the full URLs of playlist entries instead of their basenames
in osc.lua and select.lua, consistently with mp_property_playlist().
For simplicity, this just checks if entries contain :// instead of
replicating all of mp_is_url().
Co-authored-by: Kacper Michajłow <kasper93@gmail.com>