summaryrefslogtreecommitdiffstats
path: root/wscript
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a new RA/vo_gpu backend that uses Direct3D 11. The GLSL generated by vo_gpu is cross-compiled to HLSL with SPIRV-Cross. What works: - All of mpv's internal shaders should work, including compute shaders. - Some external shaders have been tested and work, including RAVU and adaptive-sharpen. - Non-dumb mode works, even on very old hardware. Most features work at feature level 9_3 and all features work at feature level 10_0. Some features also work at feature level 9_1 and 9_2, but without high-bit- depth FBOs, it's not very useful. (Hardware this old is probably not fast enough for advanced features anyway.) Note: This is more compatible than ANGLE, which requires 9_3 to work at all (GLES 2.0,) and 10_1 for non-dumb-mode (GLES 3.0.) - Hardware decoding with D3D11VA, including decoding of 10-bit formats without truncation to 8-bit. What doesn't work / can be improved: - PBO upload and direct rendering does not work yet. Direct rendering requires persistent-mapped PBOs because the decoder needs to be able to read data from images that have already been decoded and uploaded. Unfortunately, it seems like persistent-mapped PBOs are fundamentally incompatible with D3D11, which requires all resources to use driver- managed memory and requires memory to be unmapped (and hence pointers to be invalidated) when a resource is used in a draw or copy operation. However it might be possible to use D3D11's limited multithreading capabilities to emulate some features of PBOs, like asynchronous texture uploading. - The blit() and clear() operations don't have equivalents in the D3D11 API that handle all cases, so in most cases, they have to be emulated with a shader. This is currently done inside ra_d3d11, but ideally it would be done in generic code, so it can take advantage of mpv's shader generation utilities. - SPIRV-Cross is used through a NIH C-compatible wrapper library, since it does not expose a C interface itself. The library is available here: https://github.com/rossy/crossc - The D3D11 context could be made to support more modern DXGI features in future. For example, it should be possible to add support for high-bit-depth and HDR output with DXGI 1.5/1.6.
* wscript: use pkg-config for vulkan checkMartin Herkt2017-11-031-1/+1
|
* build: fix cuda testwm42017-11-021-1/+1
|
* build: garbage => upstreamwm42017-11-011-2/+2
| | | | | "garbage" is considered offensive. The result will still be pretty bad though (currently build failures).
* build: make it easier to force FFmpeg upstreamwm42017-11-011-6/+7
| | | | | | | | | | | Apparently some people want this. Actually making it compile is still their problem, though, and I expect that build with FFmpeg upstream will occasionally be broken (as it is right now). This is because mpv also relies on API provided by Libav, and if FFmpeg hasn't merged that yet, it's not our problem - we provide a version of FFmpeg upstream with those changes merged, and it's called ffmpeg-mpv. Also adjust the README which still talked about FFmpeg releases.
* Bump libav* API usewm42017-10-301-90/+31
| | | | (Not tested on Windows and OSX.)
* build: require our own ffmpeg repowm42017-10-271-3/+11
| | | | | | | | | This is required now. Can't have FFmpeg upstream randomly break us and then not fix it (like this recent EOF issue). Upstream FFmpeg is of course still supported, but you will need to edit the build scripts. Official support is only with the master branch of our own repo.
* vd_lavc: use avcodec_fill_hw_frames_parameters() APIwm42017-10-271-0/+6
| | | | | | | | This removes the need for codec- and API-specific knowledge in the libavcodec hardware acceleration API user. For mpv, this removes the need for vd_lavc_hwdec.pixfmt_map and a few other things. (For now, we still keep the "old" parts for the sake of supporting older Libav, and FFgarbage.)
* Add DRM_PRIME Format Handling and Display for RockChip MPP decodersLionel CHAZALLON2017-10-231-0/+5
| | | | | | | | | | | This commit allows to use the AV_PIX_FMT_DRM_PRIME newly introduced format in ffmpeg that allows decoders to provide an AVDRMFrameDescriptor struct. That struct holds dmabuf fds and information allowing zerocopy rendering using KMS / DRM Atomic. This has been tested on RockChip ROCK64 device.
* build: make LGPL mode final (via --enable-gpl)wm42017-10-101-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rename --enable-preliminary-lgpl2 to --enable-gpl. This concludes the relicensing. Some things are still to do (relicensing some still-GPL optional code), but we consider the code included by --enable-gpl to be fully relicensed. The relicensing was performed by asking every known author for permission for relicensing it to LGPL version 2.1 "or later". If an author could not be contacted or permission could not be obtained, and the contribution was considered relevant for copyright purposes, the affected code was either excluded from LGPL mode (not built), or removed or rewritten. This is the standard in open source relicensing processes. Keep in mind that using LGPL mode is still on the user's own risk. Even though I claim that the relicensing was pretty clean and thorough (measured on the standards of the open source community¹), and I followed the advice of some actual experts, there is still a residual uncertainty due to the fact that I'm not an all-knowing entity (authors could have taken someone else's code and pretend it's their own) nor a lawyer (meaning I might lack associated authority or expertise), and the fact that the judicial system is far from deterministic. The relicensing was performed merely to the best of my knowledge. I reject all responsibility outside of that. This commit also cleans up the "Copyright" file to reflect the finalized relicensing process. ¹ Not to imply that the standards of commercial companies are much higher. Some major tech companies get away with stuff I would not consider clean. See #2033.
* vo_gpu: android: fix gpu contextAman Gupta2017-10-091-0/+1
|
* vo_gpu: add android opengl backendAman Gupta2017-10-091-2/+5
| | | | | | | | | | At the moment, rendering on Android requires ``--vo=opengl-cb`` and a lot of java<->c++ bridging code to receive the receive and react to the render callback in java. Performance also suffers with opengl-cb, due to the overhead of context switching in JNI. With this patch, Android can render using ``--vo=gpu --gpu-context=android`` (after setting ``--wid`` to point to an android.view.Surface on-screen).
* build: switch preliminary LGPL mode from v3 to v2.1wm42017-10-051-3/+3
| | | | | | | | | | | iive agreed to relicense things that are still in mpv to LGPLv2.1. So change the licenses of the affected files, and rename the configure switch for LGPL mode to --enable-preliminary-lgpl2. (The "preliminary" part will probably be removed from the configure switch soon as well.) Also player/main.c hasn't had GPL parts since a few commits ago.
* wayland_common: rewrite from scratchRostislav Pehlivanov2017-10-031-0/+9
| | | | | | | | | | | | The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
* vaapi: change license to LGPLwm42017-09-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | Originally mpv vaapi support was based on the MPlayer-vaapi patches. These were never merged in upstream MPlayer. The license headers indicated they were GPL-only. Although the actual author agreed to relicensing, the company employing him to write this code did not, so the original code is unusable to us. Fortunately, vaapi support was refactored and rewritten several times, meaning little code is actually left. The previous commits removed or moved that to GPL-only code. Namely, vo_vaapi.c remains GPL-only. The other code went away or became unnecessary mainly because libavcodec itself gained the ability to manage the hw decoder, and libavutil provides code to manage vaapi surfaces. We also changed to mainly using EGL interop, making any of the old rendering code unnecessary. hwdec_vaglx.c is still GPL. It's possibly relicensable, because much of it was changed, but I'm not too sure and further investigation would be required. Also, this has been disabled by default for a while now, so bothering with this is a waste of time. This commit simply disables it at compile time as well in LGPL mode.
* video: remove old videotoolbox supportwm42017-09-261-15/+1
| | | | | Like as in previous commits, you need a very recent FFmpeg (probably git master).
* wscript: remove redundant checkwm42017-09-261-6/+0
| | | | We're not using this function directly.
* video: drop old D3D11/DXVA2 supportwm42017-09-261-11/+1
| | | | | | | | | Now you need FFmpeg git, or something. This also gets rid of the last real use of gpu_memcpy(). libavutil does that itself. (vaapi.c still used it, but it was essentially unused, because the code path isn't really in use anymore. It wasn't even included due to the d3d-hwaccel dependency in wscript.)
* vo_gpu: vulkan: generalize SPIR-V compilerNiklas Haas2017-09-261-0/+4
| | | | | | | | | | | | | | In addition to the built-in nvidia compiler, we now also support a backend based on libshaderc. shaderc is sort of like glslang except it has a C API and is available as a dynamic library. The generated SPIR-V is now cached alongside the VkPipeline in the cached_program. We use a special cache header to ensure validity of this cache before passing it blindly to the vulkan implementation, since passing invalid SPIR-V can cause all sorts of nasty things. It's also designed to self-invalidate if the compiler gets better, by offering a catch-all `int compiler_version` that implementations can use as a cache invalidation marker.
* vo_gpu: vulkan: initial implementationNiklas Haas2017-09-261-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This time based on ra/vo_gpu. 2017 is the year of the vulkan desktop! Current problems / limitations / improvement opportunities: 1. The swapchain/flipping code violates the vulkan spec, by assuming that the presentation queue will be bounded (in cases where rendering is significantly faster than vsync). But apparently, there's simply no better way to do this right now, to the point where even the stupid cube.c examples from LunarG etc. do it wrong. (cf. https://github.com/KhronosGroup/Vulkan-Docs/issues/370) 2. The memory allocator could be improved. (This is a universal constant) 3. Could explore using push descriptors instead of descriptor sets, especially since we expect to switch descriptors semi-often for some passes (like interpolation). Probably won't make a difference, but the synchronization overhead might be a factor. Who knows. 4. Parallelism across frames / async transfer is not well-defined, we either need to use a better semaphore / command buffer strategy or a resource pooling layer to safely handle cross-frame parallelism. (That said, I gave resource pooling a try and was not happy with the result at all - so I'm still exploring the semaphore strategy) 5. We aggressively use pipeline barriers where events would offer a much more fine-grained synchronization mechanism. As a result of this, we might be suffering from GPU bubbles due to too-short dependencies on objects. (That said, I'm also exploring the use of semaphores as a an ordering tactic which would allow cross-frame time slicing in theory) Some minor changes to the vo_gpu and infrastructure, but nothing consequential. NOTE: For safety, all use of asynchronous commands / multiple command pools is currently disabled completely. There are some left-over relics of this in the code (e.g. the distinction between dev_poll and pool_poll), but that is kept in place mostly because this will be re-extended in the future (vulkan rev 2). The queue count is also currently capped to 1, because of the lack of cross-frame semaphores means we need the implicit synchronization from the same-queue semantics to guarantee a correct result.
* android: posix_spawn(p) replacementsfan52017-09-221-2/+12
| | | | Signed-off-by: wm4 <wm4@nowhere>
* build: make vo_gpu + infrastructure non-optionalwm42017-09-221-8/+3
| | | | | Also readd the the error message for when no GL backends are found (why was this removed?).
* vo_opengl: refactor into vo_gpuNiklas Haas2017-09-211-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is done in several steps: 1. refactor MPGLContext -> struct ra_ctx 2. move GL-specific stuff in vo_opengl into opengl/context.c 3. generalize context creation to support other APIs, and add --gpu-api 4. rename all of the --opengl- options that are no longer opengl-specific 5. move all of the stuff from opengl/* that isn't GL-specific into gpu/ (note: opengl/gl_utils.h became opengl/utils.h) 6. rename vo_opengl to vo_gpu 7. to handle window screenshots, the short-term approach was to just add it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to ra itself (and vo_gpu altered to compensate), but this was a stop-gap measure to prevent this commit from getting too big 8. move ra->fns->flush to ra_gl_ctx instead 9. some other minor changes that I've probably already forgotten Note: This is one half of a major refactor, the other half of which is provided by rossy's following commit. This commit enables support for all linux platforms, while his version enables support for all non-linux platforms. Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the --opengl- options like --opengl-early-flush, --opengl-finish etc. Should be a strict superset of the old functionality. Disclaimer: Since I have no way of compiling mpv on all platforms, some of these ports were done blindly. Specifically, the blind ports included context_mali_fbdev.c and context_rpi.c. Since they're both based on egl_helpers, the port should have gone smoothly without any major changes required. But if somebody complains about a compile error on those platforms (assuming anybody actually uses them), you know where to complain.
* build: add preliminary LGPL modewm42017-09-211-10/+31
| | | | | | | See "Copyright" file for caveats. This changes the remaining "almost LGPL" files to LGPL, because we think that the conditions the author set for these was fina