summaryrefslogtreecommitdiffstats
path: root/wscript
Commit message (Collapse)AuthorAgeFilesLines
* 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 mature and well supported APIs, but on Linux, VDPAU is falling behind the hardware capabilities, and there's no sign that nvidia are making the investments to update it. Most concretely, this means that there is no VP8/9 or HEVC Main10 support in VDPAU. On the other hand, NvDecode does export vp8/9 and partial support for HEVC Main10 (more on that below). ffmpeg already has support in the form of the "cuvid" family of decoders. Due to the design of the API, it is best exposed as a full decoder rather than an hwaccel. As such, there are decoders like h264_cuvid, hevc_cuvid, etc. These decoders support two output paths today - in both cases, NV12 frames are returned, either in CUDA device memory or regular system memory. In the case of the system memory path, the decoders can be used as-is in mpv today with a command line like: mpv --vd=lavc:h264_cuvid foobar.mp4 Doing this will take advantage of hardware decoding, but the cost of the memcpy to system memory adds up, especially for high resolution video (4K etc). To avoid that, we need an hwdec that takes advantage of CUDA's OpenGL interop to copy from device memory into OpenGL textures. That is what this change implements. The process is relatively simple as only basic device context aquisition needs to be done by us - the CUDA buffer pool is managed by the decoder - thankfully. The hwdec looks a bit like the vdpau interop one - the hwdec maintains a single set of plane textures and each output frame is repeatedly mapped into these textures to pass on. The frames are always in NV12 format, at least until 10bit output supports emerges. The only slightly interesting part of the copying process is that CUDA works by associating PBOs, so we need to define these for each of the textures. TODO Items: * I need to add a download_image function for screenshots. This would do the same copy to system memory that the decoder's system memory output does. * There are items to investigate on the ffmpeg side. There appears to be a problem with timestamps for some content. Final note: I mentioned HEVC Main10. While there is no 10bit output support, NvDecode can return dithered 8bit NV12 so you can take advantage of the hardware acceleration. This particular mode requires compiling ffmpeg with a modified header (or possibly the CUDA 8 RC) and is not upstream in ffmpeg yet. Usage: You will need to specify vo=opengl and hwdec=cuda. Note that hwdec=auto will probably not work as it will try to use vdpau first. mpv --hwdec=cuda --vo=opengl foobar.mp4 If you want to use filters that require frames in system memory, just use the decoder directly without the hwdec, as documented above.
* atomics: readd some emulationwm42016-09-061-2/+6
| | | | | | | | | | | This time it's emulation that's supposed to work (not just dummied out). Unlike the previous emulation, no mpv code has to be disabled, and everything should work (albeit possibly a bit slowly). On the other hand, it's not possible to implement this kind of emulation without compiler support. We use GNU statement expressions and __typeof__ in this case. This code is inactive if stdatomic.h is available.
* wscript: fix typopavelxdd2016-09-061-1/+1
|
* build: make avutil-mastering-metadata check slightly more robustwm42016-08-181-1/+1
| | | | | Fixes the specific scenario of compiling against a local Libav build, while the system has FFmpeg installed.
* wscript: improve stdatomic checkThomas Petazzoni2016-08-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The current stdatomic check verifies the availability of the function by calling atomic_load(). It also uses this test to check if linking against libatomic is needed or not. Unfortunately, on specific architectures (namely SPARC), using atomic_load() does *not* require linking against libatomic, while other atomic operations do. Due to this, mpv's wscript concludes that stdatomic is available, and that linking against libatomic is not needed, causing the following link failure: [190/190] Linking build/mpv audio/out/ao.c.13.o: In function `ao_query_and_reset_events': /home/peko/autobuild/instance-0/output/build/mpv-0.18.1/build/../audio/out/ao.c:399: undefined reference to `__atomic_fetch_and_4' In order to fix this, the stdatomic check is adjusted to call atomic_fetch_add() instead, which does require libatomic. Thanks to this, the wscript realizes that linking against libatomic is needed, and the build works fine. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* build: always require atomicswm42016-08-051-5/+2
| | | | | | | | | | | | | | | Always require them, instead of just for some components which have hard requirements on correct atomic semantics. They should be widely available, and are supported by all recent gcc and clang compiler versions. We even have the fallbacks builtins, which should keep this working on very old gcc releases. In particular, w32_common.c recently added a hard requirement on atomics, but checking this properly in the build system would have been messy. This commit makes sure it always works. The fallback where weak atomic semantics are always fine is in theory rather questionable as well.
* build: add --htmldir optionChris Mayo2016-07-301-0/+1
| | | | | Defaults to docdir but makes it possible to install html documentation separately.
* vd_lavc: expose mastering display side data reference peakNiklas Haas2016-07-031-0/+6
| | | | | | | | | | | | | | | | | | | This greatly improves the result when decoding typical (ST.2084) HDR content, since the job of tone mapping gets significantly easier when you're only mapping from 1000 to 250, rather than 10000 to 250. The difference is so drastic that we can now even reasonably use `hdr-tone-mapping=linear` and get a very perceptually uniform result that is only slightly darker than normal. (To compensate for the extra dynamic range) Due to weird implementation details, this only seems to be present on keyframes (or something like that), so we have to cache the last seen value for the frames in between. Also, in some files the metadata is just completely broken / nonsensical, so I decided to apply a simple heuristic to detect completely broken metadata.
* vo_opengl: implement ARIB STD-B68 (HLG) HDR TRCNiklas Haas2016-06-281-3/+4
| | | | | | | | | | | | | | This HDR function is unique in that it's still display-referred, it just allows for values above the reference peak (super-highlights). The official standard doesn't actually document this very well, but the nominal peak turns out to be exactly 12.0 - so we normalize to this value internally in mpv. (This lets us preserve the property that the textures are encoded in the range [0,1], preventing clipping and making the best use of an integer texture's range) This was grouped together with SMPTE ST2084 when checking libavutil compatibility since they were added in the same release window, in a similar timeframe.
* vo_opengl: remove nnedi3 prescalerBin Jin2016-06-181-5/+0
|
* Revert "wscript: Require recent FFmpeg by default"wm42016-06-091-45/+24
| | | | | | | This reverts commit b51957fab59fd5a2fde824e1946befd29ed172c1. Breaks big time. It appears to ignore explicitly configured paths within the libav* .pc files, which for example breaks mpv-build.
* wscript: Require recent FFmpeg by defaultMartin Herkt2016-06-091-24/+45
| |