summaryrefslogtreecommitdiffstats
path: root/meson.build
Commit message (Collapse)AuthorAgeFilesLines
* meson: don't require swift when checking macos sdkDudemanguy2023-09-271-4/+8
| | | | | | | 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.
* meson: enable cplugins on WindowsKacper Michajłow2023-09-201-2/+2
| | | | Fixes: #12185
* meson: check vulkan versionsyphyr2023-09-131-1/+1
| | | | | The symbol "vkGetPhysicalDeviceProperties2" was recently added after refactoring context.c.
* meson: rename last feature with underscoresfan52023-09-111-1/+1
| | | | fixes: ecbaf347010530cb7ca1858486e001f804811921
* meson: add -Bsymbolic for libmpvKacper Michajłow2023-09-071-0/+1
| | | | | | | | | 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
* meson: include our local copy of libavutil uuid if ffmpeg is too oldPhilip Langdale2023-09-041-0/+5
| | | | | | | | | 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.
* meson: rename all features with underscoressfan52023-08-201-10/+9
| | | | The convention is to use dashes.
* meson: remove redundant libplacebo version check for Vulkan interopPhilip Langdale2023-08-191-2/+2
| | | | | | 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.
* x11: remove xinerama and refactor window geometryDudemanguy2023-08-201-1/+0
| | | | | | | | | | | 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.
* x11: require randr 1.4Dudemanguy2023-08-201-1/+1
| | | | | | 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.
* meson: remove redundant libplacebo-next checkNiklas Haas2023-08-181-11/+3
| | | | Now implied by the minimum libplacebo version.
* meson: bump minimum libplacebo dependency to v6.292Niklas Haas2023-08-181-1/+1
| | | | To remove a bunch of #ifdef templating.
* build: check for SNDCTL_DSP_HALT for oss-audioLeonardo Taccari2023-08-161-1/+1
| | | | | | | 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.
* vf_vapoursynth: save display resolution as a variableDudemanguy2023-08-131-2/+2
| | | | | | | | | | | | | | 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
* build: remove version.pyKacper Michajłow2023-08-021-7/+2
| | | | | | | | | | | | | 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.
* drm: bump minimum version to 2.4.105LaserEyess2023-07-311-4/+1
| | | | | Debian 12 is out, with 2.4.114, and Ubuntu 22.04 has 2.4.110, this #ifdef is no longer needed
* build: remove outdated generated directoryDudemanguy2023-07-311-8/+23
| | | | | | | | | | | | | | | | 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.
* ao_sndio: use sio_flush() to improve controls responsivenessAlexandre Ratchov2023-07-301-0/+1
| | | | Use sio_flush() instead of sio_stop() to improve controls responsiveness.
* meson: look for linux/input-event-codes.h with libwayland flagsJan Beich2023-07-291-1/+3
| | | | | | | | | 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
* build: remove unneeded libdl requirement for vaapiDudemanguy2023-07-251-2/+2
| | | | | | | | | | | | | 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.
* build: refactor vaapi handlingGusar3212023-07-251-16/+21
|
* build: vaapi-x-egl is not used anywhere, remove itGusar3212023-07-241-1/+0
|
* build: vaapi-egl should explicitly depend on eglGusar3212023-07-241-1/+1
|
* build: vaapi-drm and vaapi-wayland do not depend on eglGusar3212023-07-241-2/+2
|
* build: internally rename gl-wayland to egl-waylandDudemanguy2023-07-231-3/+3
| | | | | | 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.
* Revert "vo_gpu_next: use pl_dispatch_info_move to avoid useless data copy"sfan52023-07-231-2/+2
| | | | | | | | 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.
* build: make dmabuf-wayland a build option and require drmDudemanguy2023-07-141-8/+12
| | | | | | | 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.
* vo_gpu_next: use pl_dispatch_info_move to avoid useless data copyKacper Michajłow2023-07-021-2/+2
| | | | | Instead copy the data on-demand when VOCTRL_PERFORMANCE_DATA is requested.
* video/image_writer: add avif screenshot supportcloud116652023-07-011-0/+1
| | | | | | | | | | 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
* osdep: add mp_get_user_langsrcombs2023-06-251-1/+4
|
* osdep: move cfstr<->cstr conversions to a new apple_utils.c filercombs2023-06-251-1/+2
|
* misc: add language-matching utilitiesrcombs2023-06-251-0/+1
|
* ao_pipewire: bump dependency to 0.3.48Thomas Weißschuh2023-06-211-1/+1
| | | | | | | | 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>
* wayland: bump wayland-protocols to 1.25Dudemanguy2023-06-161-1/+1
| | | | | 1.27 would have been nicer but ubuntu 22.04 is on 1.25 so we'll just compromise.
* wayland: bump required version to 1.20Dudemanguy2023-06-161-2/+2
| | | | This lets us remove some ifdefs.
* hwdec_cuda: bump required headers version for timeline semaphoresPhilip Langdale2023-06-041-1/+1
| | | | | | | | 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.
* hwdec_vulkan: check for the correct libplacebo versionPhilip Langdale2023-05-291-2/+2
| | | | It's 6.278, rather than 5.278.
* hwdec_vulkan: simplify requirement checks for Vulkan interopPhilip Langdale2023-05-291-4/+3
| | | | | | | | | | | | | 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.
* hwdec_vulkan: add Vulkan HW InteropPhilip Langdale2023-05-281-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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) * Vulkan filters can only be used with drivers that support VK_EXT_descriptor_buffer which doesn't include Intel ANV as yet. There is an MR outstanding for this. * When dealing with 1080p content, there may be some visual distortion in the bottom lines of frames due to chroma scaling incorporating the extra hidden lines at the bottom of the frame (1080p content is actually stored as 1088 lines), depending on the hardware/driver combination and the scaling algorithm. This cannot be easily addressed as the mechanical fix for it violates the Vulkan spec, and probably requires a spec change to resolve properly. All of these caveats will be fixed in either drivers or ffmpeg, and so will not require mpv changes (unless something unexpected happens) If you want to run on nvidia with the non-beta drivers, you can this ffmpeg tree with the work-around patches: * https://github.com/philipl/FFmpeg/tree/vulkan-nvidia-workarounds
* vo_dmabuf_wayland: rewrite around wl_listDudemanguy2023-05-241-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
* osdep: separate out macos paths from path-unix.cDudemanguy2023-05-091-2/+7
| | | | | | | | | | | macOS really has completely different path conventions that mpv doesn't take into account and it treats it just like any other old unix-like system. This means mpv enforces certain conventions on it (like all the XDG stuff) that doesn't really apply. Since we'd like to use more of this but at the same time not distrupt mac users even more, let's just copy and paste the current code to a new file, update the build and call it a day. This way, the paths of these two platforms can more freely diverge.
* meson: bump required version to 0.62Dudemanguy2023-05-021-10/+6
| | | | | This lets us use meson's custom dl dependency as well as the version method when checking rst2pdf's version.
* meson: use the new build_options methodDudemanguy2023-04-111-6/+9
| | | | | | | | This finally allows us to put any user defined options into the CONFIGURATION variable like what waf does. The arbitrary hardcoded fallback is left in place for old meson versions. Also update the documentation in regards to the mpv-configuration variable to be relevant to meson.
* win32: follow Windows settings and update dark mode stateKacper Michajłow2023-04-041-0/+1
| | | | | | | | | | | | | | | | | Microsoft documented how to enable dark mode for title bar: https://learn.microsoft.com/windows/apps/desktop/modernize/apply-windows-themes https://learn.microsoft.com/windows/win32/api/dwmapi/ne-dwmapi-dwmwindowattribute Documentation says to set the DWMWA_USE_IMMERSIVE_DARK_MODE attribute to TRUE to honor dark mode for the window, FALSE to always use light mode. While in fact setting it to TRUE causes dark mode to be always enabled, regardless of the settings. Since it is quite unlikely that it will be fixed, just use UxTheme API to check if dark mode should be applied and while at it enable it fully. Ideally this function should only call the DwmSetWindowAttribute(), but it just doesn't work as documented. Fixes: #6901
* build: add check for eglext_angle.h when checking for ANGLEKacper Michajłow2023-04-021-3/+8
| | | | | | This better follows the actual required bits, and makes sure that a file not part of standard EGL headers is available, as the handle type is part of standard EGL extensions header.
* build: add an option to control gpu-nextKacper Michajłow2023-03-281-10/+10
| | | | Also simplify meson logic
* meson: fix libplacebo-next version comparisonPhilip Langdale2023-03-261-1/+1
| | | | Should just compare against '264'.
* meson: bump libplacebo-next required version to 5.264Philip Langdale2023-03-261-3/+3
| | | | | | | This is the latest stable release, and what we should use for libplacebo-next per haasn's recommendation. The previous 202 version wasn't even a release.
* meson: rst2pdf handle dependency fileThomas Weißschuh2023-03-241-1/+11
|
* test: integrate unittests with mesonDudemanguy2023-03-021-14/+16
| | | | | | | | | | | | This reworks all of mpv's unit tests so they are compiled as separate executables (optional) and run via meson test. Because most of the tests are dependant on mpv's internals, existing compiled objects are leveraged to create static libs and used when necessary. As an aside, a function was moved into video/out/gpu/utils for sanity's sake (otherwise most of vo would have been needed). As a plus, meson multithreads running tests automatically and also the output no longer pollutes the source directory. There are tests that can break due to ffmpeg changes, so they require a specific minimum libavutil version to be built.
* player: remove unittest optionDudemanguy2023-03-021-17/+0
| | | | | | | | | Since meson has its own unit testing system, let's rework mpv's tests so they integrate nicely with this. To prepare for this, start off by dropping the unittest option. Of course, this means that tests will no longer be supported in the waf build at all but it will be dropped anyway. Note that the tests option is preserved for the meson build. We will still make use of this in the future commits.
* zimg: add ZIMG_TRANSFER_ST428 mappingKacper Michajłow2023-03-021-0/+1
|
* command: add platform propertyDudemanguy2023-02-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | This returns the value of the target OS that mpv was built on as reported by the build system. It is quite conceivable that script writers and API users would need to make OS-dependent choices in some cases. Such people end up writing boilerplate/hacks to guess what OS they are on. Assuming you trust the build system (if you don't, we're in really deep trouble), then mpv actually knows exactly what OS it was built on. Simply take this information at configuration time, make it a define, and let mp_property_platform return the value. Note that mpv has two build systems (waf and meson), so the names of the detected OSes may not be exactly the same. Since meson is the newer build system, the value of this property follows meson's naming conventions*. In the waf build, there is a small function to map known naming deviations to match meson (i.e. changing "win32" to "windows"). waf's documentation is a nightmare to follow, but it seems to simply take the output of sys.platform in python and strip away any trailing numbers if they exist (exception being win32 and os2)*. *: https://mesonbuild.com/Reference-tables.html#operating-system-names *: https://waf.io/apidocs/Utils.html#waflib.Utils.unversioned_sys_platform
* Vulkan: add configure check for VK_KHR_display extensionrcombs2023-02-201-1/+7
| | | | This allows building directly against ICDs that don't implement this extension.
* meson: move vector check inside of meson.buildDudemanguy2023-02-021-3/+5
| | | | | It's three lines. There's no real reason to have this as a separate file when we've removed every other compile check sourced from outside files.
* meson: check macos touchbar with has_headerDudemanguy2023-02-021-2/+2
|
* meson: check pthread provider with has_functionDudemanguy2023-02-021-10/+10
| | | | | Previously, we did this doing code fragments, but we can be a bit more clever and use has_function as well as the platform we're on.
* meson: replace check_header with has_headerDudemanguy2023-01-311-2/+2
| | | | | | | | It turns out that there's a has_header check, and we should actually be using that instead. We only care here if the header actually exists so the pre-processor check is all that is needed. check_header depends on what arguments the user passes among other things. That makes it more complicated than necessary for our purposes.
* meson: actually use -Werror=format-securityDudemanguy2023-01-311-1/+1
| | | | | | We tested for this flag, but never added -Wformat in addition to -Werror=format-security. The latter was silently ignored and actually did nothing.
* meson: add missing library dep for egl_angle_lib checkKacper Michajłow2023-01-281-0/+5
|
* meson: reuse libmpv objects for cplayerThomas Weißschuh2023-01-261-10/+13
| |