summaryrefslogtreecommitdiffstats
path: root/wscript
Commit message (Collapse)AuthorAgeFilesLines
* 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
* video: change some remaining vo_opengl mentions to vo_gpuAkemi2018-01-201-1/+1
|
* build: rpi: add missing linker flags to fix buildIlya Tumaykin2018-01-101-1/+1
| | | | | | | | See https://www.raspberrypi.org/forums/viewtopic.php?f=67&t=20005&p=194090 and https://github.com/raspberrypi/firmware/issues/110 Raspberry-pi upstream also adds '-lGLESv2' when EGL is used: https://github.com/raspberrypi/userland/blob/master/pkgconfig/egl.pc.in
* build: generate version.h before anything elseStefano Pigozzi2018-01-011-0/+5
| | | | | | This seems to fix issues when building on windows where compiling mpv.rc after a `waf clean` resulted in a failure because version.h was not always present
* wscript: remove redundant libraries check for shaderc-staticshinchiro2017-12-241-2/+1
| | | | | | | libshaderc_combined.a already bundles every libs it depends on References: https://github.com/google/shaderc/tree/master/libshaderc#build-artifacts
* wscript: support static linking of shadercMartin Herkt2017-12-241-1/+16
| | | | | These idiots have no idea how to design a library, so we’ll have to work around their bullshit for now.
* build: use a list instead of a string for rpi cflagsScott Zeid2017-12-211-4/+4
| | | | Using a string caused all 4 flags to be passed as one argument, causing the build to fail when trying to include bcm_host.h.
* Restore Libav supportwm42017-12-211-1/+1
| | | | | | | | | | | Libav has been broken due to the hwdec changes. This was always a temporary situation (depended on pending patches to be merged), although it took a bit longer. This also restores the travis config. One code change is needed in vd_lavc.c, because it checks the AV_PIX_FMT for videotoolbox (as opposed to the mpv format identifier), which is not available in Libav. Add an ifdef; the affected code is for a deprecated option anyway.
* vo_mediacodec_embed: implement hwcontextAman Gupta2017-12-201-1/+1
| | | | Fixes vo_mediacodec_embed, which was broken in 80359c6615658f2784
* vd_lavc: use libavcodec metadata for hardware decoder wrapperswm42017-12-151-1/+1
| | | | | This removes the need to keep an explicit list and to attempt to parse codec names. Needs latest FFmpeg git.
* Remove support for ffmpeg-mpvRostislav Pehlivanov2017-12-051-13/+4
|
* build: remove nanosleep() checkwm42017-12-021-4/+0
| | | | Also guaranteed by POSIX.
* build: remove termios checkwm42017-12-021-4/+0
| | | | Also should be fully covered by POSIX.
* build: remove POSIX/sysv shared memory testwm42017-12-021-5/+0
| | | | | | vo_x11 and vo_xv need this. According to the Linux manpage, all involved functions are POSIX-2001 anyway. (I just assumed they were not, because they're mostly System V UNIX legacy garbage.)
* build: bump required ffmpeg versionwm42017-11-301-1/+1
| | | | For the vp9 fix (at least if upstream ffmpeg is used).
* build: accept ffmpeg git by defaultwm42017-11-291-1/+0
| | | | VP9 is still broken due to a difference with Libav, though.
* ao_alsa: change license to LGPLwm42017-11-231-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | Looks like this is covered by LGPL relicensing agreements now. Notes about contributors who could not be reached or who didn't agree: Commit 7fccb6486e has tons of mp_msg changes look like they are not copyrightable (even if they were, all mp_msg calls were rewritten in mpv times again). The additional play() change looks suspicious, but the function was rewritten several times anyway (first time after that commit in 4f40ec312). Commit 89ed1748ae was rewritten in commit 325311af3 and then again several times after that. Basically all this code is unnecessary in modern mpv and has been removed. No code survived from the following commits: 4d31c3c53, 61ecf838f2, d38968bd, 4deb67c3f. At least two cosmetic typo fixes are not considered as well. Commit 22bb046ad is reverted (this wasn't a valid warning anyway, just a C++-ism icc applied to C). Using the constants is nicer, but at least I don't have to decide whether that change was copyrightable.
* demux_mkv: remove unnecessary parsing for vp9wm42017-11-171-1/+1
| | | | | | | We can finally get rid of this crap. Depends on a ffmpeg-mpv change. Always worked with Libav (ever since they fixed it properly).
* build: enable libarchive by defaultwm42017-11-121-1/+0
| | | | Or libcve, as the vlc developers call it.
* vo_gpu: d3d11: enhance cache invalidationJames Ross-Gowan2017-11-071-1/+1
| | | | | | | | The shader cache in ra_d3d11 caches the result of shaderc, crossc and the D3DCompiler DLL, so it should be invalidated when any of those components are updated. This should make the cache more reliable, which makes it safer to enable gpu-shader-cache-dir. Shader compilation is slow with D3D11, so gpu-shader-cache-dir is highly necessary
* vo_gpu: d3d11: initial implementationJames Ross-Gowan2017-11-071-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |