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
Client side cursors have always had some issues with fractional scaling.
However since we changed to using viewporter for cursor scaling, most
(or all?) of the problems can be fixed. Unfortunately, a scaling factor
was being truncated to int instead of kept as a double. This matched the
old behavior with buffer_scale, but it's better to use double so the
viewport is actually set to the correct size. Of course, none of this is
relevant if the compositor is using cursor shape.
Fixes f0a6578259Fixes#14001
This follows up 96e1f1dfa5 which converted --gpu-context, and has the
same advantages as listed there.
Unlike with --gpu-context auto can be used anywhere in the list, e.g.
--gpu-api=d3d11,auto works.
I wanted to use the list of GPU contexts as the description in
get_type_desc(), but there is no talloc context to allocate it to, so I
set a print_help_list to print them. The APIs go before the contexts so
that etc/_mpv.zsh doesn't try to complete the contexts.
This function is used to reject invalid context names early, and without
it the context fails to create and only audio is played, but it doesn't
need to check for known entries again.
Mainly for debugging. It might be handy to disable presentation feedback
on wayland to make sure something isn't going wrong with the
calculations somewhere.
Most of these are pretty obscure things that were replaced a long time
ago. The special messages they were printing are also not really useful
at all so just remove them.
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.
No need to reset mp_pass_perf which is only read when desc.len > 0.
This avoids zeroing >16384 uint64_t's every time it's called.
Profiling shows that this reduces CPU usage for frame rendering by ~4%.
