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.
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.
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.
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.
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.
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
These keys should be considered "being pressed" instead of an action of
press. This way, the keypress action won't be triggered; it now triggers
only when the key binding is repeatable and after the initial ar delay.
Since d9c1e9bc5c dovi metadata is
unconditionally mapped to colorspace in mp_image.
However, Dolby Vision videos can have backwards compatibility present for
players without the ability to interpret dovi metadata, like all current
VOs other than gpu-next. In this case, the original video colorspace should
be used to make sure backwards compatibility work properly.
Save the fallback colorspace for VOs which don't interpret dovi metadata.
Fixes: d9c1e9bc5c
Since a6683ea3c9 it is possible to bind
MBTN_LEFT to something useful without conflicting with VO dragging.
However, currently wayland edge resizing is an exception and trying to
resize still triggers MBTN_LEFT. This is not a problem on win32 which
does not pass these inputs to the input system.
Fix this on wayland to do the same.
Change to always use drmModeAddFB2WithModifiers for all formats and fall
back on using drmModeAddFB2 if drmModeAddFB2WithModifiers fail.
With the DRM_MODE_FB_MODIFIERS-flag now only being used for formats with
modifiers all formats without modifiers should also work.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Similar to handles the modifiers must be supplied for each plane of the
format or a framebuffer cannot be created.
Use the format_modifier tied to the object used for the plane to fix use
of formats with modifiers.
Also fix the improper use of the DRM_MODE_FB_MODIFIERS-flag for formats
without modifiers.
This fixes playback of videos decoded by e.g. rpivid into a NV12 format
using SAND128 modifer on RPi using the drmprime-overlay interop.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Now that we have identified the device types associated with each hwdec, we
can take advantage of this to ensure that get the right hwdec is chosen when
decoding frames and there are multiple choices available with different device
types.
This is also plumbed into the filter initialisation logic, although in practice
the decision on the hwdec has already been made at this point - still it's
easier than retaining the ambiguous look up logic and worrying that it might
lead to an inconsistent result.
As the first step towards handling scenarios where the are multiple hwdecs for
a given image format but backed by different AVHWDeviceTypes, let us annotate
the hwdecs with their corresponding device types.
From this, we can also see how all the existing hwdecs which match the same
image format also match the same device type.
It won't be TA allocated and would fail on header check. Also
documentation doesn't mention that ownership is transfered to mpv, so it
is unexpected.
This will cause existing clients of this API leak this memory, but I
doubt anyone really used it in this broken state.
Fixes: #14633
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.
Set UPDATE_VO to GPU API options that are only set on init.
To change multiple options without multiple reinits, use
set vo null; set opengl-foo 1; set opengl-bar 1; set vo gpu
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.
if no NSApplication has been initialized, applications using Appkit
functionality are not supposed to work properly or just deadlock
indefinitely. properly error out on macvk context creation in that case.
Described in more detail in the upstream MR*. mpv naively rounds which
makes us susceptible to the mentioned error. Fix this by keeping
wl->scaling and wl->pending_scaling in the base 120 units. Use the
simple rounding algorithm when needed for calculating widths/heights.
Create a wl->scaling_factor as convenient shorthand for scale / 120
which is what wl->scaling used to previously be.
*: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/309
On X11, aspect ratio constraint is applied on the window manager side,
so whenever keepaspect and keepaspect-window change, mpv should update
the size hint immediately, otherwise the new constraint isn't applied.
Window classes are global per process, but they are associated with the
module that registered them. Documentation is clear that it is the DLL's
responsibility to unregister its own classes:
No window classes registered by a DLL are unregistered when the DLL is
unloaded. A DLL must explicitly unregister its classes when it is
unloaded.
See: https://learn.microsoft.com/windows/win32/api/winuser/nf-winuser-registerclassw
Using a window class after the DLL is unloaded would result in access
violation errors. This is not that important for libmpv, where it is
unlikely someone would use the "mpv" window class externally. The real
issue comes from the fact that reloading libmpv would fail to register
the class (as it still exists) and consequently fail to create a window.
This commit fixes the operability of libmpv after reloading it.
Fixes: #11638
