This makes use of the new frame acquire/release callbacks to hold on to
hwdec images only as long as necessary. This should greatly improve the
smoothness/efficiency of hwdec interop, by not holding on to them for
longer than needed.
This also avoids the need to pool hwdec mappers altogether.
Should fix#10067 as well, since frames are now only mapped when we
actually use them.
There's really nothing vulkan-specific about this hwdec wrapper, and it
actually works perfectly fine with an OpenGL-based ra_pl. This is not
hugely important at the time, but I still think it makes sense in case
we ever decide to make vo_gpu_next wrap OpenGL contexts to ra_pl instead
of exposing the underlying ra_gl.
libplacebo v198 fixed this properly by adding the ability to flip planes
directly, which is done automatically by the swapchain helpers.
As such, we no longer need to concern ourselves with hacky logic to flip
planes using the crop. This also removes the need for the OSD coordinate
hack on OpenGL.
Render subs at the output resolution, rather than the video resolution.
Uses the new APIs found in libplacebo 197+, to allow controlling the OSD
resolution even for image-attached overlays.
Also fixes an issue where the overlay state did not get correctly
updated while paused. To avoid regenerating the OSD / flushing the cache
constantly, we keep track of OSD changes and only regenerate the OSD
when the OSD state is expected to change in some way (e.g. resolution
change). This requires introducing a new VOCTRL to inform the VO when
the UPDATE_OSD-tagged options have changed.
Fixes#9744, #9524, #9399 and #9398.
See the previous commit for the full explanation. Basically, luajit 2.0
has a bad pc file on macos that causes libmpv to fail during build. The
workaround was, if the os was darwin and luajit was found, to save a
full luajit dep and a partial luajit dep with the link args removed. The
partial dep was used for compiling libmpv, and the full dep was used for
the actual mpv executable. This worked and was needed for the CI to pass
but it sucked. Since the previous commit now makes the CI grab lua 5.1,
we don't need all this crap anymore. Just delete it and treat the
dependency normally.
This does effectively mean that building libmpv with luajit 2.0 on macOS
will no longer work with the meson build. However libraries not being
built correctly is not a mpv-specific issue. The waf build will succeed
for some reason, but it has known issues and it would be better if it
just failed honestly. An upstream developer said years ago that that
macOS users should use the 2.1 branch (and there's no release of
course). In any case, no macOS user should be building mpv with luajit
2.0, so we shouldn't be going out of our way to support this.
https://github.com/mpv-player/mpv/issues/7512https://github.com/LuaJIT/LuaJIT/issues/521#issuecomment-562999247
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)
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 78cfeee2b9.
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.
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
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.
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>
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.
Back when the meson build was still in the PR state, this particular
variable was a dictionary. Later, it was refactored to simply be a
feature object instead. All uses of egl_drm['use'] should have been
replaced with egl_drm.allowed() but this particular line was missed
(that's what I get for not just doing find/replace). The conditional in
this line is usually satisified before egl_drm ever needs to be checked
which was why no one noticed until now. Fixes#9631.
shaderc is a special case dependency in meson. According to the
documentation*, it first checks for shaderc_shared and will fallback to
shaderc_combined (the order is reversed if the static keyword is true).
However, shaderc also has a third .pc file (shaderc_static) which should
be checked. The meson documentation doesn't indicate this, but it also
actually checks shaderc_static*. shaderc_combined is first checked if
meson looks for static libs and if that is not found it tries
shaderc_static. So this extra fallback check is not needed.
*: https://mesonbuild.com/Dependencies.html#shaderc
*: a2934ca9d1/mesonbuild/dependencies/misc.py (L539)
Not all deprecated symbols were removed. Only three events were removed for now
since these are not used internally.
This bumps the library version to 2.0.
The initial iconv dependency worked everywhere but was broken on
freebsd. This was fixed in 0.60.2 but the fix accidentally broke mingw
(ouch; kind of my fault for not double checking). There's another PR to
fix this but that won't land until 0.60.3 so for the meantime just
if/else this (both freebsd and windows work with the system method)
until we want to bump the meson version (probably not for a while since
opensuse tumbleweed is weirdly slow).
This is done to avoid cluttering vo_gpu_next.c with more ifdeffery and context-specific code
when additional backends are added in the near future.
Eventually gpu_ctx is intended to take the place of ra_ctx to further separate gpu and gpu_next.
Following the previous commit, we can just set gnu_symbol_visibility to
'hidden' to hide everything except for the symbols we explictly want to
export. This should work on gcc, clang, and msvc.
The original implementation had some errors with regards to android. Add
a couple of missing files, add the android library, fix the aviocontext
bytes_read check, fix egl-android, and rearrange/tidy up the vulkan
handling.
A few custom targets had some less than optimal names which created some
misleading "Generating custom-target-name with a custom command"
messages. Change those to be more descriptive/correct. In a few other
places, some checks were being done that could easily be
skipped/ignored in certain cases (like checking for windows-related
headers when gl-win32 isn't true). Also rearrange that to be smarter.
Finally, print some extra libplacebo messages for enabling/disabling
vo_gpu_next.
This test fails because the compiler object does not have -Wformat when
it tries this flag. To fix this this, we have to pass both -Wformat and
-Werror=format-security at the same time during the test. This requires
us to use has_multi_arguments so this flag needs to be pulled out of
this array and tested separately.
Leo Izen
Niklas Haas
Dudemanguy
Andrew Krasavin
LaserEyess
Thomas Weißschuh
Philip Langdale
sfan5
Solomon Choina