summaryrefslogtreecommitdiffstats
path: root/wscript
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | | | | | | Distros and users alike should be made aware of the fact that old FFmpeg versions are bad. When users come to us with FFmpeg-related trouble, the answer is “update FFmpeg” more often than not (and no further support will be provided until they have done so), so instead we just nag them about it here.
* build: Do not link to libGL for egl-drmQuentin Glidic2016-05-201-1/+4
| | | | Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
* csputils: add AVCOL_TRC_SMPTEST2084 supportNiklas Haas2016-05-161-1/+7
| | | | | | | This now lets us auto-detect appropriately tagged HDR content using FFmpeg's new TRC entries (when available). Hidden behind an #if because Libav stable doesn't have it yet.
* build: merge d3d11va and dxva2 hwaccel checkswm42016-05-111-13/+5
| | | | | | We don't have any reason to disable either. Both are loaded dynamically at runtime anyway. There is also no reason why dxva2 would disappear from libavcodec any time soon.
* vo_opengl: angle: dynamically load ANGLEwm42016-05-111-3/+2
| | | | | | | | | | | | ANGLE is _really_ annoying to build. (Requires special toolchain and a recent MSVC version.) This results in various issues with people having trouble to build mpv against ANGLE (apparently linking it against a prebuilt binary doesn't count, or using binaries from potentially untrusted sources is not wanted). Dynamically loading ANGLE is going to be a huge convenience. This commit implements this, with special focus on keeping it source compatible to a normal build with ANGLE linked at build-time.
* wscript: make at least 1 OpenGL output mandatorywm42016-05-011-1/+5
| | | | | You have to explicitly disable it if you really want to compile without it (like with libass).
* win32: replace libuuid.a usage with initguid.hJames Ross-Gowan2016-05-011-1/+1
| | | | | | | | | | | | | | | Including initguid.h at the top of a file that uses references to GUIDs causes the GUIDs to be declared globally with __declspec(selectany). The 'selectany' attribute tells the linker to consolidate multiple definitions of each GUID, which would be great except that, in Cygwin and MinGW GCC 6.1, this method of linking makes the GUIDs conflict with the ones declared in libuuid.a. Since initguid.h obsoletes libuuid.a in modern compilers that support __declspec(selectany), add initguid.h to all files that use GUIDs and remove libuuid.a from the build. Fixes #3097
* build: add check for AVHWFramesContext APIwm42016-04-141-0/+6
| | | | | It's not used yet anywhere. Pushing this now so switching between branches is less bothersome.
* Revert "build: disable encoding mode by default"Rudolf Polzer2016-04-111-1/+0
| | | | | | Reverting because the use of deprecated API has been fixed. This reverts commit d0238711dc776aeee2509452202ba4748f863ee4.
* build: fix AVCodecParameters FFmpeg API check (again)wm42016-04-021-2/+2
| | | | | | | Commit 0d746522 was complete non-sense. The description and the code mention the wrong struct. This time I actually tested it.
* build: fix AVCodecParameters FFmpeg API checkwm42016-04-011-1/+1
| | | | | | FFmpeg partially merged the API change. It added the AVCodecParameters definition, but not the AVCodecContext.codecpar field. The new code compiles only with the API fully merged, so adjust the check.
* build: disable encoding mode by defaultwm42016-03-311-0/+1
| | | | | | | | | Encoding mode uses deprecated API. See previous commit. Encoding mode will stop working/compiling at some point in the future, so unless someone fixes the encoding code, it will stay disabled by default. (Note that the deprecations are not merged in FFmpeg yet, but they will soon. They've been deprecated in Libav for a while now.)
* demux_lavf, ad_lavc, ad_spdif, vd_lavc: handle FFmpeg codecpar API changewm42016-03-311-1/+7
| | | | | | | | | AVFormatContext.codec is deprecated now, and you're supposed to use AVFormatContext.codecpar instead. Handle this for all of the normal playback code. Encoding mode isn't touched.
* vd_lavc: add d3d11va hwdecKevin Mitchell2016-03-301-1/+11
| | | | | | This commit adds the d3d11va-copy hwdec mode using the ffmpeg d3d11va api. Functions in common with dxva2 are handled in a separate decode/d3d.c file. A future commit will rewrite decode/dxva2.c to share this code.
* build: allow plain-gl build on OSXwm42016-03-261-3/+3
| | | | | | Still requires Cocoa for various things, but no vo_opengl. Untested. Fixes #2980 (probably).
* ad_lavc, vd_lavc: support new Libav decoding APIwm42016-03-241-0/+6
| | | | For now only found in Libav.
* ao: initial OpenSL ES supportIlya Zhuravlev2016-02-271-0/+4
| | | | | | | | OpenSL ES is used on Android. At the moment only stereo output is supported. Two options are supported: 'frames-per-buffer' and 'sample-rate'. To get better latency the user of libmpv should pass values obtained from AudioManager.getProperty(PROPERTY_OUTPUT_FRAMES_PER_BUFFER) and AudioManager.getProperty(PROPERTY_OUTPUT_SAMPLE_RATE).
* wscript: remove dxva2-dxinterop configure testKevin Mitchell2016-02-171-5/+0
| | | | Wasn't really necessary as it was equivalent to gl-dxinterop.
* vo_opengl: dxinterop: add dxva2 passthroughKevin Mitchell2016-02-171-0/+5
| | | | | Use dxva2 surface to fill RGB IDirect3DSurface9 shared with opengl via DXRegisterObjectNV.
* build: enable vaapi under drm-onlywm42016-02-111-1/+1
| | | | Fixes #2808.
* Enable building the opengl-cb video renderer on AndroidJan Ekström2016-02-101-3/+18
| | | | | | * Add Android-specific OpenGL ES feature and checks * Add missing GL_* symbols for Android (list gathered by Ilya Zhuravlev <whatever@xyz.is>)
* Initial Android supportJan Ekström2016-02-101-0/+4
| | | | | * Adds an 'android' feature, which is automatically detected. * Android has a broken strnlen, so a wrapper is added from FreeBSD.
*