summaryrefslogtreecommitdiffstats
path: root/wscript
Commit message (Collapse)AuthorAgeFilesLines
* osdep: separate out macos paths from path-unix.cDudemanguy2023-05-091-0/+5
| | | | | | | | | | | 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.
* win32: follow Windows settings and update dark mode stateKacper Michajłow2023-04-041-1/+8
| | | | | | | | | | | | | | | | | 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-2/+3
| | | | | | 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.
* various: fix typosHarri Nieminen2023-03-281-1/+1
| | | | Found by codespell
* build: add an option to control gpu-nextKacper Michajłow2023-03-281-1/+1
| | | | Also simplify meson logic
* wscript: bump libplacebo-next required version to 5.264llyyr2023-03-261-2/+2
| | | | | b77f88157e82e644c88c5e095093ef7229f29542 only bumped the version for meson builds.
* player: remove unittest optionDudemanguy2023-03-021-5/+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/+4
|
* command: add platform propertyDudemanguy2023-02-271-0/+2
| | | | | | | | | | | | | | | | | | | | | | | 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-0/+6
| | | | This allows building directly against ICDs that don't implement this extension.
* vo_opengl/angle_dynamic: simplify symbol renaming to make it more ↵Kacper Michajłow2023-01-281-2/+0
| | | | straightforward
* waf: migrate to version.pyKacper Michajłow2023-01-281-9/+4
| | | | Fixes https://github.com/mpv-player/mpv-build/issues/204
* wscript: remove MSVC from compiler lookupKacper Michajłow2023-01-281-0/+3
| | | | | MSVC is not supported and waf doesn't respect CC environment value like any sane buildsystem.
* wayland: add wp-fractional-scale-v1 supportDudemanguy2023-01-241-0/+5
| | | | | | | | | | | | | This protocol is pretty important since it finally lets us solve the longstanding issue of fractional scaling in wayland (no more mpv doing rendering over the target resolution and then being scaled down). This protocol also can completely replace the buffer_scale usage that we are currently using for integer scaling so hopefully this can be removed sometime in the future. Note that vo_dmabuf_wayland is omitted from the fractional scale handling because we want the compositor to handle all the scaling for that VO. Fixes #9443.
* build: officially deprecate wafDudemanguy2023-01-151-0/+2
| | | | | | | | While the waf build has served us well for many years, it's time to officially consider it deprecated. The meson build was added fully with the intention to eventually replace waf and its current state is more than good enough to do that. Let's start the deprecation period now to give users a heads up to switch before we remove waf for good.
* build: add configure test for POSIX shm for the sake of vo_kittysfan52022-12-261-0/+5
| | | | Android's POSIX coverage is pretty sketchy but not like we have a choice.
* ffmpeg: increase minimum required version to 4.4Philip Langdale2022-12-011-7/+7
| | | | | | | | | Now that 0.35 has been released, we can consider increasing our minimum required ffmpeg version. Currently, we think 4.4 is the most recent version we can move to (from the current requirement of 4.0). This allows us to remove a few conditionals. There are more that we won't be able to remove unless we move further up to 5.1.
* wayland: add support for content-type protocolDudemanguy2022-11-151-0/+5
| | | | | | | | | | | | | | | | | | | | The content-type protocol allows mpv to send compositor a hint about the type of content being displayed on its surface so it could potentially make some sort of optimization. Fundamentally, this is pretty simple but since this requires a very new wayland-protocols version (1.27), we have to mess with the build to add a new define and add a bunch of if's in here. The protocol itself exposes 4 different types of content: none, photo, video, and game. To do that, let's add a new option (wayland-content-type) that lets users control what hint to send to the compossitor. Since the previous commit adds a VOCTRL that notifies us about the content being displayed, we can also add an auto value to this option. As you'd expect, the compositor hint would be set to photo if mpv's core detects an image, video for other things, and it is set to none for the special case of forcing a window when there is not a video track. For completion's sake, game is also allowed as a value for this option, but in practice there shouldn't be a reason to use that.
* build: add an additional check for wayland-protocols 1.24Dudemanguy2022-10-291-0/+5
| | | | | | | | | | | | | | | | | 666cb91cf12a4f8b42087530104513b0fc4ba16d added support for v4 of the dmabuf protocol. This was meant to be optional and the fallback support for the old v2 (dates back to 2017[0] well before the 1.15 wayland-protocol version we depend on) was maintained. However, v4 added several new functions and structs that of course aren't defined in old protocol versions so naturally this breaks the build on those systems. Since this is just a niche feature and not really critical to overall wayland support in mpv, just give in and add another check in the build system and #if out the newer stuff in wayland_common. v4 of linux-dmabuf depends on wayland protocols 1-24[1], so go ahead and make that our new check. Fixes #10807. [0]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commit/a840b3634ad637b237f238d2efb9ab8f4712d5f4 [1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commit/8a5cd28a0e84911a5339855cb32ed63fb57ea40a
* ao_pipewire: compatibility for libpipewire 0.3.19Thomas Weißschuh2022-10-261-1/+1
|
* vo_vaapi_wayland: remove, as it is superceded by vo_dmabuf_waylandAaron Boxer2022-10-261-5/+0
|
* vo_dmabuf_wayland: wayland VO displaying dmabuf buffersAaron Boxer2022-10-261-2/+7
| | | | | | | | | | | | | Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
* wscript: remove some bogus configure optionsDudemanguy2022-10-171-2/+2
| | | | | | | | | It turns out that wayland-scanner and wayland-protocols are both exposed as configure options in waf meaning you can --enable/--disable them at configure time. This is pretty nonsensical. If you want to control wayland in the build, you should just use --enable-/--disable-wayland. wayland-scanner and wayland-protocols should just be typical checks like in the meson build.
* vo_gpu: hwdec: add Android hwdec utilizing AImageReadersfan52022-10-021-0/+6
|
* drm_common: remove hard dependency on drmIsKMS()sfan52022-08-111-0/+6
| | | | | | ae768a1e141eb88243e46757d41ca0cada9502b4 forgot to bump the required libdrm version however Debian 11 just barely misses the requirement, which is a good reason not to require it unconditionally anyway.
* hwdec/dmabuf_interop: use AVDRMFrameDescriptor to describe dmabufsPhilip Langdale2022-08-031-0/+10
| | | | | | | | | | | | Annoyingly, libva and libdrm use different structs to describe dmabufs and if we are going to support drmprime, we must pick one format and do some shuffling in the other case. I've decided to use AVDRMFrameDescriptor as our internal format as this removes the libva dependency from dmabuf_interop. That means that the future drmprime hwdec will be able to populate it directly and the existing hwdec_vaapi needs to copy the struct members around, but that's cheap and not a concern.
* af_rubberband: add new engine option in rubberband 3.0.0Christoph Heinrich2022-08-031-0/+4
|
* x11: support xorg present extensionDudemanguy2022-06-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This builds off of present_sync which was introduced in a previous commit to support xorg's present extension in all of the X11 backends (sans vdpau) in mpv. It turns out there is an Xpresent library that integrates the xorg present extention with Xlib (which barely anyone seems to use), so this can be added without too much trouble. The workflow is to first setup the event by telling Xorg we would like to receive PresentCompleteNotify (there are others in the extension but this is the only one we really care about). After that, just call XPresentNotifyMSC after every buffer swap with a target_msc of 0. Xorg then returns the last presentation through its usual event loop and we go ahead and use that information to update mpv's values for vsync timing purposes. One theoretical weakness of this approach is that the present event is put on the same queue as the rest of the XEvents. It would be nicer for it be placed somewhere else so we could just wait on that queue without having to deal with other possible events in there. In theory, xcb could do that with special events, but it doesn't really matter in practice. Unsurprisingly, this doesn't work on NVIDIA. Well NVIDIA does actually receive presentation events, but for whatever the calculations used make timings worse which defeats the purpose. This works perfectly fine on Mesa however. Utilizing the previous commit that detects Xrandr providers, we can enable this mechanism for users that have both Mesa and not NVIDIA (to avoid messing up anyone that has a switchable graphics system or such). Patches welcome if anyone figures out how to fix this on NVIDIA. Unlike the EGL/GLX sync extensions, the present extension works with any graphics API (good for vulkan since its timing extension has been in development hell). NVIDIA also happens to have zero support for the EGL/GLX sync extensions, so we can just remove it with no loss. Only Xorg ever used it and other backends already have their own present methods. vo_vdpau VO is a special case that has its own fancying timing code in its flip_page. This presumably works well, and I have no way of testing it so just leave it as it is.
* audio: add AVChannelLayout helpers to convert from/to mp_chmapJan Ekström2022-06-121-0/+4
| | | | | | | | | This is the new FFmpeg channel layout structure, which now combines channel count and layout into a single location. Only unspecified (channel count only) and native (channel layout mask based) layouts are currently supported for the initial move towards non-deprecated APIs.
* vo_vaapi_wayland/wayland_common: code style fixesDudemanguy2022-05-301-1/+1
| | | | | | | | A bad person (AKA me) merged this stuff without paying close enough attention to the code style. Reformat this to be in-line with the rest of the wayland code and general mpv style (braces for functions on the next line, horizontally aligning arguments, some cosmetic cleanups for wayland_common.h, etc.).
* vo: add new vaapi-wayland driverAaron Boxer2022-05-241-0/+5
| | | | | | | This driver makes use of dmabuffer and viewporter interfaces to enable efficient display of vaapi surfaces, avoiding any unnecessary colour space conversion, and avoiding scaling or colour conversion using GPU shader resources.
* build: add avcodec jpegxl dependency versionsLeo Izen2022-04-281-0/+4
| | | | | Add the libavcodec version check for AV_CODEC_ID_JPEGXL to the build system rather than to any file that references it.
* vo_gpu_next: switch to unpooled hwdec mappingNiklas Haas2022-04-111-2/+2
| | | | | | | | | | | | 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.
* hwdec_vaapi_vk: rename to vaapi_plNiklas Haas2022-03-031-3/+3
| | | | | | | | 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.
* vo_gpu_next: remove/simplify plane flipping hacksNiklas Haas2022-02-251-2/+2
| | | | | | | | | 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.
* vo_gpu_next: refactor subtitle renderingNiklas Haas2022-02-211-2/+2
| | | | | | | | | | | | | | | 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.
* libplacebo: bump minimum dependency to 4.157Niklas Haas2022-02-031-1/+1
| | | | | | 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)
* build: rename libplacebo version checkNiklas Haas2022-02-031-1/+1
| | | | | Rename from "libplacebo-v4" to "libplacebo-next" to more closely capture the intent, since this will become libplacebo v5 eventually (tm).
* wscript: bump libplacebo version requirement to 4.190Jan Ekström2022-02-021-2/+2
| | | | | | | | Was done in meson.build as part of a9cb2e2821adb40e7548e8233390e79706104041 , but the waf wscript was missed. This brings the two files in sync again.
* build: remove aviocontext bytes_read checkDudemanguy2022-01-251-9/+0
| | | | | | | | | | | | | | | | 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.
* ao_sndio: bugfix and small refactoring for #8314Andrew Krasavin2022-01-221-2/+1
| | | | | | | | 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
* ao_sndio: add this audio output againrim2022-01-221-0/+6
| | | | | | | | | 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;
* ao_pipewire: Add PipeWire audio backendThomas Weißschuh2022-01-171-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* wscript: switch shaderc checks to pkgconfigsfan52021-12-191-3/+3
| | | | | | Shaderc has been shipping .pc files for almost three years and we all know of the advantages. If this turns out to be problematic the old checks can be re-added but I'd like to avoid doing this preemptively.
* context_drm_egl: use gbm_surface_create_with_modifiersPhilip Langdale2021-11-101-1/+1
| | | | | | | | | The GBM supporting nvidia driver doesn't support creating surfaces without modifiers and using modifiers is more and more recommended as the right way to do this. Enumerating modifiers is painfully verbose, but necessary if we are to allow the driver to pick the best possible one.
* vo_gpu_next: fix resource exhaustion on minimized windowsNiklas Haas2021-11-081-2/+2
| | | | | | | | This required an upstream API change to implement in a way that doesn't unnecessarily re-push or upload frames that won't be used. I consider this a big enough bug to justify bumping the minimum version for it. Closes #9401
* vo_gpu_next: add new libplacebo-based rendererNiklas Haas2021-11-031-0/+6
| | | | | | | | | | | | | As discussed in #8799, this will eventually replace vo_gpu. However, it is not yet complete. Currently missing: - OpenGL contexts - hardware decoding - blend-subtitles=video - VOCTRL_SCREENSHOT However, it's usable enough to cover most use cases, and as such is enough to start getting in some crucial testing.
* {wscript,demux_lavf}: clean up last bits of !FFMPEG_STRICT_ABIJan Ekström2021-10-261-4/+8
| | | | | | | | | | | | | | | | | The bytes_read struct member in AVIOContext is now officially public, so its usage no longer has to be specified as non-compliance with FFmpeg's ABI/API rules. That said, unfortunately there was a short period of time between August 2021 and October 2021 where the struct member did not exist in FFmpeg's git master, so keep a feature check for it alive for now to enable building with those versions. Thankfully, no release version of FFmpeg will be without this field, so it should be possible to drop this check with time. Finally, simplify the function in case the struct member is not found. After all, there is zero reason to iterate through the AVIO contexts if we cannot get the information we require.
* drm_common: utilize drmGetDevices when iterating over cardsJan Ekström2021-10-251-1/+1
| | | | | | | | | | | | Based on the idea behind emersion's change to drm_info (https://github.com/ascent12/drm_info/commit/869e789a645b92a99e592a230fe39b0c59a2cd7d). Lets us by default skip devices which are not capable of doing what the DRM master output requires (not primary devices), as some devices have card0 actually not be such. Negative part is that the number given to drm-connector is no longer a direct mapping against a file name.
* wscript: bump libplacebo minimum versionNiklas Haas2021-10-041-1/+1
| | | | Switching to v3 allows us to drop the use of deprecated/removed members.
* build: lua 5.1/5.2: use generic version namesAvi Halachmi (:avih)2021-10-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TL;DR: use --lua=XXX for pkg-config name XXX, e.g. --lua=lua-5.1 . For unversioned 'lua.pc', use the name luadef51/luadef52 . Autodetection remains the same (5.2 names, luajit, 5.1 names). The old names are still supported, but not auto-detected. Before this patch, if one wanted to choose a specific lua version when more than one is installed, then the names were a mess, e.g. 51obsd is also the name detected on Arch linux, and other (distro) names are also not unique to a specific distro/platform. So to ask mpv to choose the package name (specifically, the pkg-config file name), one needs to look at the mpv sources and find the (arbitrary) distro name which has the same lua version naming as they do on their own system, e.g. --lua=51obsd on Arch. This is a pain. Now we add generic names: - luadef51/luadef52 - generic pkg-config lua.pc (version is inside). - lua* - exactly the pkg-config name, e.g. --lua=lua-51 for lua-51.pc (the names are curated, e.g. --lua=foo won't detect foo.pc). - The legacy names (e.g. 51deb) are still supported, but undocumented, and the new generic names take precedence during auto-detection. The fact that the generic names all start with "lua" has an additional benefit that it shows right after "lua" at the output of mpv -v, while the old names start with numbers, so they're first at the list, making it hard to understand that e.g. "51obsd" is the lua version. None of these names are actually used at the mpv code. The C code checks the version using the lua headers (LUA_VERSION_NUM).