initially we drew on a dedicated render queue to circumvent certain
bottlenecks on the main queue, like concurrent events that could lead
to late drawing.
though due to the way cocoa works we need to draw an the main queue
otherwise we get undefined behaviour that could lead to crashes.
Fixes#10276
The opt validator functions are casted to generic validator, which has
erased type for value. Calling function by pointer of different
definition is an UB.
Avoid that by generating wrapper function that does proper argument type
conversion and calls validator function. Type erased functions have
mangled type in the name.
Fixes UBSAN failures on Clang 17, which enabled fsanitize=function by
default.
Not sure why all of these single line if's were being braced. Probably
some cargo cult from years ago but might as well fix it now since it's
bothering me.
Could have been done in e32554cd57, but I
skipped it there. However, using viewporter is actually a win here.
There's been a longstanding issue in upstream wayland* exactly related
to this. I even forgot about cd7a7a1de8
which was made for this exactly problem and explains the random
spawn_cursor calls. Anyways, just not using buffer scale and instead
scaling the cursor surface via viewporter works just fine and completely
sidesteps this problem. This means we can drop the random looking
spawn_cursor calls and some additional checks.
*: https://gitlab.freedesktop.org/wayland/wayland/-/issues/194
We don't want to use this if we have fractional scaling or version 6 of
the wl_surface interface which has a preferred buffer scale event which
is superior to this. We were checking in the important place (surface
entrance events) but not technically in the output. So just move the
conditional to set_surface_scaling itself. Also through the VO_EVENT_DPI
in there for convenience.
this logic was copied from the cocoa-cb opengl backend, since it was
assumed both layers work similar. apparently they don't and a nil value
on the metal layer means use the display colour profile, while on the
opengl layer it means undefined behaviour.
this also fixes a problem with the target-colorspace-hint option, since
moltenvk needs to set this colour space itself for a proper hint. both
mechanism would compete to set the colour space.
usually the content scale updates automatically, though on init it is
possible the wrong scale is used for the initial rendering leading to a
wrongly sized surface.
properly set the initial content scale of the layer.
cocoa-cb was always pre-allocated in the Application itself because
libmpv needs to be set up before usage, an opengl context has to be set
and because it was decided mac specific code should be kept out of
libmpv.
this means that a completely working libmpv and opengl renderer was set
up even if it wasn't used. leading to unnecessary log message, resources
being used or reserved on the system that might not be used, triggering
of dedicated GPU unnecessarily and many other things.
even if not optimal, this wasn't the biggest problem since we only had
that one working vo on macOS. though now that we have a vulkan
gpu(-next) backend on macOS that was made the default, we always have
that dangling cocoa-cb instance, which is completely unnecessary.
move the cocoa-cb initialisation into libmpv preinit function and only
init cocoa-cb when we are a standalone App and cocoa-cb support is build
into.
The --alpha option currently covers two related but different concepts:
whether or not to ignore the alpha component and possibly blending it
with a background. Because of the way the option currently works, it is
impossible to have a transparent window (which requires setting
--alpha=yes) while blending it with the background at the same time. To
solve this, let's rework it so it it superseded by the background
option.
--background controls what kind of background to set for the image if
possible. It can be blended with the set background color, with tiles,
or not blended at all (the last one is still broken on X11/mesa except
for GLX, *sigh*). In this new paradigm, --alpha=no has no real purpose
because you can simply set the background to color and whatever color
you want for exactly the same effect. So the option is removed. Instead,
the hint set by windowing backends (i.e. setting
ra_ctx->opts.want_alpha) can by done with the --background option.
As an aside, the colors in vo_gpu are currently bugged due to not
pre-multiplying the alpha and it seems no one ever noticed. The next
commit fixes that. vo_gpu_next support happens latter since it requires
new things from libplacebo.
Fixes#9615.
Currently this was being duplicated on init and on runtime updates
between both VOs. Since the conditions for setting this will get more
complicated in the future commits, it's better to just handle it in one
place. We could combine the vo_gpu and vo_gpu_next handling into one
single function but vo_gpu_next has an additional condition for
determining alpha that vo_gpu_does not, so we'll leave these separate
for simplicity. Also this technically fixes a memory leak where gl_opts
weren't being freed.
As it turns out OES_EGL_image is only defined for OpenGL ES.
OpenGL drivers implement this extension anyway because it used to be
the only way of importing EGLImages into GL.
An equivalent extension for OpenGL was defined with EXT_EGL_image_storage.
The only difference is the interaction with immutability, which requires
textures to be recreated since they can be bound only once.
Note: this commit can in theory cause certain systems to lose vaapi / drmprime
support. Since EXT_EGL_image_storage is 7 years old this hopefully doesn't happen.
If it does, the init checks can be relaxed to still permit OES_EGL_image.
We generally try to avoid that due to the #ifdef mess.
The equivalent format is defined in ffmpeg 4.4 while our interop code
requires a higher version, but that doesn't cause any problems.
It's actually been like this for years, but wlroots doesn't keep track
of resizes a client does independent of the compositor. When using sway,
this leads to weird behavior with floating clients resizing themselves
back to the old size if you unfocus it. mpv has been working around this
for a long time, but it's really annoying to selectively ignore events
based on a weird heuristic. Since Sway finally fixed this bug, let's go
ahead and drop this crap. Note that other wlroots compositors may
possibly experience a regression if they didn't correct for this like
sway does, but it's for their own good.
This commit adds a DND_INSERT_NEXT action option for drag-and-drop,
allows for selecting it through the --drag-and-drop=insert-next option,
and adds the necessary plumbing to make that happen when something is
dragged onto the player.
Wayland was the only backend that attempted this, but it can be done in
a centralized place for anything that supports this. hidpi-window-scale
is just the same as a normal window scale but with the OS DPI as the
factor.
Several related things but in a nutshell makes it more like wayland.
1. Remove unneeded --hidpi-window-scale checks. The backend should
always report the actual dpi value regardless of what this option
says.
2. Remove dpi_scale factors from UNFS_WINDOW_SIZE VOCTRLs. It makes
things more complicated and unintuitive for no reason. A window scale
of 1 should mean 1. It annoyed a few years ago in #9437, and I agree
with them (wayland was never implemented like this).
3. Change the dpi log messages to be more brief and remove the unneeded
comments about prescaling.
Previous fix only worked when the video output doesn't have vertical
black bars. This fixes the cases like fullscreen, video-zoom etc.
Fixes: https://github.com/mpv-player/mpv/pull/13528
The purpose of osdep/io is to provide a wrapper for POSIX I/O functions
on Windows. The last 2 functions are utility functions which don't serve
this purpose.
Move them to a separate file.
When doing the dithering pass, the fragment coordinate is queried, but
doesn't take the fbo texture flipped property into account. This results
in different dithering patterns when toggling between fbo flipped and
non-flipped state. This can be reproduced with --vo=gpu --gpu-api=opengl
and easily seen with --dither-depth=1 when toggling between playing and
pausing.
Fix this by flipping the fragment y coordinate if the fbo is flipped
when calculating dithering coordinate.
When redrawing cached frames while the fbo texture is flipped,
the texture after drawing to screen pass will be flipped when blitting.
However, when rendering the checkerboard, the fragment coordinate
doesn't take this into account, so the coordinate before flipping is used,
resulting in different checkerboard location when toggling between
flipped and non-flipped state. This can be reproduced with --vo=gpu
and --gpu-api=opengl: the checkerboard patterns when playing and
pausing are different (vertically flipped).
Fix this by flipping the fragment y coordinate if the fbo is flipped
when calculating checkerboard coordinate.
Begin the _NET_WM_MOVERESIZE window dragging in ButtonPress event
to match the behavior of win32 and wayland, simplify logic by dropping
the win_drag_button1_down hack required by the old method, and fix a race
condition described in commit 19f101db68,
which happens when moving the mouse and releasing the button at the same time.
The race condition can be easily triggered when using a touch screen
(tested with libinput driver), where a tap is translated to MotionNotify,
ButtonPress, MotionNotify, and ButtonRelease in sequence, with the last 2
events having the same timestamp. This has caused some window managers to
not stop dragging after the ButtonRelease, resulting in window being stuck
in dragging state after a single tap.
this partially reverts commit 7b5a258. back then the only properly
working vo on macOS was cocoa-cb (libmpv). it would always use the
deprecated opengl cocoa backend or no vo at all. because of that libmpv
was moved to the top of the auto-probing order, so the preferred vo
was used on macOS only.
we now have a working vulkan gpu/gpu-next backend on macOS which should
be the new default vo. though disabling the auto-probing again for
libmpv would probably cause the undesired behaviour on macOS that
cocoa-cb would never be auto selected again. especially if not build
with vulkan support or without vulkan driver on macOS, this would lead
to no video output at all. so instead of completely reverting the
mentioned commit, we instead move libmpv to the bottom of the
auto-probing order but only auto select it when mpv was built with
cocoa-cb support. this restores the previous behaviour on all other
platforms besides macOS, but also lets us auto select cocoa-cb if
supported.
this fixes a crash on quit, when a CATransaction from a system owned
thread/event is happening at the same time. locking the context
synchronises these access and prevents the race condition.
the draw operation induced by any display call from the CAOpenGLLayer
doesn't need that lock, since the display function already does lock
that current context.
Fixes#11681
Since 03cf150ff3, the only purpose of this
VOCTRL was to signal a redraw to the vo. It actualy could have been
removed in 531868fe0d, but this was
missed. The UPDATE_VIDEO flag is better anyway because it allows us to
handle a wide variety of options scattered around that require the VO to
update itself and redraw. We can remove both of the custom callbacks in
vo.c and only leave the VOCTRL_VO_OPTS_CHANGED one. Additionally, that
commit also introduced vo_set_want_redraw, but this is redundant and not
needed. The VOs that use VOCTRL_UPDATE_RENDER_OPTS already set
vo->want_redraw, and those are the only VOs where these options are
relevant in the first place. So we can remove this as well and just let
the big callback in player/command do everything.
It's only necessary to check the existance of cursor_shape_manager.
Also drop the pointer check to handle multi-seat since a removed seat
sets the cursor_seat to NULL.
For VOCTRL_SET_CURSOR_VISIBILITY, set cursors visibility for all seats.
The return is VO_NOTAVAIL is none of the seats have cursor, and
VO_FALSE if setting visibility failed for at least one seat.
The cursor_shape_device is per pointer, which is per seat. Handle it
together with other seat objects. This in turn also handles cursor
visibility per seat.
On a multi-seat setup, wl_registry_global advertises wl_seat multiple times,
one for each seat. if wl->seat is already set, the previous value will be
overwritten, preventing it from being freed.
Additionally, if the latter seat doesn't have the capabilities of the
former seat, the keyboard/pointer/touch input devices will be destroyed
because the current wl_seat_capabilities doesn't distinguish between
different seats. This casues keyboard/pointer/touch not working if the
latter seat has no such capabilities.
Fix this by implementing multi-seat support.
This allows receiving inputs from all devices on all seats.
All seat-specific objects (wl_keyboard/pointer/touch, wl_data_device)
are grouped with their respective seats so they can be managed together.
Note that currently inputs from all seats are interleaved with each other
and modify the same global input states.
If libplacebo manages to create a vulkan swapchain that allows
alpha composition mode to be controlled by the DWM API,
this makes it runtime changeable.
Specify cAlphaBits in PIXELFORMATDESCRIPTOR makes the pixel format
transparent, as is already the case for d3d11. Also makes the
window transparent when --alpha=yes is used.
Works on --vo=gpu and --vo=gpu-next.
Previously, libplacebo would fail to render the image since mpv was
feeding it bogus bitmaps with 0 width/height. An easy way to encounter
this would be to set sub-scale to 0 with bitmap/image subs.
This avoids clearing the queued frame and the currently displayed one on
VO reconfiguration requests that happen when new frames arrive. Instead,
let those frames be fully displayed.
Fixes mf:// playback issues introduced after commit ef11d31.
Instead of removing the frame timing check embrace and fix it to wake up
the playloop as needed. The frame display duration is problematic to
handle as both VO and playloop thread would already be sleeping, but in
certain use cases it is needed to display frames in full, so in this
case, let the VO sleep to the end of frame, wake up the core as
requested and go back sleeping.
Note that this patch series reintroduces 0c9ac5835, which is esenitally
fixed in this commit. It is still not perfect, but it is better than
just busy waiting on playloop, even if those events when this would be
needed are quite rare.
Since 1f8013ff3f, if you release a modifier before a regular key on
Wayland, that key gets immediately pressed again because
keyboard_handle_modifiers() calls mp_input_put_key() regardless of
whether a modifier is pressed or released, e.g. if you press Ctrl+s it
easy to take an another screenshot with s by accident. Fix this by
releasing keys when releasing modifiers.
Ideally, releasing the modifier should input the key alone after
--input-ar-delay, while this patch disables it forever, e.g. on X11 if
you type something in the console, hold Ctrl+h, and release Ctrl, it
starts typing h instead of deleting characters. This doesn't work
because keyboard_handle_key() is only called when you first press a key,
while on X11 KeyPress keeps getting sent as you hold down the key. But
this difference in behavior between X11 and Wayland can also be
reproduced with GTK and Qt applications, so I guess this is acceptable.
When the mpv surface leaves the output, we no longer mark it as the
current output. However, this implicitly depends on there being a
preceding surface entrance event to a different output. This is not
necessarily the case. Consider moving the window from monitor 1, to
monitor 1-2, and then back to 1 again. mpv gets the entrance event to
monitor 2 and sets that as the current output to work off of. Then when
you move back to only monitor 1, it removes monitor 2 from the current
output. However, monitor 1 is not updated again as the current output
because there is not a new surface entrance event in this case (the
window never left). So the numbers that mpv's core is using are
incorrect and for the wrong monitor. Luckily, we already keep track of
what outputs the mpv surface is currently on no matter how many there
are so it is simply a matter of setting current output again in the
leave event if we have a different output that has the mpv surface.
Ref: https://github.com/swaywm/sway/issues/7932
vo_rpi and its related code has pretty much historically been a
disaster in mpv. The build regularly gets broken and since nobody uses
it, it takes months for anyone to notice. There was also that time where
fullscreen was broken for about a year and a half. Also building in waf
was entirely broken for about a couple of years or so due to mysterious
reasons no one ever figured out (meson magically fixed it).
Anyways, once again the build is broken due to rpi being forgotten about
again, but instead of pretending to support this crap. Just drop it all.
Nowadays, mmal hwdec is a relic since these devices are better off using
the v4l2m2m ffmpeg fork instead which actually uses KMS properly. RPI 1
and 2 probably can't do this and will remain broken but oh well blame
Broadcom for being special snowflakes and not using standard APIs (my
rockpro worked out of the box; just saying). RPI 2 is nearly 10 years
old anyways, so I think you can afford a new SBC by now. If we were
nicer, there would be a deprecation period, but this is broken in the
last major release anyway so too late.
Closes#13402.
When adding things like brightness or gamma, the video obviously needs a
redraw if paused. This happened to work in the normal case because the
OSD notification triggered a redraw, but if you use no-osd the picture
won't change. Fix this by adding another option flag, UPDATE_VIDEO, and
simply signalling we want a redraw. This gets handled along with the
normal osd redrawing check in the playloop so something like "no-osd add
gamma 1" actually works.
df764bc0c3 and
c82c55b4b9 blindly converted the units for
this VO since neither of us actually have the hardware/setup to test the
VO. Well it was not actually correct (maybe just one was wrong or both
who knows) since vo_vdpau using timing very differently than all the
other VOs and no one reported on it until just now. Anyways, just apply
this random patch from @DanOscarsson which apparently works for him and
call it a day. Fixes#13397.
Since the scroll event handler is moved to wl_pointer_frame, version 5 of
wl_seat is required. Warn that scrolling is broken if the compositor
doesn't support that verison.
Commit f54ad8eb05 broke high resolution
scrolling because one logical mouse click is generated for every scroll
event, no matter the magnitude. This makes scrolling on trackpad way
too fast.
Revert the axis scaling change in that commit and clamp the resulting
value between -1 and 1 to make sure mouse wheel scrolling works as
intended on compositors which send a value larger than 10 for these events.
Some X11 window managers support controlling the title bar independently
from other window decorations with _MOTIF_WM_HINTS. This allows hiding
the title bar while keeping other decorations like the resizing borders.
Let mpv respect the --title-bar option on X11 so --no-title-bar can hide
the title bar only like on win32.
Save the cache to separate files to avoid loading/saving a huge combined
libplacebo.cache. This approach allows the saving of only new cache
objects and avoids resaving the entire cache, especially even if only a
tiny change was made.
This commit improves the cold start time of mpv and avoids saving data
when it's not necessary.
Number of changes were made:
- each cached object is saved in its own file
- cache files are prefixed with the name of cached object
- cache directory is cleaned on each uninit
- the least recently used cache files are removed if cumulative cache
size is above limit
- files used in the recent 24 hours are not removed to allow changes
to mpv.conf without worrying about the cache being removed during
experimentation
- shader cache size limit is set to 128 MiB
- icc cache size limit is set to 1.5 GiB
- cache objects are loaded/saved as needed
This commit eliminates the runtime performance penalty associated with
the size cache. While we continue to maintain the cache limit to prevent
retaining stale objects, mpv now only loads a small subset of files that
are currently required for playback, instead of loading all files.
32-bit signed integer can hold ~2.1s stored as nanoseconds. While frame
duration doesn't make sense to be this long, the existing clamp is to
10s. Change type to double, which is consistent with other fields in
vo_frame.
Previously, all scaling was forced to 1 with this vo and all coordinates
were calculated as if the scale was 1. This works since viewport relies
on the compositor completely for scaling so it doesn't really matter if
we don't draw directly to the correct size since the compositor will
just scale the rest for us. This does have some downsides however since
the OSD text might not be drawn at the actual resolution of the final
size of the video.
We can instead handle this by getting rid of the dmabuf_wayland specific
scaling logic and using the same values as everything else. In the
resize in vo_dmabuf_wayland, we just need to adjust the viewport
destination calls so they go to the wayland local coordinates and not
the physical ones. This should ensure that vo_dmabuf_wayland directly
goes to the desired size and the compositor doesn't need to operate on
it after the fact.
If the scaling value changed for some reason, the window geometry would
be recalculated with the new scaling even if this option was disabled.
Properly ignore it.
The core wayland protocol way of handling scaling is to use the
buffer_scale mechanism. But this sucks in several ways for reasons I
won't list here and fractional scaling rightly avoids this altogether
and uses a buffer_scale of 1 (i.e. not setting it) along with
viewporter. When originally implemented, this was only specifically used
when the fractional scale protocol was available, but we actually can
use it as a full replacement instead. This means that mpv now hard
requires viewporter, but this protocol is supported by everyone and is
one of the few that is actually stable.
How it works is the same regardless of fractional scaling or not. When
the compositor has a scale value not equal to 1, it will always scale
the client by that factor (unless you set buffer_scale). What we do here
is pass a viewporter size that exactly undos the compositor-side scale
(sans a possible rounding error). So what we are left with is just the
exactly physical pixels we want to display. Fixes#13316.
7b8a30fc81 made it possible for a VO to
have direct ownership of frame objects since the it may be beneficial
for the frame to follow the lifecycle of that particular VO instead
(i.e. the wayland compositor for dmabuf-wayland). But when frames are
dropped, this always has to be unconditionally freed since the VO isn't
aware of it. Fixes#13364.
This exports `current-gpu-context` property, which is the string
description of the current active GPU context. This allows scripts to
uniquely identify the platform and backend used for --vo=gpu
and --vo=gpu-next.
Negative values are nonsense to mpv, and can cause protocol error afterwards,
like xdg_surface::set_window_geometry which doesn't accept negative values.
Treat any negative values as zero (client determines size) for now.
Needed in case the timer solution fails. Note that this will leave the
mode indicator in the language bar showing the original mode until
a key is pressed.
The IME is useful for text input. Additionally, Alt+Shift input language
switching doesn't work when IME is disabled even when the languages don't
require IME.
Re-add the VK_PROCESSKEY logic to ensure that IME is handled properly.
Reverts bf6b981367.
According to the xkbcommon docs, `xkb_state_mod_index_is_consumed` is
true when a modifier *may affect* key translation. A key modifier may
be consumed but not be active. See xkb documentation for this function
for further details. This breaks key modifiers in cases where
L_Shift+R_Shift for example is used to change keyboard layout with
`xkb_options grp:shifts_toggle`. Instead, replace it with a simple
check for a valid modifier.
Xft.dpi is much more widely used nowadays by GUI programs compared to
the X11 screen DPI.
This is the best we can get for a vendor-neutral scaling preference
value under X11 in terms of adoption.
If Xft.dpi isn't available, the X11 screen DPI is used as a fallback.
~144 DPI displays are pretty common and neither 1x nor 2x scales are
the right size for it. Allow DPI scale in unit of 0.5 to fix this.
Additionally, add a note about the current behavior of the API used
to get the scale factor.
Currently, libplacebo always tries to reconfigure the d3d11 swapchain
to a 10-bit output format because disable_10bit_sdr isn't set to true,
even when an 8-bit format is explicitly requested via
--d3d11-output-format.
Fix this by passing the requested output format preference to libplacebo.
Document that this option may be ignored.
In commit c09245cdf2
long-path support was enabled for mpv without actually
making sure that there was no code left that used the
old limit (260 Unicode chars) for buffer sizes.
This commit fixes all but one case.
As a result of the work I did the explicitly check for formats
supported by the vo in the f_autoconvert logic, I introduced a
regression in the handling of the rpi4_8 and rpi4_10 formats. These
require special handling because they only exist in the rpi forks and
not upstream ffmpeg, which means they don't have stable pix fmt values
that we can use directly.
Previously, we simply didn't declare them as supported, which was ok,
as nothing was really enforcing the list of supported formats, but that
has changed.
As we still can't simply use the pix fmts, I had to do a slightly
ridiculous dance to look them up by name, and if they exist, then
register them as supported.
Good times.
The dragging hack can cause unwanted aero shake activation.
Prevent this by saving the window arrangement state before dragging,
temporarily disable it while dragging hack is active, and restore to
the original state after dragging ends.
The mouse down handler checks w32->current_fs to determine whether
to begin the dragging hack. Unfortunately, the w32->current_fs value
is stale, because the input is handled asynchronously, and we cannot
wait for an up-to-date value if dragging needs to be kept resonsive.
As a result, when the fullscreen state changes after the dragging
model loop is entered, the opposite value is used, so the window stays
draggable after entering fullscreen, and becomes undraggable after
exiting fullscreen.
With the resonsiveness and model loop constraints, the up-to-date
state must be queried inside WM_MOVING messages which are sent while
dragging. The message handler now checks if the dragging hack is active
while the window is in fullscreen, and overrides the new window position
with the current one, in effect prevents the window from being moved.
The old check is also removed, so the window is now draggable after
exiting fullscreen while dragging hack is active.
Compose key doesn't function in X11 because XFilterEvent() isn't called,
and XNInputStyle is set to a wrong value. This results in KeyPress events
for the separate keyboard inputs in the compose key input sequence
instead of the composed character, making it impossible to input certain
characters which require compose key.
Fix this by calling the required XFilterEvent() and set XNInputStyle
to the correct value.
According to MS documentation, an application should return TRUE from
WM_XBUTTONUP and WM_XBUTTONDOWN if it processes these messages.
DefWindowProc generates the WM_APPCOMMAND message when it processes the
WM_XBUTTONUP message, so if an application properly handles WM_XBUTTONUP
messages, extra WM_APPCOMMAND messages won't be generated.
Because mpv doesn't properly handle these messages,
WM_XBUTTONUP causes APPCOMMAND_BROWSER_BACKWARD to be generated, resulting
in duplicated keys and improper fix 438ead7a, which prevents the processing
of the appcommand from sources other than mouse clicks.
Fix this by following the documentation, and the back and forward
appcommands can be added.
XF86Back and XF86Forward are mostly used to navigate file and web browsers
to go back/forward in history. XF86Forward isn't recognized right now,
so add it.
Because XF86AudioForward already takes the "FORWARD" name, rename the
browse keys to GO_BACK and GO_FORWARD instead.
in the case the window was already set to a maximized size via geometry
or related options (100%x100%) the maximize function would try to
maximize the window again. this reset the position and slightly
increased the size further.
to prevent this only maximize on init if we really want to maximize. in
the reverse case make a noop call by passing the current zoom state.
Fixes#11193
281b1d8999 introduced a stack use after
scope because dest_fbo can be reassigned a new pointer and then be used
by pass_draw_to_screen outside of that scope where the pointer is no
longer valid. Fix this by rearranging the variables so the assignment is
done in the same scope as the pass_draw_to_screen call instead.
The info provided for libva might be useful. Specifically on Windows it
seems to not use the error callback for what should be logged as error.
[ 0.080][v][vaapi] libva: VA-API version 1.20.0
[ 0.080][v][vaapi] libva: Trying to open <path>/vaon12_drv_video.dll
[ 0.080][v][vaapi] libva: va_openDriver() returns -1
[ 0.080][e][vaapi] Failed to initialize VAAPI: unknown libva error
As we can see only the "unknown" error is printed to the error callback
and important information is printed on the info callback. Print it to
verbose log to make it easier to find.
the title is updated on the main thread (mandatory with cocoa)
asynchronously, because otherwise it would either deadlock when done
synchronously, lead to undefined behaviour or just crashes. the problem
here is that the c string was only copied to an NSString within that
asynchronous call, which potentially would access the pointer when it
is accessed, modified or freed by another thread. it is only safe to
access this pointer as long as the control callback wasn't returned yet.
to fix this we move the copying and creation of the String from the
c string pointer outside of the asynchronous call where the conversion
of an untyped pointer to a typed pointer is done too. since the
resulting String is a copy it's safe to be used in the asynchronous
call.
also reverting ee6ad40, since the problem was most likely an SDK problem
or the very same problem as mentioned here. i retested the crash case
again und can't reproduce it anymore. using a swift String again instead
of an NSSstring.
Fixes#12935
- Don't define _GNU_SOURCE on Windows, no need
- Define WIN32_LEAN_AND_MEAN to strip some unneded headers from
windows.h
- Define NOMINMAX and _USE_MATH_DEFINES as they are common for Windows
headers
We prefer to fail fast rather than degrade in unpredictable ways.
The example in sub/ is particularly egregious because the code just
skips the work it's meant to do when an allocation fails.
This mostly is added to resolve player command synchronization with VO
thread discussed in 477a0f83.
The current uses does not necessarily need this as they are all managed
by playloop. But for future use with other params that will be handy.
Those params are mostly to observe current state of VO and does not
necessarly need to be locked along with frame drawing, that changes the
params once at the end.
Only vaapi-copy variant as nothing can map D3D12 resources currently.
And even if we would add resource sharing to D3D11 it would invoke copy
at some point, so there is no point really. Maybe in the future when
libplacebo get smarter about resource sharing on Windows, but practical
advantages are really small. I've tested it with Vulkan <-> D3D11
sharing and GPU <-> GPU copy is still invoked. Better than CPU memcpy,
something for the future.
Up to 2x playback rate is the most we can offer currently. Should work
fine for most kernels with radius <= 2.
This avoids limitation of hwdecs number of frames in-flight.
Fixes: #12927
there is 1px border at the top of the window that is not covered by our
title bar and the video below is visible. this broke in some newer macOS
version even so the calculation of size and position of the title bar is
still correct. add 1px the the height of the title bar to cover up the
unwanted border.
These are less likely to be modified from run to run, and with the
avoidance of redundant re-saving we can get away with a larger size.
This is enough to save 10 3DLUTs at typical sizes.
I have no idea why this code is such a convoluted mess of options and
possibilities. First of all, why is dumping both caches to a single file
even a supported use case? Why is the cache path generated multiple
times, once for saving and once for loading, instead of just generated
once and stored? Why even create a pl_cache if you're not going to
save/load it? Why so much code duplication?
I don't know. But I rewrote it in a way that makes far more sense to me.
This change prevents unwanted adjustments. Generally, screenshots
shouldn't invoke pl_queue_update, as this action could cull the already
mapped frames in the queue.
If !display_synced, some values may not be correct or zeroed. Therefore,
it makes no sense to interpolate in this case.
For a non-moving frame, we always want to show an uninterpolated frame.
libplacebo requires additional frames when VPS is lower than FPS and
anti-aliasing is enabled. Supports up to a 1/4 ratio. VO has a limit of
10 frames, so in practice, not many more can fit.
Note that the internal libplacebo mixing limit is 16 frames.
The `current_frame` can be redrawn even if the remaining `num_vsync` is
equal to 0. In this scenario, the vsync offset would be incremented
beyond the target point.
It turns out that mpv will rewrite the entire cache file on every single
quit. It's not so great since after viewing a ton of files, your cache
can grow to massive sizes and slow down quitting the player to a
noticeable amount. Turn down the max size of both caches to 10 MiB for
now as a workaround until this gets improved later.
This filters out vastly inaccurate values from presentation feedback
that can happen shortly after restarting playback or seeking.
Makes estimated vsync converge almost instantly instead of waiting
until those outliers are dropped from the past samples.
In commit de6d57f0 libplacebo enabled drift compensation by default.
mpv already tracks error and adjust the speed by itself.
This commit fixes judder visible when slowing video a lot, ex. playing
back at 10% speed.
Set ideal vsync duration also when dropping frames, libplacebo estimate
currently own values anyway, will be useful later...
See: de6d57f021
The commit subject sounds reasonable except that frame redraws get
spammed in certain cases (still image with subtitles) all the time
regardless if the subtitle actually has changed or not. So this is
stupid and wasteful, but you'll always see subtitles. vo_gpu currently
has this behavior as well, so we're just matching it but later mpv's
core should be fixed so this works reasonably. Fixes#11335.
Fixes gpu-next completely ignoring any speed adjustment, either DS or
playback.
Frames in pl_queue have raw PTS values, so when querying them we have to
use the same time base. There was misunderstanding between mpv and
libplacebo, where the former was querying the frames based on display
vblank timeline, but this cannot work if the playback speed is adjusted
and display timeline is not aligned with video timelien. In which case
we have to schedule "video vsync" points that we want to display.
Previous code was working only when playback speed was 1.0x, but since
DS almost always changes the speed the interpolation was mostly not
timied correctly.
Relative to frame PTS timeline as oposed to display vblank.
Those values are relative to unadjusted video timeline. They will be
used by gpu-next where it expect virtual frame vsync, not display vblank
time.
Originally suggested by @haasn. Instead of awkwardly using a pts from
the previous render loop, we can just peek into pl_queue and use the pts
of the first frame instead. This eliminates a lot of weird artifacts
that can happen on discontinuities like seeking. Fixes#12355.
Several related things in regards to interpolation. Essentially this
adds more general sanity checking to bring it more in line with what
vo_gpu does.
- Add a can_interpolate bool which determines whether or not this frame
is allowed to interpolate.
- p->is_interpolated was sometimes lying and because you can have a mix
frames greater than 1 depending on the video and settings. Make sure
that vsync_offset is not 0 so we know if it's actually interpolated or
not. This prevents a redundant redraw for those edge cases when
pausing.
- When the vo wants a reset, i.e. some sort of discontinuity, don't try
to interpolate the frame. Interpolation is only valid for
monotonically increasing times.
This fixes#11519 because of the additional check to make sure that we
have more than 1 frame. The PTS clamping part is still not great. That
is for the next commit.
In the past, this worked by accident because the initial startup was
racy and sometimes the initial firing of handle_toplevel_config would
happen after reconfig. Since we now properly wait on all compositor
events we can save the initial size hint that is given to us and try to
use that as the window-size/geometry provided the --autofit/geometry
options aren't explictly set. Fixes#11134.
the OpenGL cocoa backend was deprecated in 0.29, it has lot of bugs, is
completely unmaintained and can't properly playback anything anymore on
the newest macOS. it is time to remove it.
the old displayName property via the IODisplay API is not working
anymore on ARM based macs and was broken in at least one other case.
instead we use the new localizedName property introduced in 10.15 of the
NSScreen. we don't need any backwards compatibility since 10.15 is the
oldest version we support now.
configs and scripts that use the options and properties fs-screen-name,
screen-name or display-names need to be adjusted since the names could
differ from the previous implementation via the IODisplay API.
Fixes#9697
this is apparently something that was added with swift 5.5, though it is
hard to find anything officially.
don't capture self in closure but explicitly access all variables by
prepending self.
Fixes#12653
Fixes a899e14b which changed clamp from 0 to 1 ms which effectivelly
introduced 1ms sleep always, even if requested until_time_ns is in the
past and should request 0 timeout.
While at it also fix mp_poll wrapper to respect negative timeout which
should mean infinite wait.
Also keep the 37d6604 behaviour for very short timeouts, but round only
the ones > 100us, anything else is 0.
Fixes: a899e14b
Most importantly, the wait_until addition was missed while doing the
unit conversions to nanoseconds which meant mpv woke up roughly every
second since not nearly enough time was added. It was meant to be 1000
seconds (1e9 in microseconds). Use a macro so it's more readable. Also
put some other wild 1e9 calculations inside of a macro as well.
Fixes a899e14bcc.
These have been build options since the waf build, but that doesn't
really make sense. The build can detect whatever macOS sdk version is
available and then use that information to determine whether to enable
the features or not. Potentially disabling multiple sdk versions doesn't
really make any sense. Because f5ca11e12b
effectively made macOS 10.15 the minimum supported version, we can drop
all of these checks and bump the required sdk version to 10.15. The rest
of the build simplifies from there.
Currently VOCTRL are completely unusable for frequent data query. Since
the HDR parameter addition to video-params, the parameters can change
each frame. In which case observe on those parameter would be triggered
constantly. The problem is that quering those parameters involves VOCTRL
which in turn involves whole render cycle of delay.
Instead update VO params on each draw_frame. This requires changes to VO
reconfiguration condition, but in practice it should only be triggered
when image size or data layout changes. In other cases it will be
handled internal by VO driver.
I'm not quite happy with this solution, but don't see better one without
changing observe/notify logic significantly. There is no good way
currently to handle VOCTRL that are constantly queried.
This adds unfortunate synchronization of player command with VO thread,
but there is not way around that and if too frequent queries of this
param becomes a problem we can thing of other solutions.
Changes the way to get data from VO driver added by a98c5328dc
Fixes: 84de84bFixes: #12825
windowrc in vo_w32_state is actually client size, for hit test we need
proper window size. When border is disabled those sizes are the same,
but when only title bar is disabled it is not.
Reduce the hit area to more sane values when the border is not
drawn to minimize amount of covered client area in borderless mode.
This was specifically special logic for drm. Before present_sync, it
would also clear out all of its vsync values like this. The old drm code
would save a bunch of samples which would confuse vo.c when unpausing
since it got old, bogus values. Since we make sure to match successive
vsync samples with the swapchain depth and that present sync samples
also match the swapchain depth, this is unneeded.
There's some geometry-related things that mpv has to calculate before
the window is actually mapped onto the screen in wayland. But there's no
way to know which output the window will end up on before it happens, so
it's possible to calculate it using the wrong values. mpv corrects
itself later when the surface event happens, but making the initial
guess work better can help in certain cases.
find_output is the only thing that needs to be changed here. Its main
purpose is to grab the right output based on user settings when we're
trying to full screen and giving a fallback in case we don't have
wl->current_output yet. The x11 code already does something similar, so
we're basically just copying it. Allow user settings like --screen and
--screen-name to influence the initial wl_output guess. Those options
won't actually place the window on that specific screen since we can't
do that in wayland, but if the user knows where the window will end up
beforehand it makes sense to listen to the arguments they pass. If
something goes wrong, then we just fallback to 0 like before.
A ton of code and drm-specific abstractions can be dropped with this.
One important thing to note is that the usage of sbc is completely
dropped here. The utility of that is not particularly clear since the
sbc value was manually incremented before the flip and it's not as if
the drm page flip event gives it to us like it does with the msec and
ust. It can be reintroduced later if there is a need. For drm, we also
add a present_sync_clear_values helper since all presentation feedback
needs to be cleared on pause/resume for it.
When this was originally written, the queuing/list approach was
deliberately removed since it adds more complication and xorg/wayland
don't really use it anyway. In practice, you only really have one frame
in flight with presentation timestamps. However, one slight annoyance is
that the drm code has its own thing which is almost exactly the same and
does its own calculations. Ideally, we'd port drm to this instead, but
the implementation there takes into account N-frames in flight which
probably does actually work. So we need to make present_sync smarter and
be able to handle this.
mpv does actually have its own linked list implementation already which
is a good fit for this. mp_present becomes the list and each
mp_present_entry has its own set of timestamps. During initialization,
we create all the entries we need and then simply treat it like a queue
during the lifecycle of the VO. When an entry is fully used
(present_sync_get_info), then we remove it from the list, zero it out,
and append it to the end for future use. This avoids needing to allocate
memory on every frame (which is what drm currently does) and allows for
a reasonable number of in flight frames at the same time as this should
never grow to some obscene number. The nice thing is that current users
of present_sync don't need to change anything besides the initialization
step.
This commit replaces all uses of sig_peak and maps all HDR metadata.
Form notable changes mixed usage of maxCLL and max_luma is resolved and
not always max_luma is used which makes vo_gpu and vo_gpu_next behave
the same way.
This change essentially removes mp_thread_self() and instead add
mp_thread_id to track threads and have ability to query current thread
id during runtime.
This will be useful for upcoming win32 implementation, where accessing
thread handle is different than on pthreads. Greatly reduces complexity.
Otherweis locked map of tid <-> handle is required which is completely
unnecessary for all mpv use-cases.
Note that this is the mp_thread_id, not to confuse with system tid. For
example on threads-posix implementation it is simply pthread_t.
The old one would actually crash if the libplacebo.cache file was
invalid. Additionally, set a max size of 1 GiB for icc cache and 50 MiB
for gpu shader cache. The per object size limit is removed which puts
mpv in line with plplay. Finally, a few memory leaks are also fixed
since several objects previously were not freed on uninit.
Vapoursynth does not provide crop metadata and input one is likely to be
invalidated during filtering. Set crop to full frame if image dimensions
were changed during filtering.
Fixes: #12780
I'd like some names to be more descriptive, but to work with 15 chars
limit we have to make some sacrifice.
Also because of the limit, remove the `mpv/` prefix and prioritize
actuall thread name.
ffmpeg is again setting the frame dimensions to the coded size, so we
need to reintroduce our work-around to get the logical frame dimensions
from the frames_ctx rather than the frame itself.
ffmpeg commit:
* 9ee4f47c94
This reverts commit c40bd88872.
Other similar options are in the form of --foo-override not
--override-foo. The display-fps one was backwards so flip it around the
other way for consistency reasons.
Peak detection greatly increases HDR experience. Performance hit of
non-delayed detection is not that significant and is in line with
current default settings.
Make it not possible to build mpv without the latest libplacebo anymore.
This will allow for less code duplication between mpv and libplacebo,
and in the future also let us delete legacy ifdefs and track libplacebo
better.
since i was going to fix the include order of stdatomic, might as well
sort the surrouding includes in accordance with the project's coding
style.
some headers can sometime require specific include order. standard
library headers usually don't. but mpv might "hack into" the standard
headers (e.g pthreads) so that complicates things a bit more.
hopefully nothing breaks. if it does, the style guide is to blame.
replace it with <stdatomic.h> and replace the mp_atomic_* typedefs with
explicit _Atomic qualified types.
also add missing config.h includes on some files.
Some users report visible black frames during window resize, this should
not happen in most cases. Let's just keep stale content as it is less
distracting. While still clearing on first window paint to avoid white
background.
Fixes: #12642
