summaryrefslogtreecommitdiffstats
path: root/wscript
Commit message (Collapse)AuthorAgeFilesLines
* 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-111-0/+8
| | | | | | | | | | | | | | | | | | | | | WGL_NV_DX_interop is widely supported by Nvidia and AMD drivers. It allows a texture to be shared between Direct3D and WGL, so that rendering can be done with WGL and presentation can be done with Direct3D. This should allow us to work around some persistent WGL issues, such as dropped frames with some driver/OS combos, drivers that buffer frames to increase performance at the cost of latency, and the inability to disable exclusive fullscreen mode when using WGL to render to a fullscreen window. The addition of a DX_interop backend might also enable some cool Direct3D-specific enhancements in the future, such as using the GetPresentStatistics API to get accurate frame presentation timestamps. Note that due to a driver bug, this backend is currently broken on Intel. It will appear to work as long as the window is not resized too often, but after a few changes of size it will be unable to share the newly created renderbuffer with GL. See: https://software.intel.com/en-us/forums/graphics-driver-bug-reporting/topic/562051
* stream: drop PVR supportwm42015-12-101-5/+0
| | | | | | | | | This is only for specific Hauppage cards. According to the comments in who is actively using this feature. Get it out of the way. Anyone who still wants to use this should complain. Keeping this code would not cause terribly much additional work, and it could be restored again. (But not if the request comes months later.)
* win32: enable internal pthreads wrapper by defaultwm42015-12-041-1/+0
|
* win32: remove dwmapi.dll dynamic loadingwm42015-12-041-1/+1
| | | | All Windows versions we support have this API.
* vo_opengl: require --enable-gpl3 for nnediwm42015-12-031-0/+5
| | | | | | | | | There are claims that nnedi3.c doesn't constitute its own new implementation, but is derived from existing HLSL or OpenCL shaders distributed under the LGPLv3 license. Until these are resolved, do the "correct" thing and require --enable-gpl3 to build nnedi.
* vo_opengl: add initial ANGLE supportJames Ross-Gowan2015-11-181-0/+8
| | | | | | | | | | | ANGLE is a GLES2 implementation for Windows that uses Direct3D 11 for rendering, enabling vo_opengl to work on systems with poor OpenGL drivers and bypassing some of the problems with native GL, such as VSync in fullscreen mode. Unfortunately, using GLES2 means that most of vo_opengl's advanced features will not work, however ANGLE is under rapid development and GLES3 support is supposed to be coming soon.
* build: make vaapi-wayland depend on gl-waylandwm42015-11-121-1/+1
| | | | | | | Wayland without GL isn't enough. Specifically, we need to make sure the EGL libs are included. (That's one tricky dependency tree.) Fixes #2476.
* win32: request MMCSS "Playback" profilewm42015-11-081-1/+1
|
* vo_opengl: add DRM EGL backendrr-2015-11-081-6/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Notes: - Unfortunately the only way to talk to EGL from within DRM I could find involves linking with GBM (generic buffer management for Mesa.) Because of this, I'm pretty sure it won't work with proprietary NVidia drivers, but then again, last time I checked NVidia didn't offer proper screen resolution for VT. - VT switching doesn't seem to work at all. It's worth mentioning that using vo_drm before introduction of VT switcher had an anomaly where user could switch to another VT and input text to it, while video played on top of that VT. However, that isn't the case with drm_egl: I can't switch to other VT during playback like this. This makes me think that it's either a limitation coming from my firmware or from EGL/KMS itself rather than a bug with my code. Nonetheless, I still left (untestable) VT switching code in place, in case it's useful to someone else. - The mode_id, connector_id and device_path should be configurable for power users and people who wish to watch videos on nonprimary screen. Unfortunately I didn't see anything that would allow OpenGL backends to register their own set of options. At the same time, adding them to global namespace is pointless. - A few dozens of lines could be shared with vo_drm (setting up VT switching, most of code behind page flipping). I don't have any strong opinion on this. - Sometimes I get minor visual glitches. I'm not sure if there's a race condition of some sort, unitialized variable (doubtful), or if it's buggy driver. (I'm using integrated Intel HD Graphics 4400 with Mesa) - .config and .control are very minimal. Signed-off-by: wm4 <wm4@nowhere>
* sd_lavc: take care of AVPicture deprecationwm42015-10-231-0/+6
|
* build: remove explicit checks for VPPwm42015-10-171-5/+1
| | | | | This was once done when old versions of libva without VPP had to be supported. Some parts of it were removed earlier already.
* build: bump required libva versionwm42015-10-171-4/+4
| | | | | | | | 0.34 and 0.35 don't have the buffer API, such as vaAcquireBufferHandle. This is only needed for the EGL interop, but why bother staying compatible for such old things (0.36 was released over a year ago). We also can drop some minor compatibility ifdeffery.
* Take care of libavcodec convergence_duration deprecationwm42015-09-291-1/+7
| | | | | | This AVPacket field was a hack against the fact that the duration field was merely an int (too small for things like subtitle durations). Newer libavcodec drops this field and makes duration 64 bit.
* video: remove VDA supportwm42015-09-281-26/+0
| | | | | | | | | VideoToolbox is preferred. Now that FFmpeg released 2.8, there's no reason to support VDA anymore. In fact, we had a bug that made VDA not useable with older FFmpeg versions in some newer mpv releases. VideoToolbox is supported even on slightly older OSX versions, and if not, you still can run mpv without hw decoding.
* vo_opengl: vaapi: add Wayland supportwm42015-09-271-2/+7
| | | | | | Pretty trivial with the new EGL interop. Fixes #478.
* vo_opengl: refactor EGL context information callbackwm42015-09-271-1/+2
| | | | | Move the ugliness from x11egl.c to common.c, so that the ugliness doesn't have to be duplicated in wayland.c.
* vaapi: remove dependency on X11wm42015-09-271-5/+15