summaryrefslogtreecommitdiffstats
path: root/wscript
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* build: enable vo_opengl_cb if GL headers are presentwm42016-02-081-1/+10
| | | | | | | | | | | | To be more specific, enable vo_opengl and vo_opengl_cb, if libmpv is compiled, and the GL headers happen to be in the default search paths. Although platform specific code can be useful for libmpv (for window embedding, and even with vo_opengl_cb for certain forms of hardware decoding), it's not a requirement to use the opengl_cb API. Enabling vo_opengl is not useful here, but the rest of the build system doesn't distinguish vo_opengl and vo_opengl_cb, and I see no reason to.
* build: make posix_spawn optionalwm42016-02-081-1/+0
| | | | OK, Android doesn't support it.
* wscript: mark subprocess as requiredwm42016-02-071-0/+1
| | | | | | | We either need to be on Windows, or have posix_spawn available. If someone can come up with a system that is POSIX, but does not provide posix_spawn, we could make it optional.
* build: make libavfilter mandatorywm42016-02-051-1/+2
| | | | | | The complex filter support that will be added makes much more complex use of libavfilter, and I'm not going to bother with adding hacks to keep libavfilter optional.
* wscript: Update `--lua' helpMichael Reed2016-01-221-1/+1
| | | | This was outdated after a1f949d3b83224306e099c7d670f11eb8f249b84.
* vo_opengl: add KMS/DRM VAAPI hardware decoding interopwm42016-01-201-1/+5
| | | | Just requires glueing it together with Bloat Super Glue (tm).
* build: add option to customize config files system pathStefano Pigozzi2016-01-111-0/+2
| | | | | | | Some packagers need to install default config files to some path but automatically load system configuration files from another path. See #2704
* Fix build on older libavcodec versionswm42016-01-081-0/+6
| | | | avcodec_profile_name() was added only a week ago or so.
* ao_dsound: remove this audio outputwm42016-01-061-4/+0
| | | | | | | It existed for XP-compatibility only. There was also a time where ao_wasapi caused issues, but we're relatively confident that ao_wasapi works better or at least as good as ao_dsound on Windows Vista and later.
* build: add option of html manualChris Mayo2016-01-051-0/+6
|
* vo_opengl: fall back to gcc thread local storage (2)wm42015-12-231-1/+0
| | | | | | | | | | | | Commit 1a6f3c56 added a fallback for the case when C11 TLS was not available, but GCC TLS was. But it forget to enable VAAPI EGL interop in the build system in this case. Just remove the build system check. Should someone find a compiler that works on Linux and does not support GCC extensions or C11, it will still compile and just fail to init at runtime. Actually fixes #2631 (hopefully).
* win32: input: use Vista CancelIoExJames Ross-Gowan2015-12-201-6/+0
| | | | | | | | | | | | | | | | | libwaio was added due to the complete inability to cancel synchronous I/O cleanly using the public Windows API in Windows XP. Even calling TerminateThread on the thread performing I/O was a bad solution, because the TerminateThread function in XP would leak the thread's stack. In Vista and up, however, this is no longer a problem. CancelIoEx can cancel synchronous I/O running on other threads, allowing the thread to exit cleanly, so replace libwaio usage with native Vista API functions. It should be noted that this change also removes the hack added in 8a27025 for preventing a deadlock that only seemed to happen in Windows XP. KB2009703 says that Vista and up are not affected by this, due to a change in the implementation of GetFileType, so the hack should not be needed anymore.
* vo_opengl: x11egl: retrieve framebuffer depthwm42015-12-191-1/+6
| | | | | | | | | | This is used for dithering, although I'm not aware of anyone who got higher than 8 bit depth support to work on Linux. Also put this into egl_helpers.c. Since EGL is pseudo-portable at best I have no hope that the EGL context creation code in all the backends can be fully shared. But some self-contained functionality can definitely be shared.
* vo_opengl: add dxinterop backendJames Ross-Gowan2015-12-11