summaryrefslogtreecommitdiffstats
path: root/wscript_build.py
Commit message (Collapse)AuthorAgeFilesLines
* waf: remove waf as a build systemLaserEyess2023-07-231-826/+0
| | | | | | Remove waf entirely in favor of meson as the only supported build system. Waf was officially deprecated in 0.36.0, and has not been preferred over meson since 0.35.0.
* wscript: add 1.32 protocols to sourcesAdam Sampson2023-07-111-0/+2
| | | | | The patch that added these protocols didn't include them in the list of sources, which caused build failure with wayland-protocols 1.32.
* wayland: add cursor-shape-v1 supportDudemanguy2023-07-091-0/+14
| | | | | | 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.
* osdep: add mp_get_user_langsrcombs2023-06-251-0/+8
|
* osdep: move cfstr<->cstr conversions to a new apple_utils.c filercombs2023-06-251-0/+1
|
* misc: add language-matching utilitiesrcombs2023-06-251-0/+1
|
* hwdec_vulkan: add Vulkan HW InteropPhilip Langdale2023-05-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+2
| | | | | | | | | | | 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.
* player: remove unittest optionDudemanguy2023-03-021-13/+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.
* Vulkan: add configure check for VK_KHR_display extensionrcombs2023-02-201-1/+1
| | | | This allows building directly against ICDs that don't implement this extension.
* wayland: add wp-fractional-scale-v1 supportDudemanguy2023-01-241-0/+10
| | | | | | | | | | | | | 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.
* vo_kitty: Introduce modern sixel alternativeMia Herkt2022-12-211-0/+1
| | | | | | | | | | | | | See https://sw.kovidgoyal.net/kitty/graphics-protocol/ This makes no attempt at querying terminal features or handling terminal errors, as it would require mpv to pass the response codes from the terminal to the vo instead of interpreting them as keystrokes made by the user and acting very unpredictably. Tested with kitty and konsole. Fixes #9605
* vo_dmabuf_wayland: use single-pixel-buffer-v1LaserEyess2022-11-201-0/+7
| | | | | | | The new single-pixel-buffer protocol is designed to optimize the case for using a solid color as an underlay wl_surface. It works the same as the wl_shm 1x1 pixel trick currently used, but it allows the compositor to make optimizations with more certainty than the wl_shm trick.
* wayland: add support for content-type protocolDudemanguy2022-11-151-0/+9
| | | | | | | | | | | | | | | | | | | | 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.
* vo_vaapi_wayland: remove, as it is superceded by vo_dmabuf_waylandAaron Boxer2022-10-261-1/+0
|
* vo_dmabuf_wayland: wayland VO displaying dmabuf buffersAaron Boxer2022-10-261-0/+5
| | | | | | | | | | | | | 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
* vo_gpu/hwdec: rename and introduce legacy names for some interopsPhilip Langdale2022-10-111-1/+1
| | | | | | | | | | | | We've had some annoying names for interops, which we can't simply rename because that would break config files and command lines. So we need to put a little more effort in and add a concept of legacy names that allow us to continue loading them, but with a warning. The two I'm renaming here are: * vaapi-egl -> vaapi (vaapi works with Vulkan too) * drmprime-drm -> drmprime-overlay (actually describes what it does) * cuda-nvdec -> cuda (cuda interop is not nvdec specific)
* vo_gpu: hwdec: add Android hwdec utilizing AImageReadersfan52022-10-021-0/+1
|
* mpv.metainfo.xml: add XDG appstream metadata manifestVitaly Zaitsev2022-09-091-0/+4
|
* misc/random: add xoshiro random number implementationLeo Izen2022-08-171-0/+1
| | | | | | | Add xoshiro as a PRNG implementation instead of relying on srand() and rand() from the C standard library. This, in particular, lets us avoid platform-defined behavior with respect to threading.
* hwdec/drmprime: add drmprime hwdec-interopPhilip Langdale2022-08-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the confusing landscape of hardware video decoding APIs, we have had a long standing support gap for the v4l2 based APIs implemented for the various SoCs from Rockship, Amlogic, Allwinner, etc. While VAAPI is the defacto default for desktop GPUs, the developers who work on these SoCs (who are not the vendors!) have preferred to implement kernel APIs rather than maintain a userspace driver as VAAPI would require. While there are two v4l2 APIs (m2m and requests), and multiple forks of ffmpeg where support for those APIs languishes without reaching upstream, we can at least say that these APIs export frames as DRMPrime dmabufs, and that they use the ffmpeg drm hwcontext. With those two constants, it is possible for us to write a hwdec-interop without worrying about the mess underneath - for the most part. Accordingly, this change implements a hwdec-interop for any decoder that produces frames as DRMPrime dmabufs. The bulk of the heavy lifting is done by the dmabuf interop code we already had from supporting vaapi, and which I refactored for reusability in a previous set of changes. When we combine that with the fact that we can't probe for supported formats, the new code in this change is pretty simple. This change also includes the hwcontext_fns that are required for us to be able to configure the hwcontext used by `hwdec=drm-copy`. This is technically unrelated, but it seemed a good time to fill this gap. From a testing perspective, I have directly tested on a RockPRO64, while others have tested with different flavours of Rockchip and on Amlogic, providing m2m coverage. I have some other SoCs that I need to spin up to test with, but I don't expect big surprises, and when we inevitably need to account for new special cases down the line, we can do so - we won't be able to support every possible configuration blindly.
* hwdec/dmabuf_interop: use AVDRMFrameDescriptor to describe dmabufsPhilip Langdale2022-08-031-2/+2
| | | | | | | | | | | | 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.
* hwdec/vaapi: rename interops to reflect more general usePhilip Langdale2022-08-031-2/+2
| | | | | | | | | | | This is the first in a series of changes that will introduce a drmprime hwdec. As our vaapi hwdec is based around exporting surfaces as drmprime dmabufs, we've actually got a lot of useful code already in place in the GL/PL interops. I'm going to reorganise and adjust this code to make the interops usable with the new hwdec as well. The first step is to rename the files and functions. There are no functional or other changes here. They will come next.
* x11: support xorg present extensionDudemanguy2022-06-191-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* vo: move wayland presentation to separate filesDudemanguy2022-06-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Wayland had some specific code that it used for implementing the presentation time protocol. It turns out that xorg's present extension is extremely similar, so it would be silly to duplicate this whole mess again. Factor this out to separate, independent code and introduce the mp_present struct which is used for handling the ust/msc values and some other associated values. Also, add in some helper functions so all the dirty details live specifically in present_sync. The only wayland-specific part is actually obtaining ust/msc values. Since only wayland or xorg are expected to use this, add a conditional to the build that only adds this file when either one of those are present. You may observe that sbc is completely omitted. This field existed in wayland, but was completely unused (presentation time doesn't return this). Xorg's present extension also doesn't use this so just get rid of it all together. The actual calculation is slightly altered so it is correct for our purposes. We want to get the presentation event of the last frame that was just occured (this function executes right after the buffer swap). The adjustment is to just remove the vsync_duration subtraction. Also, The overly-complicated queue approach is removed. This has no actual use in practice (on wayland or xorg). Presentation statistics are only ever used after the immediate preceding swap to update vsync timings or thrown away.
* audio: add AVChannelLayout helpers to convert from/to mp_chmapJan Ekström2022-06-121-0/+1
| | | | | | | | | 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: add new vaapi-wayland driverAaron Boxer2022-05-241-0/+15
| | | | | | | 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.
* hwdec_vaapi_vk: rename to vaapi_plNiklas Haas2022-03-031-2/+2
| | | | | | | | 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.
* build: rename libplacebo version checkNiklas Haas2022-02-031-2/+2
| | | | | Rename from "libplacebo-v4" to "libplacebo-next" to more closely capture the intent, since this will become libplacebo v5 eventually (tm).
* ao_sndio: add this audio output againrim2022-01-221-0/+1
| | | | | | | | | 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/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* libmpv: remove opengl_cb API and other deprecated symbolssfan52021-12-151-1/+1
| | | | | | 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.
* vo_gpu_next: factor out context-specific code to gpu_next/context.csfan52021-11-221-0/+1
| | | | | | 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.
* demux_edl: rename ebml_defs.c to ebml_defs.incDudemanguy2021-11-141-1/+1
| | | | | | | | | | | The extension is completely arbitrary since ebml_defs.c isn't a real c file that actually is compiled at any point in time. It's just used as an include. The reason for changing the extension is because meson needs to add this to its list of sources for dependency/ordering purposes. Understandably, meson will try to compile any .c file added to a c project executable object. Obviously, this compilation will never succeed, and this shouldn't be compiled anyways. Just make it .inc instead.
* vo_gpu_next: add new libplacebo-based rendererNiklas Haas2021-11-031-0/+1
| | | | | | | | | | | | | 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.
* sub: new: --sub-filter-jsre (js regex)Avi Halachmi (:avih)2021-08-051-0/+1
| | | | | | | | | | | | Pretty much identical to filter-regex but with JS expressions and requires only JS support. Shares the filter-regex-* control options. The target audience is Windows users - where filter-regex doesn't work due to missing APIs, but mujs builds cleanly on Windows, and JS is usually enabled in 3rd party Windows mpv builds. Lua could have been used with similar effort, however, the JS regex syntax is more extensive and also much more similar to POSIX.
* vo_gpu: vulkan: implement a VkDisplayKHR backed contextPhilip Langdale2021-06-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | This is the Vulkan equivalent of the drm context for OpenGL, with the big difference that it's implemented purely in terms of Vulkan calls and doesn't actually require drm or kms. The basic idea is to identify a display, mode, and plane on a device, and then create a display backed surface for the swapchain. In theory, past that point, everything is the same, and this is in fact the case on Intel hardware. I can get a video playing on a vt. On nvidia, naturally, things don't work that way. Instead, nvidia only implemented the extension for scenarios where a VR application is stealing a display from a running window system, and not for standalone scenarios. With additional code, I've got this scenario to work but that's a separate incremental change. Other people have tested on AMD, and report roughly the same behaviour as on Intel. Note, that in this change, the VT will not be correctly restored after qutting. The only way to restore the VT is to introduce some drm specific code which I will illustrate in a separate change.
* ao_oss: add this audio output againrim2021-03-151-0/+1
| | | | | | | | | | | Changes: - code refactored; - mixer options removed; - new mpv sound API used; - add sound devices detect (mpv --audio-device=help will show all available devices); - only OSSv4 supported now; Tested on FreeBSD 12.2 amd64.
* video/out/vo_sixel.c: Implement sixel as a output deviceShreesh Adiga2020-11-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Based on the implementation of ffmpeg's sixel backend output written by Hayaki Saito https://github.com/saitoha/FFmpeg-SIXEL/blob/sixel/libavdevice/sixel.c Sixel is a protocol to display graphics in a terminal. This commit adds support to play videos on a sixel enabled terminal using libsixel. With --vo=sixel, the output will be in sixel format. The input frame will be scaled to the user specified resolution (--vo-sixel-width and --vo-sixel-height) using swscaler and then encoded using libsixel and output to the terminal. This method requires high cpu and there are high frame drops for 720p and higher resolution videos and might require using lesser colors and have drop in quality. Docs have all the supported options listed to fine tune the output quality. TODO: A few parameters of libsixel such as the sixel_encode_policy and the SIXEL_XTERM16 variables are hardcoded, might want to expose them as command line options. Also the initialization resolution is not automatic and if the user doesn't specify the dimensions, it picks 320x240 as the default resolution which is not optimal. So need to automatically pick the best fit resolution for the current open terminal window size.
* wscript_build.py: use -Wl,--subsystem,console insteadChristopher Degawa2020-10-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes an issue with clang not using the -mconsole option if mwindows is present resulting in mpv.com being a gui program instead of a console program. Does not interfere with gcc compilation. result without this patch ``` file .\mpv.com .\mpv.exe .\mpv.com: PE32+ executable (GUI) x86-64 (stripped to external PDB) .\mpv.exe: PE32+ executable (GUI) x86-64 (stripped to external PDB) ``` both executables open the mpv gui with out console output. result with this patch ``` file .\mpv.com .\mpv.exe .\mpv.com: PE32+ executable (console) x86-64 (stripped to external PDB) .\mpv.exe: PE32+ executable (GUI) x86-64 (stripped to external PDB) ``` mpv.com properly outputs text to console instead of instantly opening a gui `, for MS Windows` removed from the end of file outputs to reduce col count https://github.com/m-ab-s/media-autobuild_suite/issues/1794 Signed-off-by: Christopher Degawa <ccom@randomderp.com>
* Revert "demux: add a POS"wm42020-10-081-1/+0
| | | | | | This reverts commit 4f18e7927bacd2e887f8cca48a967804ce7adf86. It was a mistake, and barely anyone needs this.
* demux: add a POSwm42020-10-081-0/+1
| | | | | | I regret doing this so much, it's fucking garbage. Fixes: #