summaryrefslogtreecommitdiffstats
path: root/wscript
Commit message (Collapse)AuthorAgeFilesLines
* wayland: add cursor-shape-v1 supportDudemanguy2023-07-091-0/+5
| | | | | | This protocol no longer requires us to draw a separate cursor surface and all of that horrible stuff. We can just ask the compositor for the default cursor instead since that's literally all mpv cares about.
* wscript: bump required libplacebo-next version to 5.266Dudemanguy2023-07-021-2/+2
| | | | | Was forgotten in b73d96776cfee61f88bf60b27315baab32a2115d. Can't wait until we finally remove the waf build.
* video/image_writer: add avif screenshot supportcloud116652023-07-011-0/+4
| | | | | | | | | | 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
* wayland: bump wayland-protocols to 1.25Dudemanguy2023-06-161-5/+0
| | | | | 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-1/+6
| | | | | | | | | | | | | 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-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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: