| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
It appears MinGW switched their pkg config implementation from pkg-config to pkgconf,
causing all builds to fail because we requested the former.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This speeds up chapter name access while hovering the seekbar:
- Fetch the chapter-list property using observation rather than on
every render while hovering the bar. Property access, especially
with potentially lots of values (chapters), can be expensive-ish,
and can involve locking, so the less per-render the better.
- Sort the list once (on change) to simplify the iteration logic when
searching the chapter which matches the mouse position. It's still
O(N) (no binary search currently), but with less work.
The cached sorted list is stored at the state. While there are other
places which access this property and could use this cache, for now we
don't touch them, because they're not performance-critical (on init
for the chapter markers, on ch_{prev,next} button click for OSD).
Caching properties using observation instead of using mp.get_property
can indeed speedup other places too, but it should be part of a system
rather than implemented per-property. Maybe some day.
|
|
|
|
|
|
|
|
| |
When utils.get_user_path was added, the expand-path command didn't
exist. Now it does, so remove the C code, make it a trivial wrapper.
Keep this function for backward compat to not break scripts, but
technically it's not required anymore.
|
|
|
|
|
| |
`target_dummy` got deprecated in version v4.169. We unfortunately have
to hide this behind an #if for the time being.
|
|
|
|
|
| |
`caps` is deprecated, and replaced by individual fields in
`pl_glsl_version` / `pl_gpu_limits`.
|
|
|
|
|
| |
All of these const struct pointers got typedefs, clean up the code
accordingly.
|
|
|
|
|
| |
Use the pl_log APIs introduced in libplacebo v4, replacing the
deprecated pl_context concept.
|
|
|
|
|
|
| |
This has been the latest stable release for about half a year now. This
version in particular lets us get rid of all the deprecation warnings in
the older code. (See the following commits)
|
|
|
|
|
| |
Failing to do this results in the shader cache not actually ever being
written, ergo no shader caching being done. Oops.
|
|
|
|
|
| |
Rename from "libplacebo-v4" to "libplacebo-next" to more closely capture
the intent, since this will become libplacebo v5 eventually (tm).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The wayland backend contains logic to detect if the window is hidden. If
so, we skip rendering as an optimization. However, if we receive
multiple resize events in rapid succession, we will send the compositor
new buffers faster than the refresh rate of the monitor. Therefore the
compositor will not send us frame events which we incorrectly interpret
as the window being hidden.
Once the last buffer has actually been rendered, the compositor sends us
a frame event. However, if at that point playback is paused, there is no
logic to restart rendering of frames that we skipped due to the above
optimization. Therefore we never send the compositor new buffers
corresponding to the new size of the window and the surface will either
be too small or too large.
The simplest solution is to always render a few frames after we receive
a resize event.
|
| |
|
|
|
|
| |
filter kernels: add cosine window
|
|
|
|
|
|
|
|
| |
Was done in meson.build as part of
a9cb2e2821adb40e7548e8233390e79706104041 , but the waf wscript
was missed.
This brings the two files in sync again.
|
| |
|
|
|
|
| |
This prepares us to not duplicate all of this code for d3d11.
|
|
|
|
| |
This enables us to utilize it from gpu-next.
|
|
|
|
|
|
|
|
| |
vo_gpu_next and libplacebo expect swapchain images to be able to be
blitted to, which for libplacebo on FL11_0 and up means they have to
have DXGI_USAGE_UNORDERED_ACCESS, since libplacebo uses a compute shader
to emulate certain kinds of blits. For libplacebo's benefit, set all
applicable usage flags on swapchain images.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The docs specify that the +-X+-Y geometry values position the content.
This used to work correctly but got broken at 8fb4fd9a .
Geometry size is unaffected - this only concerns position.
Commit 8fb4fd9a made it center the window rather than the content by
taking the borders into account during positioning, but forgot to make
an exception when a position is specified explicitly.
This commit adds this exception, and now if a specific position is
requested then the borders are ignored, and the content is positioned
correctly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code assumed that the value of the profile-restore field is
"default" for such profiles, but the C implementation is such
that the field is intentionally omitted in such case.
This resulted in incorrectly trying to restore such profiles. However,
there are no stored values with profile-restore=default, so it only
resulted in a harmless warning, but otherwise behaved correctly (i.e.
nothing is restored).
Fix the condition by taking into account that missing field means
"default", so that it doesn't try to restore in such case, and
avoid the warning.
|
|
|
|
|
|
|
|
| |
Currently the profile-restore field is intentionally omitted if it
holds the default value (i.e. no values are stored for the profile,
and trying to restore would only warn).
See m_config_get_profiles at command.c .
|
|
|
|
|
| |
This was mistakenly left out. mpv requires at least 1.15 for the
xdg-decoration protocol. This just matches the waf build.
|
|
|
|
|
|
|
|
|
|
|
|
| |
a02901cae77c86fb9de997a418296d1fc0e3eada changed how mpv was handling
wl_surface_set_buffer_scale. It's correct in that constantly setting the
surface scale on every resize (which mpv was previously doing) is
unneccessary and not right. However, it introduced a slight regression
if someone moved a surface to a new monitor with the same resolution but
a different scale. It did not trigger a resize and thus the video would
have incorrect dimensions. A later refactor changed how things looked
inside here, but this regression wasn't fixed. A resize should always be
triggered if the scale changes in this surface event. Fixes #9426.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mouse button event codes above `BTN_EXTRA` (the ones currently defined
in `input-event-codes.h` are `BTN_FORWARD`, `BTN_BACK`, and `BTN_TASK`)
are mapped to `MP_MBTN9` and up. (Reminder that due to historical
reasons, the names `BTN_FORWARD` and `BTN_BACK` are completely
misleading; the real forward and back buttons are `BTN_SIDE` and
`BTN_EXTRA` and are already mapped correctly by mpv.)
This functionality is analogous to what the X11 backend supports in
`video/out/x11_common.c` and what the Cocoa backend supports in
`video/out/cocoa/events_view.m`.
|
|
|
|
|
|
|
|
|
|
|
| |
According to the xdg-shell protocol spec, a 0x0 size from the compositor
means that "the client should decide its own window dimension". We were
not doing this correctly. What should happen is that mpv should simply
reuse the old window size if it is not maximized or fullscreened. This
should work on all (reasonably recent) versions of mutter and an
compositor that follows the spec.
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/xdg-shell/xdg-shell.xml#L1050
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So actually according to the xdg-shell spec, a 0x0 resize is meant to
indicate that "the client should decide its own window dimension".
Previously, this just accidentally worked. In mutter 41.3, they changed
how 0x0 resizes were sent and what actually happened was that mpv tried
to resize itself to 0x0. This was obviously broken, so the reverted
commit naively just ignored 0x0. It actually seemed to work, but it
ended up breaking older versions of mutter. It's also not exactly the
correct fix so it deserves a revert.
This reverts commit d16defac27fcfe3e5fc43af6e42c2e590988cd3d.
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/xdg-shell/xdg-shell.xml#L1050
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This define was always just a stopgap for that two month period (August
2021 - October 2021) where the bytes_read field in ffmpeg was completely
missing. Before that time, it was a private member in a struct (which
mpv used). Afterwards, it officially became public. Fortunately, the
lack of this field never actually made it into a release, so it could
have only possibly affected people building from the master branch.
Since ffmpeg 5.0 came out recently, and it's been plenty of months since
that two month window, we can go ahead and drop this check. This
finishes up the work done in 78cfeee2b93830f2988508a653b508336147b79d.
Sidenote: the cached ffmpeg version in the mingw ci were from that time
period when the bytes_read field was missing. The N in the workflow is
bumped to force a full rebuild and fresh clone of ffmpeg.
|
|
|
|
|
|
|
|
|
|
| |
Both _NET_WM_NAME and _NET_WM_ICON_NAME (part of Extended Window Manager
Hints) require that the string is UTF-8*. mpv was not doing this and
thus violating the spec. Just sanitize the title for these two atoms.
Note that XA_WM_NAME and XA_WM_ICON_NAME have no such requirement so
those atoms are left the same. Fixes #8812.
*: https://specifications.freedesktop.org/wm-spec/1.3/ar01s05.html
|
|
|
|
|
|
|
| |
The xdg-shell protocol requires that the toplevel title is UTF-8*. Go
ahead and leverage existing mpv tools to sanitize the title. Fixes #9694
*: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/0aaf12157ede8fdf6eda49963da313bd1a7d930f/stable/xdg-shell/xdg-shell.xml#L638
|
|
|
|
|
|
|
|
|
| |
Apparently mutter can send us 0x0 resizes* for whatever reason. Probably
there's some interal reason why this occurs, but for us trying to resize
to 0x0 is obviously terrible and results in all kinds of brokenness.
Just ignore any 0 values. Fixes #9748.
*: https://gitlab.gnome.org/GNOME/mutter/-/issues/2091
|
| |
|
|
|
|
| |
We have this ao again since #9298 so let's run it through the CI.
|
|
|
|
|
|
|
|
| |
Changes:
* fixed hangups in the loop function and in some other cases
* refactoring according to @michaelforney's recommendations in #8314
* a few minor and/or cosmetic changes
* ability to build ao_sndio using meson
|
|
|
|
|
|
|
|
|
| |
Changes:
- rewrite to use new internal MPV API;
- code refactoring;
- fix buffers size calculations;
- buffer set to auto;
- reset() - clean/reinit device only after errors;
|
|
|
|
|
|
|
|
| |
Previously, the sub-visibility option changed the visibility of all
subtitles including secondary ones. This meant that it was not possible
to only display secondary subtitles while hiding the primary ones. This
modifies the sub-visibility option so that it only affects primary
subtitles which allows only secondary subtitles to be displayed.
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 04f0b0abe48d664aaa1400d1dddb02b434999b85.
It's not a good idea to unify the names only for visibility, while
keeping secondary-* for everything else.
This needs a bit more thought before we allow secondary sub to be
visible on its own.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds --sub-visibility choices 'primary-only' for only displaying the
primary subtitle track, and 'secondary-only' for only displaying
secondary subtitle track.
Removes --secondary-sub-visibility and displays a message telling the
user to use --sub-visibility=yes/primary-only instead.
These changes make it so that the default 'sub-visibility' bind 'v'
cycles through all the 'sub-visibility' choices, 'no', 'yes',
'primary-only', and 'secondary-only'.
|
| |
|
|
|
|
|
|
| |
Was tripping -Wparantheses as the && after the || was not explicitly
wrapped. However, due to operator precedence the intended effect was
still correct.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Warning from meson:
WARNING: You should add the boolean check kwarg to the run_command call.
It currently defaults to false,
but it will default to true in future releases of meson.
See also: https://github.com/mesonbuild/meson/issues/9300
All of the run_command() calls currently use need to succeed for the
build to work properly.
|
|
|
|
|
|
|
|
|
|
| |
Sometimes the most obvious things can be missed.
Reflects authorship described in the original commit.
* https://github.com/mpv-player/mpv/pull/7902
* https://github.com/Oschowa/mpv/commit/fddb143282fa74425a8a6f29c9566e51777759d0
* https://github.com/mpv-player/mpv/pull/9587
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The AO provides a way for mpv to directly submit audio to the PipeWire
audio server.
Doing this directly instead of going through the various compatibility
layers provided by PipeWire has the following advantages:
* It reduces complexity of going through the compatibility layers
* It allows a richer integration between mpv and PipeWire
(for example for metadata)
* Some users report issues with the compatibility layers that to not
occur with the native AO
For now the AO is ordered after all the other relevant AOs, so it will
most probably not be picked up by default.
This is for the following reasons:
* Currently it is not possible to detect if the PipeWire daemon that mpv
connects to is actually driving the system audio.
(https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1835)
* It gives the AO time to stabilize before it is used by everyone.
Based-on-patch-by: Oschowa <oschowa@web.de>
Based-on-patch-by: Andreas Kempf <aakempf@gmail.com>
Helped-by: Ivan <etircopyhdot@gmail.com>
|
|
|
|
|
| |
Can be used conditionally (via #ifdef HOOKED_gather) to use
textureGather in custom shaders.
|
|
|
|
|
|
|
|
|
| |
The only way to fix the channel order here is to create the texture with
bgra format. Incidentally, there used to be a way to set the component
map for overlays directly, but no more. Shouldn't matter since
everything supports bgra8 anyways, though.
Fixes #9699
|
|
|
|
|
| |
This was a misnomer, the actual channel order is IMGFMT_BGRA (as the
comment explicitly point out). Rename the enum for consistency.
|
|
|
|
| |
mark an array as static, a typo and a missing free
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
These got added upstream a while ago. Need to be added to the mapping
helpers.
It might be time to think about bumping the minimum dependency here.
Reported-by: Uoti Urpala <uau@glyph.nonexistent.invalid>
|
|
|
|
|
|
|
| |
There was some breakage with regards to the iconv detection in some
older meson versions. This was all settled in 0.60.3 and now it simply
just works. Remove the workarounds and bump the needed meson version to
0.60.3.
|
|
|
|
|
|
|
|
|
| |
When this was originally added, some OS package managers were slow and
behind the required meson version needed for mpv to build. Both opensuse
tumbleweed and freebsd now appear to carry meson 0.60.3 in their repos
so we no longer need to do the two-step process of installing pip3 and
then installing meson via pip. Instead, just use the OS package manager
version.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Useful to strip dolbyvision from the output, in cases where the user
does not want it applied. Doing this as a video filter gives users the
abiilty to easily toggle this stripping at runtime in a way that
properly propagates to any (potentially stateful) VO.
It also thematically fits the rest of the options in vf_format, which
are similarly concerned with modifying the video image parameters.
|
|
|
|
|
|
| |
This needs to be forwarded from the AVStream to the AVPacket itself, so
that it reaches the decoder. There exists an FFmpeg function for this,
we just need to call it. (Also add some logging)
|
|
|
|
| |
Co-authored-by: Niklas Haas <git@haasn.dev>
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of `xkb_keymap_new_from_string`. The protocol does not require
the keymap to be null terminated and if the size of the keymap is a
multiple of the page size, using `_from_string` could lead to problems.
Some compositors include a null byte and even include the null byte in
`size`. Therefore we have to use `strnlen` to find the real length of
the string. Note that `_from_string` internally uses `strlen` and then
calls `_from_buffer`.
|
|
|
|
|
|
|
|
|
|
| |
While mpv uses version 1 of the `wl_seat` protocol and `MAP_PRIVATE` is
only required from version 7 on, using `MAP_PRIVATE` allows us to be
compatible with compositors that have only been tested with newer
applications.
Since the keymap is not modified after `mmap`, using `MAP_SHARED` has no
advantage over `MAP_PRIVATE`.
|
|
|
|
|
|