4d09cde8f9 added this behavior and made
the format filtering more aggressive, but it's over correcting. The
misunderstanding on my part is that the problem was with modifiers not
with formats. There is hardware that do not have any valid modifiers
which means certain formats cannot possibly work correctly with
vo_dmabuf_wayland (broken colors etc.). Formats on the primary plane do
not require modifiers so if it happens to be a planar format, we can
accept it and possibly use mpv's autoconverter. If we do get a valid
format + modifier pair from the compositor, then we should always accept
it regardless if it is planar or not.
The old name is misleading. We do want these formats, but it is not
accurate to call them "gpu formats". Call it "planar" instead so it's
more obvious these come from drm primary planes.
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.
