Currently, running AO control wakes up the WASAPI renderer thread in the
`WASAPI_THREAD_FEED` state, where `thread_feed` will be called. However,
it seems that in recent Windows versions (tested on Windows 10 build
19044.3930 and Windows 11 build 22631.3007) we can't know if it is safe
to feed more audio data in event-driven exclusive mode:
- `IAudioClient_GetCurrentPadding` always returns `bufferFrameCount`,
even if *NO* data has ever been written. This means we don't know how
much free space we have that is available for writing. This is not the
case in shared mode, where the return value correctly reflects the
size of data waiting to be processed. As a sidenote, MS did not
document the precise definition of the return value for an
event-driven, exclusive stream [1].
- `IAudioRenderClient_GetBuffer` never fails. We can call it for 10
times in a roll, each time requesting an entire buffer (the unit at
which data is exchanged in exclusive mode using event-driven
buffering; there are 2 such buffers) and get a successful return code
everytime. In shared mode, we get `AUDCLNT_E_BUFFER_TOO_LARGE` if we
request a buffer larger than that currently available.
As a result, `thread_feed` will always write `bufferFrameCount` frames
of audio in exclusive mode. There will therefore be glitches each time
`thread_control` is called due to the subsequent `thread_feed`
overwriting frames yet to be processed. Also, an irreversible error is
accumulated to `sample_count` as long as there is no AO reset, leading
to eventual, unbounded A/V desync.
As a fix to the issue, add a dedicated state for dispatch queue
processing so that `thread_feed` is only called when signaled by the OS.
The buffer checks in `thread_feed` that use `GetCurrentPadding` in
exclusive mode are kept in case there are older versions where the two
APIs behave differently.
Closes#12615.
[1] https://learn.microsoft.com/en-us/windows/win32/api/audioclient/nf-audioclient-iaudioclient-getcurrentpadding
With --ignore-path-in-watch-later-config,
--write-filename-in-watch-later-config still writes the absolute path of
files in the comment, even though the hash is calculated from the
basename. Make it write the basename to avoid confusion.
Also stop writing redirect entries for parent directories with
--ignore-path-in-watch-later-config, both because it's redundant, and
because with this patch it would write the basename of directories in
the comment, which would be wrong because their hashes are calculated
from the absolute paths.
There's too many dumb options related to subtitles which have annoying
edge cases. Try to rewrite this completely so it hopefully behaves
normally in every expected scenario. A key goal here is be smarter while
looping through the tracks and avoid selecting the subtitle if it
doesn't meet user's passed options as opposed to clearing the pick after
the fact. Fixes#13280 and fixes#13263.
When using sub-seek without a video track while paused, adding the 0.01
SUB_SEEK_OFFSET to the new timestamp is not enough to show the new
subtitle line. Add 0.1 instead to fix it. 0.01 is already enough for
sub-step.
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.
fopen() with 'x' mode is a non-portable glibc extension, is currently
unused, and should not be used in order to maintain POSIX compatibility.
Thus there is no need for the Windows wrapper mp_fopen() to support it.
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.
There are good reasons to bind Ctrl+WHEEL_UP/WHEEL_DOWN to video-zoom:
- They are ubiquitous and familiar key bindings to represent zooming
operations, which are used in all popular web browsers, document viewers,
and document editors.
- Because WHEEL_UP/WHEEL_DOWN are scaled with high-resolution scrolling
input devices like touchpads, this allows smooth zooming.
- This makes "pinch to zoom" with touchpads and touchscreens work out of
box on Windows, since by default applications receive these key inputs
for pinch gesture.
- It had been considered to bind these keys to window-scale instead.
However, this results in horrible UX as the keybinds work only when the
mouse pointer is over the mpv window, and if the window shrinks during
this operation, the window below mpv now receives these keybinds,
resulting in unwanted zooming for that window, which violates the principle
of least surprise.
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.
Deprecated upstream 1cc24d7495
We need to reallocate the context here because `avcodec_free_context`
also frees the context, and we want to reuse the context with some
reconfig.
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
Homebrew finally pulled the plug on lua 5.1*, and it is no more. So we
have to change to a different lua package and the only other choice is
luajit (no 5.2 in homebrew). We used to use luajit for the ci, but
649556b2b6 switched it to lua 5.1. As
explained there, luajit 2.0 was horribly bugged and not usuable for mpv
and the build had to do dumb hacks to work around it. I expected 5.1 to
last a bit longer than a couple of years, but luckily it seems like
luajit in homebrew now pulls a luajit 2.1 version (some rolling release
thing or however upstream works). The details don't really matter for
us since 2.1 does not have all the awful issues that 2.0 used to have.
So just switch to luajit again.
*: 57d73df3ba
Since 03cf150ff3516789d581214177f291d46310aaf4, the only purpose of this
VOCTRL was to signal a redraw to the vo. It actualy could have been
removed in 531868fe0d2a35fbbff78d9a9ff8f96df73e69fd, 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.
