summaryrefslogtreecommitdiffstats
path: root/wscript
Commit message (Collapse)AuthorAgeFilesLines
* build: lower version requirement for EGLMarvin Schmidt2019-09-291-1/+1
| | | | | | | | `egl.pc` can be provided either by mesa or libglvnd. The latter doesn't follow the same version scheme as mesa but instead uses the API version that the library exposes, which is 1.5 for EGL[1] [1] https://github.com/NVIDIA/libglvnd/commit/0dfaea2bcb7cdcc785f95e244223bd004a2d7fba#diff-b58a140c00ea99fb9a708e15afaade62R8
* build: silence OpenGL deprecation warnings on macOS for C/objCRodger Combs2019-09-281-1/+2
| | | | | We know of the deprecation since 10.14, and thus we do not need to be reminded of it with each compiled file.
* wscript: check tvOS define's value to be nonzeroJan Ekström2019-09-271-1/+4
| | | | | | TARGET_OS_TV seems to always be defined, but set according to the build configuration. This fixes all Apple configurations being mis-identified as tvOS.
* zsh completion: move generation to runtime and improvePhilip Sequeira2019-09-271-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The completion function itself now parses --list-options on the first tab press and caches the results. This does mean a slight delay on that first tab press, but it will only do this if the argument being completed looks like an option (i.e. starts with "-"), so there is never a delay when just completing a file name. I've also put some effort into making it reasonably fast; on my machine it's consistently under 100 ms, more than half of which is mpv itself. Installation of zsh completion is now done unconditionally because it's nothing more than copying a file. If you really don't want it installed, set zshdir to empty: `./waf configure --zshdir= ...` Improvements in functionality compared to the old script: * Produces the right results for mpv binaries other than the one it was installed with (like a dev build for testing changes). * Does not require running mpv at build time, so it won't cause problems with cross compilation. * Handles aliases. * Slightly nicer handling of options that take comma-separated values and/or sub-options: A space is now inserted at the end instead of a comma, allowing you to immediately start typing the next argument, but typing a comma will still remove the automatically added space, and = and : will now do that too, so you can immediately add a sub-option. * More general/flexible handling of values for options that print their possible values with --option=help. The code as is could handle quite a few more options (*scale, demuxers, decoders, ...), but nobody wants to maintain that list here so we'll just stick with what the old completion script already did.
* vo_gpu: hwdec_drmprime_drm: add hwdec ctxJonas Karlman2019-09-271-1/+1
| | | | | | | This allows to use drm hwaccels that require a hwdevice. Tested with v4l2request hwaccel and cedrus driver on an allwinner device running mpv with --vo=gpu --gpu-context=drm --hwdec=drm.
* wscript: detect tvOS and disable posix-spawn usageAman Gupta2019-09-261-1/+5
| | | | | | cc #5331 Signed-off-by: Aman Gupta <aman@tmm1.net>
* wscript: Fix test for ffmpeg drmprime supportPhilip Langdale2019-09-221-2/+9
| | | | | | | This test requires libavutil headers but there is no avutil dependency for it to use. So let's add one, and also reorder the ffmpeg tests ahead of the video tests so that the avutil dependency can be used.
* test: fix cmocka assert_float_equal shadowing warningswm42019-09-211-1/+1
| | | | | | | | | Just use cmocka's function. It takes an epsilon argument, which we now provide directly. There's no assert_double_equal() in cmocka (and the float variant actually forces a conversion to the float type), but fortunately we didn't use it.
* waf: fix wayland-scanner deprecation warningdudemanguy2019-09-211-2/+2
| | | | | | Use `private-code` instead of `code` here. Also this bumps up the required wayland-client/wayland-cursor version to 1.15 which is still pretty old anyway.
* rpi: Update for modern systemsCameron Cawley2019-09-201-17/+6
|
* vf_fingerprint: use aligned_alloc instead of posix_memalignwm42019-09-191-0/+6
| | | | | | | | | | | I was assuming posix_memalign was the most portable function to use, but MinGW does not provide it for some reason. Switch to C11 aligned_alloc() which someone suggested was provided by MinGW (but actually isn't, someone probably confused it with the incompatible _aligned_malloc), and add a configure check. Even though it turned out that MinGW doesn't provide it, the function is slightly more elegant than posix_memalign(), so stay with it.
* video: add vf_fingerprint and a skip-logo scriptwm42019-09-191-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | skip-logo.lua is just what I wanted to have. Explanations are on the top of that file. As usual, all documentation threatens to remove this stuff all the time, since this stuff is just for me, and unlike a normal user I can afford the luxuary of hacking the shit directly into the player. vf_fingerprint is needed to support this script. It needs to scale down video frames as part of its operation. For that, it uses zimg. zimg is much faster than libswscale and generates more correct output. (The filter includes a runtime fallback, but it doesn't even work because libswscale fucks up and can't do YUV->Gray with range adjustment.) Note on the algorithm: seems almost too simple, but was suggested to me. It seems to be pretty effective, although long time experience with false positives is missing. At first I wanted to use dHash [1][2], which is also pretty simple and effective, but might actually be worse than the implemented mechanism. dHash has the advantage that the fingerprint is smaller. But exact matching is too unreliable, and you'd still need to determine the number of different bits for fuzzier comparison. So there wasn't really a reason to use it. [1] https://pypi.org/project/dhash/ [2] http://www.hackerfactor.com/blog/index.php?/archives/529-Kind-of-Like-That.html
* build: better POSIX checkwm42019-09-191-3/+1
| | | | This is the "official" method to do this.
* vf_vapourynth: remove Lua backendwm42019-09-191-11/+1
| | | | | | | | | | | | | | | I once created this because someone wanted to use vapoursynth without the Python dependency. No idea if anyone ever actually used it. It's sort of icky (it calls itself "lazy" to preempt complaints about how much it sucks), and complicates the build process. Kill it. It seems much more promising to have something like this: https://github.com/vapoursynth/vapoursynth/issues/386 This would either solve the build distribution problem by relaxing the Python dependency, and/or allow a Lua backend to be included without pain.
* vo_gpu: remove mali-fbdevwm42019-09-191-11/+2
| | | | | Useless at this point, I don't even know if it still works, or how to test it.
* vo_gpu: hwdec_vaapi: Refactor Vulkan and OpenGL interops for VAAPIPhilip Langdale2019-09-151-6/+1
| | | | | | Like hwdec_cuda, you get a big #ifdef mess if you try and keep the OpenGL and Vulkan interops in the same file. So, I've refactored them into separate files in a similar way.
* Remove classic Linux analog TV support, and DVB runtime controlswm42019-09-131-43/+6
| | | | | | | | | | | | | | | | | | | | | | | | Linux analog TV support (via tv://) was excessively complex, and whenever I attempted to use it (cameras or loopback devices), it didn't work well, or would have required some major work to update it. It's very much stuck in the analog past (my favorite are the frequency tables in frequencies.c for analog TV channels which don't exist anymore). Especially cameras and such work fine with libavdevice and better than tv://, for example: mpv av://v4l2:/dev/video0 (adding --profile=low-latency --untimed even makes it mostly realtime) Adding a new input layer that targets such "modern" uses would be acceptable, if anyone is interested in it. The old TV code is just too focused on actual analog TV. DVB is rather obscure, but has an active maintainer, so don't remove it. However, the demux/stream ctrl layer must go, so remove controls for channel switching. Most of these could be reimplemented by using the normal method for option runtime changes.
* Remove libdvdread support in favor of libdvdnavwm42019-09-131-11/+0
| | | | | | | | | | | stream_dvd.c contained large amounts of ancient, unmaintained code, which has been historically moved to libdvdnav. Basically, it's full of low level parsing of DVD on-disc structures. Kill it for good. Users can use the remaining dvdnav support (which basically operates in non-menu mode). Users have reported that libdvdread sometimes works better, but this is just libdvdnav's problem and not ours.
* cocoa-cb: migrate to swift 5 with swift 4 fallbackder richter2019-07-211-2/+3
| | | | | | | | | | | | | this migrates our current swift code to version 5 and 4. building is support from 10.12.6 and xcode 9.1 onwards. dynamic linking is the new default, since Apple removed static libs from their new toolchains and it's the recommended way. additionally the found macOS SDK version is printed since it's an important information for finding possible errors now. Fixes #6470
* cocoa-cb: conditional compilation for Dark Mode and Material featuresder richter2019-07-211-1/+11
| | | | Fixes #6621
* build: add Swift dynamic linking supportder richter2019-07-211-0/+5
| | | | | | | | | | | | | | | this is in preparation for the upcoming swift 5 transition, where static linking was replaced by dynamic linking the swift libraries as the preferred way, by Apple. furthermore Apple removed the static swift libs from their dev Tools starting with xcode 10.2/swift 5. because of ABI incompatibility dynamic linking for swift versions prior to 5 doesn't use the system lib path for the dynamic swift libs. for now static linking is still the default, but that will be changed when swift 5 support is added and swift 3 support is dropped. Fixes #6232
* vo_gpu: hwdec_vaapi: Add Vulkan interopPhilip Langdale2019-07-081-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | This change introduces a vulkan interop path for the vaapi hwdec. The basic principles are mostly the same as for EGL, with the exported dma_buf being imported by Vukan. The biggest difference is that we cannot reuse the texture as we do with OpenGL - there's no way to rebind a VkImage to a different piece of memory, as far as I can see. So, a new texture is created on each map call. I did not bother implementing a code path for the old libva API as I think it's safe to assume any system with a working vulkan driver will have access to a newer libva. Note that we are using separate layers for the vaapi surface, just as is done for EGL. This is because libplacebo doesn't support multiplane images. This change does not include format negotiation because no driver implements the vk_ext_image_drm_format_modifier extension that would be required to do that. In practice, the two formats we care about (nv12, p010) work correctly, so we are not blocked. A separate change had to be made in libplacebo to filter out non-fatal validation errors related to surface sizes due to the lack of format negotiation.
* vo/gpu: hwdec_vdpau: Support direct mode for 4:4:4 contentPhilip Langdale2019-07-081-1/+1
| | | | | | | New releases of VDPAU support decoding 4:4:4 content, and that comes back as NV24 when using 'direct mode' in OpenGL Interop. That means we need to be a little bit smarter about how we set up the OpenGL textures.
* build: Add support for static spirv-crossMartin Herkt2019-06-141-1/+14
| | | | | This assumes a non-upstream .pc file since upstream doesn’t seem to give a fuck about this use case at all.
* vo_gpu: d3d11: use the SPIRV-Cross C API directlyJames Ross-Gowan2019-06-121-4/+4
| | | | | | | | | | When the D3D11 backend was first written, SPIRV-Cross only had a C++ API and no guarantee of API or ABI stability, so instead of using SPIRV-Cross directly, mpv used an unofficial C wrapper called crossc. Now that KhronosGroup/SPIRV-Cross#611 is resolved, SPIRV-Cross has an official C API that can be used instead, so remove crossc and use SPIRV-Cross directly.
* vo_gpu: hwdec_cuda: Implement interop for placeboPhilip Langdale2019-04-211-1/+1
| | | | | | | | | | | | | | | | | | | | This change updates the vulkan interop code to work with the libplacebo based ra_vk, but also introduces direct VkImage sharing to avoid the use of the intermediate buffer. It is also necessary and desirable to introduce explicit semaphore bsed synchronisation for operations on the shared images. Synchronisation means we can safely reuse the same VkImage for every mapped frame, by ensuring the frame is copied to the VkImage before mapping the next frame. This functionality requires a 417.xx or newer nvidia driver, due to bugs in the VkImage interop in the earlier 411 and 415 drivers. It's definitely worth the effort, as the raw throughput is about twice that of implementation using an intermediate buffer.
* vo_gpu: vulkan: use libplacebo insteadNiklas Haas2019-04-211-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | This commit rips out the entire mpv vulkan implementation in favor of exposing lightweight wrappers on top of libplacebo instead, which provides much of the same except in a more up-to-date and polished form. This (finally) unifies the code base between mpv and libplacebo, which is something I've been hoping to do for a long time. Note: The ra_pl wrappers are abstract enough from the actual libplacebo device type that we can in theory re-use them for other devices like d3d11 or even opengl in the future, so I moved them to a separate directory for the time being. However, the rest of the code is still vulkan-specific, so I've kept the "vulkan" naming and file paths, rather than introducing a new `--gpu-api` type. (Which would have been ended up with significantly more code duplicaiton) Plus, the code and functionality is similar enough that for most users this should just be a straight-up drop-in replacement. Note: This commit excludes some changes; specifically, the updates to context_win and hwdec_cuda are deferred to separate commits for authorship reasons.
* spirv: remove --spirv-compiler=nvidiaNiklas Haas2018-12-011-1/+2
| | | | | | | | | | | | This option has been deprecated upstream for a long time, probably doesn't even work anymore, and won't work moving forwards as we replace the vulkan code by libplacebo wrappers. I haven't removed the option completely yet since in theory we could still add support for e.g. a native glslang wrapper in the future. But most likely the future of this code is deletion. As an aside, fix an issue where the man page didn't mention d3d11.
* build: add a version requirement for vulkan pkg-config checkJan Ekström2018-11-041-1/+2
| | | | | | | | | | | `vkGetPhysicalDeviceProperties2KHR` was added in Vulkan 1.0.39, but 1.0.61 from Ubuntu Xenial (16.04) was the lowest anyone tried to build mpv with as of late, so we are marking that as the minimum required version. This fixes issues arising during build time from having too old version of vulkan available on a system, instead of causing a failure to build.
* build: use an argument list for the Swift build argsAkemi2018-10-281-1/+2
| | | | | | that way we don't need to quote or escape anything. Fixes #6220
* vo_gpu: vulkan: hwdec_cuda: Add support for Vulkan interopPhilip Langdale2018-10-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Despite their place in the tree, hwdecs can be loaded and used just fine by the vulkan GPU backend. In this change we add Vulkan interop support to the cuda/nvdec hwdec. The overall process is mostly straight forward, so the main observation here is that I had to implement it using an intermediate Vulkan buffer because the direct VkImage usage is blocked by a bug in the nvidia driver. When that gets fixed, I will revist this. Nevertheless, the intermediate buffer copy is very cheap as it's all device memory from start to finish. Overall CPU utilisiation is pretty much the same as with the OpenGL GPU backend. Note that we cannot use a single intermediate buffer - rather there is a pool of them. This is done because the cuda memcpys are not explicitly synchronised with the texture uploads. In the basic case, this doesn't matter because the hwdec is not asked to map and copy the next frame until after the previous one is rendered. In the interpolation case, we need extra future frames available immediately, so we'll be asked to map/copy those frames and vulkan will be asked to render them. So far, harmless right? No. All the vulkan rendering, including the upload steps, are batched together and end up running very asynchronously from the CUDA copies. The end result is that all the copies happen one after another, and only then do the uploads happen, which means all textures are uploaded the same, final, frame data. Whoops. Unsurprisingly this results in the jerky motion because every 3/4 frames are identical. The buffer pool ensures that we do not overwrite a buffer that is still waiting to be uploaded. The ra_buf_pool implementation automatically checks if existing buffers are available for use and only creates a new one if it really has to. It's hard to say for sure what the maximum number of buffers might be but we believe it won't be so large as to make this strategy unusable. The highest I've seen is 12 when using interpolation with tscale=bicubic. A future optimisation here is to synchronise the CUDA copies with respect to the vulkan uploads. This can be done with shared semaphores that would ensure the copy of the second frames only happens after the upload of the first frame, and so on. This isn't trivial to implement as I'd have to first adjust the hwdec code to use asynchronous cuda; without that, there's no way to use the semaphore for synchronisation. This should result in fewer intermediate buffers being required.
* add swift as main dependency so all dependencies can be disabled easilyAkemi2018-09-301-2/+7
|
* build: check for Swift version and disable dependencies if neededAkemi2018-09-301-1/+1
|
* Revert "ao_openal: enable building on OSX"Michael Hoang2018-08-261-1/+1
| | | | | | This reverts commit af6126adbe61fb2b6cc780025246d33df93072e6. Apple's OpenAL support is ridiculously out of date, revert back to just using OpenAL Soft on macOS (fixes #4645).
* wscript: split egl-android from androidTom Yan2018-08-201-6/+8
|
* build: if libdir is not set, set it to EXEC_PREFIX/libJan Ekström2018-07-191-0/+13
| | | | | This way the behavior of default libdir stays consistent before and after switching to gnu_dirs from waf itself.
* build: utilize built-in gnu_dirs module for installation directoriesAkemi2018-07-121-13/+20
| | | | | | | | | | | | | | | | | | | | | | This started breaking with newer (2.0.x) waf versions, and it was noticed that a built-in waf module was providing very similar functionality. APPNAME definition was required to have `gnu_dirs`' PACKAGE variable to be defined in order to have f.ex. documentation installed to the correct directory. Currently unused options added by `gnu_dirs` were removed to clean up the output of the help command. Effective changes to behavior: - `gnu_dirs` will attempt to figure out if it needs to use lib64 instead of lib within your installation prefix. If you would like it to not do that, set `--libdir` during configuration. The way it tries to figure lib/lib64 out is if there's a `/usr/lib64` and no `/usr/lib32`. - `--incdir` is now `--includedir` as per standard `gnu_dirs` behavior.
* wscript: Remove code check for cuda hwaccelPhilip Langdale2018-05-101-2/+1
| | | | | | This was there originally to detect too-old versions of ffmpeg. We now only support >= 4.0, so it's not relevant. We just need the dependencies to be present.
* build: make encoding mode non-optionalwm42018-05-031-4/+0
| | | | Makes it easier to not break the build by confusing the ifdeffery.
* vo_gpu: hwdec: Use ffnvcodec to load CUDA symbolsPhilip Langdale2018-04-151-1/+5
| | | | | | The CUDA dynamic loader was broken out of ffmpeg into its own repo and package. This gives us an opportunity to re-use it in mpv and remove our custom loader logic.
* f_lavfi: use new libavfilter iteration APIwm42018-04-031-1/+1
|
* video: remove libavutil PSEUDOPAL stuffwm42018-04-031-1/+1
| | | | Not needed anymore with newest libavutil.
* lavc_conv: do not allow libavcodec to drop subtitles with broken UTF-8wm42018-03-261-1/+1
| | | | | | | libavcodec normally drops subtitle lines that fail a check for invalid UTF-8 (their check is slightly broken too, by the way). This was always annoying and inconvenient, but now there is a mechanism to prevent it from doing this. Requires newst libavcodec.
* mp_image: replace rude function with less rude FFmpeg upstream functionwm42018-03-031-1/+1
| | | | This is new, thus a dependency bump is required.
* Fix recent FFmpeg deprecationswm42018-02-131-3/+3
| | | | | | | | | This includes codec/muxer/demuxer iteration (different iteration function, registration functions deprecated), and the renaming of AVFormatContext.filename to url (plus making it a malloced string). Libav doesn't have the new API yet, so it will break. I hope they will add the new APIs too.
* build: drop support for SDL1wm42018-02-131-6/+0
| | | | | For some reason it was supported for ao_sdl because we've only used SDL1 API.
* cocoa-cb: initial implementation via opengl-cb APIAkemi2018-02-121-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739, #2392, #2217
* hwdec: detach d3d and d3d9 hwaccel from anglemyfreeer2018-01-251-5/+4
| | | | Fix https://github.com/mpv-player/mpv/issues/5420
*