| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
older macOS dev tools were inconsistent with the way how SDK versions
were returned, some truncated the minor versions. in those cases the
SDK version had to be retrieved through the SDK build version.
recently the scheme for the SDK build version changed that our heuristic
for converting it to an SDK version produced wrong version strings.
the stride of the minor version changed from 1 to 2, so SDK versions
ended up higher than they actually were. furthermore macOS 11 was
hardcoded.
since Xcode 12 Apple fixed the SDK version retrieval and it is no longer
truncated when using Xcode as dev tools. Xcode 12 is also the latest
supported version on macOS 10.15, which is also our oldest supported
version. we can remove the old SDK build version conversation and use
the Xcode only tool to retrieve the SDK version in the case Xcode is
used as dev tools. furthermore this als keeps support for Xcode 11 where
the problem wasn't fixed yet, but is still a supported version on macOS
10.15.
Fixes #9907
|
|
|
|
|
|
|
|
|
|
|
| |
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 f5ca11e12bc55d14bd6895b619c4abfd470c6452
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.
|
| |
|
| |
|
| |
|
|
|
|
| |
And remove redundant define while at it.
|
| |
|
|
|
|
|
|
|
|
| |
Since we can no longer rely on distuils for a version comparison, let's
modify the macos-sdk-version script so it returns multiple potential
versions to meson. Then use meson's built-in version comparison to pick
the right one instead. This avoids the complication of needing certain
python packages installed since everything simply uses stdlib functions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since distutils was dropped from python 3.12, we can't rely on a
standard library implementation for version comparison anymore hence
the switch to packaging instead which is essentially supposed to be the
replacement. This is problematic though because macOS can have several
ways of managing python can result in the build calling the wrong python
binary that doesn't have the actual packaging library installed. This
commit was a workaround for that since it would fetch the python used to
run the build (which is probably the one the user wants), but apparently
upstream doesn't like this and it's subject to change*. So instead,
let's solve try, and solve this a different way.
This reverts commit a57bd8e2b8a1871dc2613984b7ca93dd7bcb5419.
*: https://github.com/mesonbuild/meson/pull/12116#pullrequestreview-1575846647
|
|
|
|
|
|
|
|
|
|
| |
- Use import to find Python installation.
- Run macos-sdk-version.py with Python provided by meson.
This fixes an error when meson and python-packaging are installed from
Homebrew. Currently, the Python executable from python@3.12 is installed as
python3.12 so python3 is referring to system installation, which may not
have packaging module. meson can provide the correct executable via import.
|
| |
|
|
|
|
| |
This causes more pain than it is worth
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
The meson build has always compiled with c_std=c11. This was never
really needed.
|
|
|
|
|
| |
even msvc (which mpv apparently doesn't support) supports C11 atomics
now. no need to carry around fallback with subtle semantic differences.
|
| |
|
|
|
|
|
|
| |
CDIO_API_VERSION 6 has been around since libcdio 0.90. That was release
over a decade ago. There's literally no reason to keep the ugly mess of
the old api around so remove it.
|
|
|
|
|
|
| |
For better feedback on build status and to keep mpv warning free.
Except for macos builds, there are more issue there that need fixing.
|
|
|
|
|
|
|
|
| |
add support for vulkan through metal and a translation layer like
MoltenVK. also add the possibility to use different render timing modes
for testing.
i still consider this experimental atm.
|
|
|
|
|
|
|
|
|
|
| |
On linux, several platforms poll for events over a fd. This has ms
accuracy, but mpv's timer is in ns now so lots of precision is lost. We
can use an mp_poll wrapper to use ppoll instead which takes a timespec
directly with nanosecond precision. On systems without ppoll this falls
back to old poll behavior. On wayland, we don't actually use this
because ppoll completely messes up the event loop for some unknown
reason.
|
|
|
|
|
|
|
| |
Originally, this was added as purely a shim for macOS. However since we
want to do high resolution polling which is not neccesarily available on
all platforms, making this a generic wrapper for poll functions is
useful so rename it.
|
|
|
|
|
|
| |
This allows libmpv users to build it as a subproject easily, i.e. meson
setup build --force-fallback-for=mpv -Dmpv:libmpv=true, if the mpv
source is in the subprojects directory. Mainly useful for development.
|
| |
|
| |
|
|
|
|
|
|
|
| |
It turns out that iOS doesn't actually need swift so this sdk check was
too strict and the build failed. Instead, only check this if we have
darwin and then make sure that the osdep subdir is only executed if
there are swift sources in the list. Fixes #12161.
|
|
|
|
| |
Fixes: #12185
|
|
|
|
|
| |
The symbol "vkGetPhysicalDeviceProperties2" was recently added
after refactoring context.c.
|
|
|
|
| |
fixes: ecbaf347010530cb7ca1858486e001f804811921
|
|
|
|
|
|
|
|
|
| |
This is required when linking ffmpeg statically and generally good
practice to have on shared libraries anyway.
Prerequisit for fixes in mpv-build for:
https://github.com/mpv-player/mpv-build/issues/215
https://github.com/haasn/libplacebo/issues/198
|
|
|
|
|
|
|
|
|
| |
In the previous change, I added the uuid files. In this change, we
check the libavutil version and if it's too old, we compile in our
local copy.
We have to change the include paths of the uuid code to find some other
libavutil headers, but nothing beyond that.
|
|
|
|
| |
The convention is to use dashes.
|
|
|
|
|
|
| |
With the bump of the required base libplacebo version, we no longer
need to do an additional check for Vulkan interop - it will always be
new enough.
|
|
|
|
|
|
|
|
|
|
|
| |
mpv mixes xinerama and randr usage together which gets kind of
confusing and is also pretty stupid. Xinerama is completely unneccesary
today since randr can do everything it can do and much more. Remove it.
This reworks a lot of the window/geometry handling stuff to be centered
completely around xrandr_display plus some other tweaks to the geometry
handling. An important concept is that current_icc_screen is changed
into current_screen and used more generously since it is useful for
things besides just icc profiles.
|
|
|
|
|
|
| |
There really is no reason to not just hard require randr 1.4. xorg added
1.4 support in 2012 and someone somehow using an xorg server older than
that today surely has several other problems.
|
|
|
|
| |
Now implied by the minimum libplacebo version.
|
|
|
|
| |
To remove a bunch of #ifdef templating.
|
|
|
|
|
|
|
| |
At least NetBSD ossaudio(3) right now has SNDCTL_DSP_SETPLAYVOL support
but does not support SNDCTL_DSP_HALT chocking at build time.
NFCI on platforms where oss audio output is supported.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mpv has a generic method for getting the display resolution, so we can
save it in vf_vapoursynth without too much trouble. Unfortunately, the
resolution won't actually be available in many cases (like my own)
because the windowing backend doesn't actually know it yet. It looks
like at least windows always returns the default monitor (maybe we
should do something similar for x11 and wayland), so there's at least
some value. Of course, this still has a bunch of pitfalls like not being
able to cope with multi monitor setups at all but so does display_fps.
As an aside, the vapoursynth API this uses apparently requires R26 (an
ancient version anyway), so bump the build to compensate for this.
Fixes #11510
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After second thought version.py does not do anything useful. Meson has
built-in function vcs_tag that mostly replicate what version.py did. For
the build time we can just use __DATE__ and __TIME__. Of course this
changes time string format a little, but in my opinion it looks nicer in
fact.
Also it will use local time, instead UTC. But I would argue that date
string is only informative for users to check how old the specific mpv
build is. It doesn't have to be precise, it weren't for years anyway
before recent change.
|
|
|
|
|
| |
Debian 12 is out, with 2.4.114, and Ubuntu 22.04 has 2.4.110, this
#ifdef is no longer needed
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This only existed as essentially a workaround for meson's behavior and
to maintain compatibility with the waf build. Since waf put everything
in a generated subdirectory, we had to put make a subdirectory called
"generated" in the source for meson so stuff could go to the right
place. Well now we don't need to do that anymore. Move the meson.build
files around so they go in the appropriate place in the subdirectory of
the source tree and change the paths of the headers accordingly. A
couple of important things to note.
1. mpv.com now gets made in build/player/mpv.com (necessary because of
a meson limitation)
2. The macos icon generation path is shortened to
TOOLS/osxbundle/icon.icns.inc.
|
|
|
|
| |
Use sio_flush() instead of sio_stop() to improve controls responsiveness.
|
|
|
|
|
|
|
|
|
| |
On DragonFly and FreeBSD native evdev headers are not not be used
outside of base system. Linux-compatible headers are provided by
evdev-proto package but require extra flags. As evdev-proto lacks
pkg-config support use libwayland prefix as approximation.
meson.build:974:0: ERROR: C header 'linux/input-event-codes.h' not usable
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Curiously, vaapi requiring libdl has always existed ever since support
was added to mpv (2827295703c74e3c119df9a435aa856e268c2ea9). After some
investigation in IRC from uau and JEEB, it was concluded that the libdl
requirement was blindly copied from the vdpau check above it. At the
time, the vdpau code actually used dlsym so it was needed. The check was
later dropped when waf support was added
(7e2edad8efea55e8df1faa695d1389ef4e326d7c). However, the requirement in
vaapi lived on, and actually it was never needed. libva does use dl when
building its libraries unsurprisingly, but this isn't relevant to mpv in
any way. Just drop it.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This has always been a pet peeve of mine and in fact I named the option
in meson "egl-wayland" with the intention of finally doing this. We call
everything that's egl "egl-foo" internally except for wayland.
|
|
|
|
|
|
|
|
| |
We wanted to preserve the libplacebo v5.264.0 requirement for gpu_next
for this release, since this is the what most Linux distributions are shipping.
The VLC 3 <-> libplacebo v6 situation is an additional reason distros are not
likely to ship the newest libplacebo release soon.
This reverts commit b73d96776cfee61f88bf60b27315baab32a2115d.
|
|
|
|
|
|
|
| |
It makes more sense as an option at this point. Also libdrm is not
optional at all. You have to get a drm format and modifier for this to
even work (the VO will just fail without DRM). Just hard require it and
remove the guards. vaapi can remain optional.
|
|
|
|
|
| |
Instead copy the data on-demand when VOCTRL_PERFORMANCE_DATA is
requested.
|
|
|
|
|
|
|
|
|
|
| |
Notes:
- converts the (image) write() api to filenames, because using avio
with FILE* is a pain.
- adds more debug logs for screenshots.
build: rename av1 dependency to avif_muxer
wscript: unify lavf dependency with meson
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Now that Debian 12 is release bump the minium required version to what
is provided in Ubuntu Jammy (22.04).
The same as has been done for the wayland dependencies.
Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
|
|
|
|
|
| |
1.27 would have been nicer but ubuntu 22.04 is on 1.25 so we'll just
compromise.
|
|
|
|
| |
This lets us remove some ifdefs.
|
|
|
|
|
|
|
|
| |
We're moving to using timeline semaphores for synchronisation between
cuda and vulkan. It's only required with libplacebo-next right now,
but eventually our baseline libplacebo requirement will increase, so we
will need new enough nvidia headers that include the necessary
declarations.
|
|
|
|
| |
It's 6.278, rather than 5.278.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I originally wrote this trying to avoid doing an explicit version check
on the headers, but it just makes things more confusing, and the
requirements harder to understand.
So, Vulkan interop now takes a dependency on the header release where
they finalised the video decode headers. VK_EXT_descriptor_buffer was
added in 1.3.235, so that's covered as well.
Along the way I fixed a bug in the waf build where it was depending
on libplacebo-next instead of libplacebo-decode.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Vulkan Video Decoding has finally become a reality, as it's now
showing up in shipping drivers, and the ffmpeg support has been
merged.
With that in mind, this change introduces HW interop support for
ffmpeg Vulkan frames. The implementation is functionally complete - it
can display frames produced by hardware decoding, and it can work with
ffmpeg vulkan filters. There are still various caveats due to gaps and
bugs in drivers, so YMMV, as always.
Primary testing has been done on Intel, AMD, and nvidia hardware on
Linux with basic Windows testing on nvidia.
Notable caveats:
* Due to driver bugs, video decoding on nvidia does not work right now,
unless you use the Vulkan Beta driver. It can be worked around, but
requires ffmpeg changes that are not considered acceptable to merge.
* Even if those work-arounds are applied, Vulkan filters will not work
on video that was decoded by Vulkan, due to additional bugs in the
nvidia drivers. The filters do work correctly on content decoded some
other way, and then uploaded to Vulkan (eg: Decode with nvdec, upload
with --vf=format=vulkan)
|