It's useful for user scripts to be able to use the same ytdl binary that
ytdl_hook uses without having to replicate ytdl_hook's process of
searching for the ytdl binary.
Some user scripts might also find it useful to be able to access ytdl's
json output that the ytdl_hook already receives, sparing user scripts
from having to make a duplicate ytdl binary invocation to get the json
output.
Providing just the json output is not enough though, as ytdl doesn't communicate
errors though it -- if an error occurs, ytdl provides no json output and instead
prints to stderr. So without stderr, there is no way for user scripts to figure
out why ytdl has failed: no such username / video id, the channel is not live
yet, etc. Because of that, the entire result of the subprocess call is provided
to the user scripts, containing stdout (json), stderr, ytdl's exit code, etc.
There's no advantage in using the forced version here. It is a leftover
from when this was an external script and forced was necessary to bind
key sequences reliably until 3f83671f20.
This results in all image params not being restored even if only one is
unknown. In particular params->color.hdr isn't cleared, causing
overblown color for some samples.
It should be safe to restore even unknown values.
mp_image_params_guess_csp will handle that.
This reverts commit 3acd253e89.
With the previous change, it is possible that the mp_hwdec_ctx contains
a list of known supported hwuploads. Take this into account when adding
to the p->fmts list. We want to be sure to select only something that is
actually possible to use. If the hwdec does not implement
supported_hwupload_formats, then all are assumed to work.
This is probably fringe, but I encountered it on my machine. The
hwupload filter happily does conversions all on the GPU side if
possible. Makes sense. However, it turns out that there is a difference
between e.g.yuv420p -> vaapi[bgr0] and a vaapi[yuv420p] -> vaapi[bgr0].
The latter worked without any issues on my hardware, but the first
example fails. To remedy this, we need to also do hardware uploads
during probing against formats and track what actually works (i.e.
vaSurfaceExportHandle). This commit only implements it in vaapi since it
is the only known place where this edge case is relevant. But other
hardware decoding drivers could easily add support later if needed.
It's a bit roundabout, but we were doing this incorrectly before. The
format table alone isn't good enough because it is possible the the
compositor may advertise different formats for a specific device which
is a subset of the format table. What we need to do is add formats based
on the array in tranche_formats. Note that it is possible for the
compositor to send multiple tranches (was not able to simulate this but
it's allowed by the protocol). For mpv, we only care about the very
first one which is supposed to be the most preferred one. The compositor
can also send the entire chain of events (main device, format_table,
tranches, etc.) all over again. We handle this in the wayland code, but
handling this in mpv's core code isn't done. e.g. say a format in use
was suddenly no longer supported. We ideally should do a full reconfig
in this case, but that gets complicated and is pretty niche so save that
for another day. Multiple GPUs isn't taken into account either. We just
pick the first one. Not strictly correct, but close enough for us.
Fixes#14544.
The linux-dmabuf protocol gives us the main device being used. Using
that along with some drm code, we can get what drm formats are supported
by the GPU. This is pretty crude as we just check against the first
primary plane we find and hope for the best. Also the protocol can
technically update formats at any time (e.g. if the device changes). We
do update what gets stored in wl->gpu_formats but the next commit won't
make any attempt to address this hypothetical scenario. It's complicated
and this is better than nothing. In practice, this will only work
against one constant device during VO runtime. Additionally, we can add
this check to ra_compatible_format to filter out additional unsupported
formats.
ASS_OVERRIDE_BIT_STYLE includes ASS_OVERRIDE_BIT_ATTRIBUTES, which we
don't want.
This prevents --sub-ass-override=force from overriding attributes such
as bold, italics, underline or strikeout to mpv defaults.
Apparently for an user mpv would crash on startup if built with asan and
mpv attemps to load mpv-mpris. Just set --no-config so we don't load
anything external since this is more correct anyway.
With --msg-module the select menu also highlights the "statusline" on
the next line. Fix this by resetting the color before \n instead of
after it.
This requires changing all log code to not preemptively add a newline,
which is actually simpler, though we have to modify the messages
received with log-message which already contain a newline.
When I introduced the behaviour of `auto` trying every hwdec down the list
instead of giving up after the first one fails, I forgot to update this
part of the docs.
Ideally it should be fast, it is on VO thread and steals precious frame
time budget. Looks like this is one of the main reasons why
display-resample on higher refresh rate displays is too slow.
Even Debian stable has them, so no need to keep compatible with ancient
versions.
Note that this does not change runtime version requirement for Vulkan.
Fixes: https://github.com/mpv-player/mpv-build/issues/234
On platforms where it is unstable/experimental, it is disabled behind
environmental variable, so safe to probe it there too.
Fixes usage of hwdec=yes with gpu-api=vulkan, where hwdec would be not
enabled. Position it after older and more stable variants. That means
the -copy variant of the other API will likely be prefered.
Also avoid regular white/black, because it is often the terminal
background and invisible as foreground color.
Change debug messages to blue while at it to differentiate them from
trace ones.
These options accept an empty value within their choices. If the user
didn't add manually input a quote before completing them, add quotes
automatically so that the blank value can actually be used.
This allows Tab completing them in the console and zsh, and using cycle
scale.
jinc is also added to --tscale=help's output, while before it was
missing because validate_scaler_opt() skipped filter windows with the
same name as a filter kernel, but the jinc kernel was skipped with
--tscale because it is polar.
Also rename the field to appropriately reflect what it is supposed to be
used for. The only other use of this was to search for ordered chapter
sources, and that makes no sense for mkv files from stdin.
This also fixes autocreate-playlist loading in the current directory
when the input file is stdin.
The comment was probably only ever true for x11, and it currently isn't
true anymore. X11 WSI used to return VK_SUBOPTIMAL_KHR in
vkQueuePresentKHR and vkAcquireNextImageKHR before, but as of
2b885b233f
it only returns VK_SUBOPTIMAL_KHR in vkAcquireNextImageKHR for
performance reasons. This makes it so that we don't have to tolerate
suboptimal swapchain configurations for the sake of smoother resizing.
On top of that, not recreating swapchain when it was suboptimal, it
also prevented mpv from being directly scanned out when fullscreened on
Wayland compositors. On Wayland, the preferred modifier from the wsi
may change depending on whether the window is fullscreened or not for
direct scan out. If mpv is fullscreened but not using modifiers that
can be directly scanned out, mpv will be receive VK_SUBOPTIMAL_KHR from
WSI and should recreate swapchain to use the right modifier with the
format mpv picked. mpv will always get the format it picks, WSI can't
give us a different format. This allows for recreating the swapchain
with modifiers that will allow mpv to be directly scanned out when the
window is fullscreened spanning an output on Wayland.
I checked X11 and Wayland myself to have no regressions when resizing,
and others have checked Windows and Mac to have no regressions.
With this, direct scanout with Vulkan on Wayland should just work.
You might also need https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31122
if your compositor enables explicit syncronization via
linux-drm-syncobj-v1.
ALSA API reports -EPIPE even when the the device is lost, which we
currently always assume to be an XRUN. If we assumed XRUN 10 times and
didn't manage to recover, just consider the device lost and try to
reconnect. Allows ao_alsa to recover from alsa server being killed then
reinitialized. And even in the worst case, this should be better than
the status quo of mpv attempting to prepare a PCM device indefinitely
until the user restarts mpv.
This is admittedly not ideal, and I don't think the -EPIPE hack is
necessary anymore, but I can only test on my setup and removing the
'assume -EPIPE is an XRUN' hack might break some setups for whatever
mysterious reasons.
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
Resizing in strictly the vertical direction has been broken forever on
wayland. It's because of how the keepaspect calculation always resized
with respect to the width. So if you moved the mouse strictly
vertically with no change left/right, the mpv window would never change
size since it just calculates with respect to the width that doesn't
change.
Fixing this is kind of weird and maybe someone should think of a better
algorithm for preserving aspect ratio (we just multiply by the gcd
basically), but whatever. You might naively try something like "resize
with respect to what direction changes the most" at first, but this
leads to very cludgy resizing since during a typical mouse dragging
motion, it will flip constantly from "resize w/ respect to the width"
and "resize w/ respect to the height". It "works" but it's really ugly
and not worth it.
The trick is to realize that we need to consider the resizing state as
one continuous motion, choose a direction initially, stick to it
throughout the entirety of the resize, and reset the relevant parameters
after we finish the resize. This ensures the direction never
unintuitively flips during a motion, but also allows for the strictly
vertical case to still work.
Might as well note it here in the commit, but mpv's resizing behavior
technically violates xdg-shell. For the resizing event, "[t]he window
geometry specified in the configure event is a maximum; the client
cannot resize beyond it." Well, we do obviously go beyond the maximum in
certain cases. For example consider resizing strictly horizontally. The
width value increases from the compositor but not the height. Since mpv
preserves aspect ratio by default, the height obviously must increase
which will go over the prescribed bounds by the compositor. This happens
before and after this commit, and I think everyone agrees is the desired
behavior. With this commit, now vertical resizing works which violates
xdg-shell in the same way. Before, it incidentally obeyed the protocol
since it did not resize at all, but let's presume users expect the
window to actually get bigger when they do a drag resize.
*: https://wayland.app/protocols/xdg-shell#xdg_toplevel:enum:state:entry:resizing
sfan5
Kacper Michajłow
Guido Cella
Maxim Biro
llyyr
Oneric
Dudemanguy
nanahi
Philip Langdale