summaryrefslogtreecommitdiffstats
path: root/wscript
Commit message (Collapse)AuthorAgeFilesLines
* wscript: make OpenGL VO failure message less misleadingwm42017-05-041-1/+1
| | | | | It doesn't even use OpenGL header anymore. What it needs are EGL and GLX libs/header and similar.
* build: remove checks for libGLwm42017-04-261-6/+2
| | | | | | We don't need to link against libGL directly, nor do we need OpenGL headers. The only thing we need is the windowing interop stuff, such as libEGL.
* video: drop vaapi/vdpau hw decoding support with FFmpeg 3.2wm42017-04-231-27/+3
| | | | | | | | | | This drops support for the old libavcodec APIs. Now FFmpeg 3.3 or FFmpeg git is required. Libav has no release with the new APIs yet, so for Libav git as of a few weeks or months ago or so is required if you want to use Libav. Not much actually changes in hwdec_vaegl.c - some code is removed, but the reindentation inflates the diff.
* build: make various x11 protocol extension libs mandatorywm42017-04-211-21/+5
| | | | | | | Reduces the ifdeffery, which is good and will avoid silent breakages, or weird behavior if a lib is omitted. Also reorder the x11_common.c include statements.
* wscript: don't make dvdread-common an optionRicardo Constantino2017-04-071-2/+2
| | | | | | | | This just checks if dvdread or dvdnav are enabled so it can compile dvdread code. Change description to be clearer on what this does differently from --enable-dvdread.
* vo_opengl: add our own copy of OpenGL headerswm42017-04-071-18/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gl_headers.h is basically header_fixes.h done consequently. It contains all OpenGL defines (and some typedefs) we need. We don't include GL headers provided by the system anymore. Some care has to be taken by certain windowing APIs including all of gl.h anyway. Then the definitions could clash. Fortunately, redefining preprocessor symbols to the same content is allowed and ignored. Also, redefining typedefs to the same thing is allowed in C11. Apparently the latter is not allowed in C99, so there is an imperfect attempt to avoid the typedefs if required API symbols are apparently present already. The nost risky part about this are the standard typedefs and GLAPIENTRY. The latter is different only on win32 (and at least consistently so). The typedefs are mostly based on stdint.h typedefs, which khrplatform.h clumsily emulates on platforms which don't have it. The biggest difference is that we define GLsizeiptr directly to ptrdiff_t, instead of checking for the _WIN64 symbol and defining it to long or long long. This also typedefs GLsync to __GLsync, just like the khronos headers. Although symbols prefixed with __ are implementation reserved, khronos also violates this rule, and having the same definition as khronos will avoid problems on duplicate definitions. We can simplify the build scripts too. The ios-gl check seems a bit wrong now (what we really want to test for is EAGLContext), but I can't test and thus can't improve it. cuda_dynamic.h redefined two GL symbols; just include the new headers directly instead.
* wscript: avoid compose_checks in one casewm42017-04-061-4/+2
| | | | | Avoid it where we can, because it tends to have unexpected side-effects. (Probably not in this case, but still a reason to avoid it.)
* build: replace android-gl check with a standard GLES3 checkwm42017-04-061-4/+4
| | | | | There's no reason to make it Android specific, as it uses standard include paths.
* wscript: fix broken build with dvdread+dvdnav in 34e6a26Ricardo Constantino2017-03-311-0/+5
| | | | Didn't know waf actually tried to compile the same files twice.
* wscript: decouple dvdnav check from dvdreadRicardo Constantino2017-03-311-2/+2
| | | | | | | | | Reallows enabling dvdnav without enabling dvdread which was broken in 77cbb3543 when they were both disabled by default. Since dvdnav requires dvdread, we can enable dvdread:// even if --enable-dvdread isn't passed. Fixes #4290
* osx: initial Touch Bar supportAkemi2017-03-261-1/+10
|
* vdpau: support new vdpau libavcodec decode APIwm42017-03-231-1/+18
| | | | | | | | | | | | | | | | | | | The new API works like the new vaapi API, using generic hwaccel support. One minor detail is the error message that will be printed if using non-4:2:0 surfaces (which as far as I can tell is completely broken in the nVidia drivers and thus not supported by mpv). The HEVC warning (which is completely broken in the nVidia drivers but should work with Mesa) had to be added to the generic hwaccel code. This also trashes display preemption recovery. Fuck that. It never really worked. If someone complains, I might attempt to add it back somehow. This is the 4th iteration of the libavcodec vdpau API (after the separate decoder API, the manual hwaccel API, and the automatic vdpau hwaccel API). Fortunately, further iterations will be generic, and not require much vdpau-specific changes (if any at all).
* build: disable optical media libs by default (DVD/BD/CD)wm42017-03-151-0/+4
| | | | Pure garbage.
* wscript: substitute cplugins linker flag for macOS compatiblityAlexis Nootens2017-03-061-2/+2
| | | | | | | | | | For an unknown reason, '-Wl -export-dynamic' doesn't work anymore on the last macOS build (10.12.3 with Apple LLVM 8.0.0) so forcing cplugins is useless because the check fails. Replacing the linker option with its substitute '-rdynamic' do the trick. The syms module from waf still works as expected and only the symbols specified in mpv.def are exported.
* wscript: drop pointless libavcodec vaapi.h/dxva2.h/d3d11va.h checkswm42017-02-201-5/+3
| | | | | | Not needed under any circumstances. While the Windows ones export functions to which we must link, these functions are always available, even if libavcodec was compiled with D3D disabled.
* wscript: fix --egl-angle-lib for waf 1.9James Ross-Gowan2017-02-191-2/+4
|
* atomic: remove __atomic builtin usagewm42017-02-131-10/+2
| | | | | | | | Using these was a temporary solution while some compilers implemented the underlying atomic mechanisms, but not the C11 language parts (or that's what I guess). Not really useful for us anymore. Also, there is the slight risk of having subtly incorrect semantics by using potentially changing compiler internals and such.
* vo_opengl: angle: rewrite with custom swap chainJames Ross-Gowan2017-02-071-1/+2
| | | | | | | | | | | | | This replaces the old backend that exclusively used EGL windowing with one that can also use ANGLE's ability to render to directly to a texture. The advantage of this is that it allows mpv to create the swap chain itself and this allows mpv to use a flip-mode swap chain on a HWND (which avoids problems with DirectComposition) and to use a longer swap chain that has six backbuffers by default (which reportedly fixes problems with rendering 24fps video on 24Hz monitors.) Also, "screenshot window" should now work on DXGI 1.2 and up (Windows 8 and up.)
* build: fix --disable-gl if cuda is enabledwm42017-01-301-0/+1
| | | | | | | | | video/out/opengl/hwdec_cuda.c is enabled with cuda-hwaccel. But it makes only sense to build if GL is enabled, and in fact it fails to link without GL as it calls a specific GL helper function. In theory it would be perfectly possible to use cuda-copy with GL disabled. But I'm not bothering with the complexity.
* wscript: add LIBRARY_PATH for library detectionkwkam2017-01-281-0/+2
| | | | | | MinGW GCC seems to ignore LIBRARY_PATH which causes problem when some libraries not using pkg-config were installed to local directory
* build: rpi: rely on pkgconfig for compiler flagsIlya Tumaykin2017-01-281-19/+1
| | | | | | | | | | | | | | | | | Upstream provides pkgconfig files for quite some time now [1,2]. Use them to determine the required flags instead of hard coding. This makes cross-compilation easy, which I dare to say is important for many raspberry-pi users. This also prevents picking libEGL and libGLESv2 from mesa when they are present, which can happen with the current code. Good distros should put these pkgconfig files into default pkg-config search path or populate PKG_CONFIG_PATH for users. However, be nice to everybody and manually look into '/opt/vc/lib/pkgconfig' just in case. Hence the PKG_CONFIG_PATH mangling. [1]: https://github.com/raspberrypi/userland/issues/245 [2]: https://github.com/raspberrypi/userland/commit/05d60a01d53dca363bb4286594db1826ffff8762
* build: explicitly check for FFmpeg vs. Libav, and their exact versionswm42017-01-271-39/+52
| | | | | | | | | | | | | | | | | | In a first pass, we check whether libavcodec is present. Then we try to compile a snippet and check for FFmpeg vs. Libav. (This could probably also be done by somehow checking the pkgconfig version. But pkg-config can't deal with that idiotic FFmpeg idea that a micro version number >= 100 identifies FFmpeg vs. Libav.) After that we check the project-specific version numbers. This means it can no longer happen that we accidentally allow older, unsupported versions of FFmpeg, just because the Libav version numbers are somehow this way. Also drop the resampler checks. We hardcode which resampler to each with each project. A user can no longer force use of libavresample with FFmpeg.
* wscript: merge libavfilter check into the main ffmpeg checkwm42017-01-271-7/+2
| | | | | It used to be optional. That's why it was separate. No need for that anymore.
* atomic: drop __sync builtinswm42017-01-271-9/+1
| | | | | | | | | | The correctness of the stdatomic.h emulation via the __sync builtins is questionable, and we've been relying on exact stdatomic semantics for a while, so just get rid of it. Compilers which support __sync but not stdatomic.h will use to the slow mutex fallback. Not sure about the __atomic builtins. It doesn't seem to harm either, so leave it for now.
* build: new vaapi hwaccel API does not use av_image_copy_uc_from()wm42017-01-241-1/+1
| | | | | | | | | | | Not even Libav does. Whoops. The developer who wrote the FFmpeg code for this said he could not find any improvements when using the "GPU memcpy" ; instead, it made it actually slower on some hardware. It's not clear to what extent the "GPU memcpy" was needed for vaapi, but hopefully not very much (see #2317). This commit enables use of the new vaapi API by default with FFmpeg.
* build: replace some FFmpeg API checks with version checkswm42017-01-241-24/+0
| | | | | | The FFmpeg versions we support all have the APIs we were checking for. Only Libav missed them. Simplify this by explicitly checking for FFmpeg in the code, instead of trying to detect the presence of the API.
* vaapi: detect new API on FFmpeg too, and disable it by defaultwm42017-01-181-2/+11
| | | | | | | | | | | | | | | Since the only way to detect the API is by a version check, this had to wait until the patches were actually pushed to FFmpeg git (which now happened). Since this does not include the new magic GPU memcpy libavutil function yet, the new vaapi code would be slower if copy mode (like vaapi-copy) is used. This would be quite bad to use by default, so check for the function, and if not present, disable the new vaapi code. This effectively disables it by default on FFmpeg. (We assume that if the new GPU memcpy exists, vaapi's AVHWFramesContext implementation will use it.)
* vaapi: we don't need SSE intrinsics with the new APIwm42017-01-171-1/+1
| | | | | | | libavutil does this for us. Although the new vaapi decode API does not strictly introduce or even need av_image_copy_uc_from(), it's implied that it will be present if the new decode API is present - even if it's not, we can't use our own SSE code with it anyway.
* player: add experimental C plugin interfacewm42017-01-121-0/+13
| | | | | | | | | | | | | | | | | This basically reuses the scripting infrastructure. Note that this needs to be explicitly enabled at compilation. For one, enabling export for certain symbols from an executable seems to be quite toolchain-specific. It might not work outside of Linux and cause random problems within Linux. If C plugins actually become commonly used and this approach is starting to turn out as a problem, we can build mpv CLI as a wrapper for libmpv, which would remove the requirement that plugins pick up host symbols. I'm being lazy, so implementation/documentation are parked in existing files, even if that stuff doesn't necessarily belong there. Sue me, or better send patches.
* wscript: slightly simplify configure check for new vaapi decode APIwm42017-01-121-10/+3
| | | | | We can drop the weird acrobatics with the is_ffmpeg. We can distinguish them directly within the vaapi check, duh.
* vaapi: support new libavcodec vaapi APIwm42017-01-111-0/+21
| | | | | | | | | | | | | | | | | The old API is deprecated, and libavcodec prints a warning at runtime. The new API is a bit nicer and does many things for you, such as managing the underlying hwaccel decoder. libavutil also provides code for managing surfaces (we use their surface pool). The new code does not contain any code from the original MPlayer VAAPI patch (that was used as base for some of the vaapi code in mpv). Thus the new code is LGPL. The new API actually does not add any visible symbols, so the only way to detect it is a version check. Of course, the versions overlap between FFmpeg and Libav, which requires additional care. The new API did not get merged into FFmpeg yet, so there's no check for FFmpeg.
* build: use matroska.py & file2string.py as python modulesStefano Pigozzi2017-01-051-1/+0
|
* Revert "Port several python scripts to Perl"wm42016-12-171-1/+3
| | | | | | | | | | | | | | | | | | This reverts commit fae73079310eef9dce9737f2e37ff4b80c8830ee. Before the waf build system was used, we had a configure script written in shell. To drop the build dependency on Python, someone rewrote the Python scripts we had to Perl. Now the shell configure script is gone, and it makes no sense to have a build dependency on both Perl and Python. This isn't just a straight revert. It adds the new Matroska EBML elements to the old Python scripts, adjusts the waf build system, and of course doesn't add anything back needed by the old build system. It would be better if this used matroska.py/file2string.py directly by importing them as modules, instead of calling them via "python". But for now this is simpler.
* options: change --h=... behaviorwm42016-12-161-4/+0
| | | | | Does not match a shell pattern anymore. Instead, a simple sub-string search is done.
* charset_conv: drop enca and libguess supportwm42016-12-091-10/+0
| | | | | | | | Enca is dead. libguess is relatively useless due to not having an universal detection mode. On the other hand, libuchardet is actively developed. Manpages changes in the following commit.
* Remove compatibility thingswm42016-12-071-68/+1
| | | | | | Possible with bumped FFmpeg/Libav. These are just the simple cases.
* build: bump required minimum versions to FFmpeg 3.2.2 and Libav 12wm42016-12-071-9/+24
| | | | Fixes the build with Libav 11 (not).
* demux, stream: add option to prevent opening referenced fileswm42016-12-041-0/+6
| | | | Quite irresponsibly hacked together. Sue me.
* wscript: add ANGLE_EXPORT definitionshinchiro2016-12-041-1/+1
| | | | It always needed when linking ANGLE libs
* wscript: Fix cuda test to actually work when cuda SDK is not presentPhilip Langdale2016-11-231-3/+2
| | | | | | | | | | The test ended up failing if cuda.h wasn't present, even if cuda.h isn't used during the actual build. This test is attempting to establish if the ffmpeg being built against has dynlink_cuda support. While it might theoretically be possible to build against the older normally-linked-cuda version of ffmpeg, it seems more trouble than it's worth.
* Support linking ANGLEMartin Herkt2016-11-231-0/+9
|
* vo_opengl: hwdec_cuda: Use dynamic loading for cuda functionsPhilip Langdale2016-11-231-3/+3
| | | | | This change applies the pattern used in ffmpeg to dynamically load cuda, to avoid requiring the CUDA SDK at build time.
* build: fix compilation with mingw-w64/ClangJames Ross-Gowan2016-11-171-1/+1
| | | | | | | | | | This fixes the build in mingw-w64/Clang on MSYS2. It also disables the use of gnu_printf in Clang, which was what was causing most of the warnings. The Clang-compiled mpv binary appears to work, but there are no guarantees yet, since until now mpv has only been tested with mingw-w64/GCC on Windows. Fixes #3800
* wscript: move install dirs setting to after C compiler checkRicardo Constantino2016-11-161-6/+6
| | | | | | | | This fixes waf setting the wrong LIBDIR for DEST_OS=win32 in waflib/Tools/c_config.py:get_cc_version() Any scripts assuming the implib and pkgconfig are in the wrong place should be changed to move the .dll instead.
* options: fnmatch: check existence instead of posixAvi Halachmi (:avih)2016-11-081-0/+4
|
* audio/out: add AudioUnit output driver for iOSAman Gupta2016-11-011-0/+7
|
* wscript: rebuild on library header changesRodger Combs2016-10-211-0/+4
| | | | In particular, libav<x>/version.h changing should trigger a rebuild
* build: add required failure message for libavfilter checkwm42016-10-201-0/+1
| | | | | | If req==True, a fmsg must be set (apparently). Fixes #3692, probably.
* build: don't rely on "__thread" being always available with GCCDmitrij D. Czarkoff2016-10-201-0/+4
| | | | | | | | | | | | | Thread-local storage in GCC is platform-specific, and some platforms that are otherwise perfectly capable of running mpv may lack TLS support in GCC. This change adds a test for GCC variant of TLS and relies on its result instead of assumption. Provided that LLVM's `__thread` support is similar to GCC, the test is called "GCC/LLVM TLS". Signed-off-by: wm4 <wm4@nowhere>
* wscript: videotoolbox is available on iOS even though IOSurface is notAman Gupta2016-10-201-2/+3
|
* opengl: compile against iOS OpenGLES implementationAman Gupta2016-10-201-1/+5
|
* win32: build with -DINITGUIDJames Ross-Gowan2016-09-281-1/+1
| | | | | | | | | | | | We always want to use __declspec(selectany) to declare GUIDs, but manually including <initguid.h> in every file that used GUIDs was error-prone. Since all <initguid.h> does is define INITGUID and include <guiddef.h>, we can remove all references to <initguid.h> and just compile with -DINITGUID to get the same effect. Also, this partially reverts 622bcb0 by re-adding libuuid.a to the build, since apparently some GUIDs (such as GUID_NULL) are not declared in the source file, even when INITGUID is set.
* ao_openal: enable building on OSXJosh de Kock2016-09-211-1/+1
| | | | Signed-off-by: Josh de Kock <josh@itanimul.li>
* hwdec_cuda: Rename config variable to be more consistentPhilip Langdale2016-09-161-2/+2
| | | | | | 'cuda-gl' isn't right - you can turn this on without any GL and get some non-zero benefit (with the cuda-copy hwaccel). So 'cuda-hwaccel' seems more consistent with everything else.
* vo_opengl: drm: use new EGL context creation codewm42016-09-141-1/+1
|
* vo_opengl: wayland: use new EGL context creation codewm42016-09-141-1/+1
|
* vo_opengl: rpi: use new egl context creation helper functionwm42016-09-131-1/+1
| | | | Only for the "new" vo_opengl backend code.
* vo_opengl: mali fbdev supportwm42016-09-131-3/+14
| | | | | | | | | | | | Minimal support just for testing. Only the window surface creation (including size determination) is really platform specific, so this could be some generic thing with platform-specific support as some sort of sub-driver, but on the other hand I don't see much of a need for such a thing. While most of the fbdev usage is done by the EGL driver, using this fbdev ioctl is apparently the only way to get the display resolution.
* hwdec/opengl: Add support for CUDA and cuvid/NvDecodePhilip Langdale2016-09-081-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Nvidia's "NvDecode" API (up until recently called "cuvid" is a cross platform, but nvidia proprietary API that exposes their hardware video decoding capabilities. It is analogous to their DXVA or VDPAU support on Windows or Linux but without using platform specific API calls. As a rule, you'd rather use DXVA or VDPAU as these are more