path: root/wscript
Commit message (Collapse)AuthorAgeFilesLines
* wscript: Remove code check for cuda hwaccelPhilip Langdale2018-05-101-2/+1
| | | | | | This was there originally to detect too-old versions of ffmpeg. We now only support >= 4.0, so it's not relevant. We just need the dependencies to be present.
* build: make encoding mode non-optionalwm42018-05-031-4/+0
| | | | Makes it easier to not break the build by confusing the ifdeffery.
* vo_gpu: hwdec: Use ffnvcodec to load CUDA symbolsPhilip Langdale2018-04-151-1/+5
| | | | | | The CUDA dynamic loader was broken out of ffmpeg into its own repo and package. This gives us an opportunity to re-use it in mpv and remove our custom loader logic.
* f_lavfi: use new libavfilter iteration APIwm42018-04-031-1/+1
* video: remove libavutil PSEUDOPAL stuffwm42018-04-031-1/+1
| | | | Not needed anymore with newest libavutil.
* lavc_conv: do not allow libavcodec to drop subtitles with broken UTF-8wm42018-03-261-1/+1
| | | | | | | libavcodec normally drops subtitle lines that fail a check for invalid UTF-8 (their check is slightly broken too, by the way). This was always annoying and inconvenient, but now there is a mechanism to prevent it from doing this. Requires newst libavcodec.
* mp_image: replace rude function with less rude FFmpeg upstream functionwm42018-03-031-1/+1
| | | | This is new, thus a dependency bump is required.
* Fix recent FFmpeg deprecationswm42018-02-131-3/+3
| | | | | | | | | This includes codec/muxer/demuxer iteration (different iteration function, registration functions deprecated), and the renaming of AVFormatContext.filename to url (plus making it a malloced string). Libav doesn't have the new API yet, so it will break. I hope they will add the new APIs too.
* build: drop support for SDL1wm42018-02-131-6/+0
| | | | | For some reason it was supported for ao_sdl because we've only used SDL1 API.
* cocoa-cb: initial implementation via opengl-cb APIAkemi2018-02-121-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739, #2392, #2217
* hwdec: detach d3d and d3d9 hwaccel from anglemyfreeer2018-01-251-5/+4
| | | | Fix
* video: change some remaining vo_opengl mentions to vo_gpuAkemi2018-01-201-1/+1
* build: rpi: add missing linker flags to fix buildIlya Tumaykin2018-01-101-1/+1
| | | | | | | | See and Raspberry-pi upstream also adds '-lGLESv2' when EGL is used:
* build: generate version.h before anything elseStefano Pigozzi2018-01-011-0/+5
| | | | | | This seems to fix issues when building on windows where compiling mpv.rc after a `waf clean` resulted in a failure because version.h was not always present
* wscript: remove redundant libraries check for shaderc-staticshinchiro2017-12-241-2/+1
| | | | | | | libshaderc_combined.a already bundles every libs it depends on References:
* wscript: support static linking of shadercMartin Herkt2017-12-241-1/+16
| | | | | These idiots have no idea how to design a library, so we’ll have to work around their bullshit for now.
* build: use a list instead of a string for rpi cflagsScott Zeid2017-12-211-4/+4
| | | | Using a string caused all 4 flags to be passed as one argument, causing the build to fail when trying to include bcm_host.h.
* Restore Libav supportwm42017-12-211-1/+1
| | | | | | | | | | | Libav has been broken due to the hwdec changes. This was always a temporary situation (depended on pending patches to be merged), although it took a bit longer. This also restores the travis config. One code change is needed in vd_lavc.c, because it checks the AV_PIX_FMT for videotoolbox (as opposed to the mpv format identifier), which is not available in Libav. Add an ifdef; the affected code is for a deprecated option anyway.
* vo_mediacodec_embed: implement hwcontextAman Gupta2017-12-201-1/+1
| | | | Fixes vo_mediacodec_embed, which was broken in 80359c6615658f2784
* vd_lavc: use libavcodec metadata for hardware decoder wrapperswm42017-12-151-1/+1
| | | | | This removes the need to keep an explicit list and to attempt to parse codec names. Needs latest FFmpeg git.
* Remove support for ffmpeg-mpvRostislav Pehlivanov2017-12-051-13/+4
* build: remove nanosleep() checkwm42017-12-021-4/+0
| | | | Also guaranteed by POSIX.
* build: remove termios checkwm42017-12-021-4/+0
| | | | Also should be fully covered by POSIX.
* build: remove POSIX/sysv shared memory testwm42017-12-021-5/+0
| | | | | | vo_x11 and vo_xv need this. According to the Linux manpage, all involved functions are POSIX-2001 anyway. (I just assumed they were not, because they're mostly System V UNIX legacy garbage.)
* build: bump required ffmpeg versionwm42017-11-301-1/+1
| | | | For the vp9 fix (at least if upstream ffmpeg is used).
* build: accept ffmpeg git by defaultwm42017-11-291-1/+0
| | | | VP9 is still broken due to a difference with Libav, though.
* ao_alsa: change license to LGPLwm42017-11-231-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | Looks like this is covered by LGPL relicensing agreements now. Notes about contributors who could not be reached or who didn't agree: Commit 7fccb6486e has tons of mp_msg changes look like they are not copyrightable (even if they were, all mp_msg calls were rewritten in mpv times again). The additional play() change looks suspicious, but the function was rewritten several times anyway (first time after that commit in 4f40ec312). Commit 89ed1748ae was rewritten in commit 325311af3 and then again several times after that. Basically all this code is unnecessary in modern mpv and has been removed. No code survived from the following commits: 4d31c3c53, 61ecf838f2, d38968bd, 4deb67c3f. At least two cosmetic typo fixes are not considered as well. Commit 22bb046ad is reverted (this wasn't a valid warning anyway, just a C++-ism icc applied to C). Using the constants is nicer, but at least I don't have to decide whether that change was copyrightable.
* demux_mkv: remove unnecessary parsing for vp9wm42017-11-171-1/+1
| | | | | | | We can finally get rid of this crap. Depends on a ffmpeg-mpv change. Always worked with Libav (ever since they fixed it properly).
* build: enable libarchive by defaultwm42017-11-121-1/+0
| | | | Or libcve, as the vlc developers call it.
* vo_gpu: d3d11: enhance cache invalidationJames Ross-Gowan2017-11-071-1/+1
| | | | | | | | The shader cache in ra_d3d11 caches the result of shaderc, crossc and the D3DCompiler DLL, so it should be invalidated when any of those components are updated. This should make the cache more reliable, which makes it safer to enable gpu-shader-cache-dir. Shader compilation is slow with D3D11, so gpu-shader-cache-dir is highly necessary
* vo_gpu: d3d11: initial implementationJames Ross-Gowan2017-11-071-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a new RA/vo_gpu backend that uses Direct3D 11. The GLSL generated by vo_gpu is cross-compiled to HLSL with SPIRV-Cross. What works: - All of mpv's internal shaders should work, including compute shaders. - Some external shaders have been tested and work, including RAVU and adaptive-sharpen. - Non-dumb mode works, even on very old hardware. Most features work at feature level 9_3 and all features work at feature level 10_0. Some features also work at feature level 9_1 and 9_2, but without high-bit- depth FBOs, it's not very useful. (Hardware this old is probably not fast enough for advanced features anyway.) Note: This is more compatible than ANGLE, which requires 9_3 to work at all (GLES 2.0,) and 10_1 for non-dumb-mode (GLES 3.0.) - Hardware decoding with D3D11VA, including decoding of 10-bit formats without truncation to 8-bit. What doesn't work / can be improved: - PBO upload and direct rendering does not work yet. Direct rendering requires persistent-mapped PBOs because the decoder needs to be able to read data from images that have already been decoded and uploaded. Unfortunately, it seems like persistent-mapped PBOs are fundamentally incompatible with D3D11, which requires all resources to use driver- managed memory and requires memory to be unmapped (and hence pointers to be invalidated) when a resource is used in a draw or copy operation. However it might be possible to use D3D11's limited multithreading capabilities to emulate some features of PBOs, like asynchronous texture uploading. - The blit() and clear() operations don't have equivalents in the D3D11 API that handle all cases, so in most cases, they have to be emulated with a shader. This is currently done inside ra_d3d11, but ideally it would be done in generic code, so it can take advantage of mpv's shader generation utilities. - SPIRV-Cross is used through a NIH C-compatible wrapper library, since it does not expose a C interface itself. The library is available here: - The D3D11 context could be made to support more modern DXGI features in future. For example, it should be possible to add support for high-bit-depth and HDR output with DXGI 1.5/1.6.
* wscript: use pkg-config for vulkan checkMartin Herkt2017-11-031-1/+1
* build: fix cuda testwm42017-11-021-1/+1
* build: garbage => upstreamwm42017-11-011-2/+2
| | | | | "garbage" is considered offensive. The result will still be pretty bad though (currently build failures).
* build: make it easier to force FFmpeg upstreamwm42017-11-011-6/+7
| | | | | | | | | | | Apparently some people want this. Actually making it compile is still their problem, though, and I expect that build with FFmpeg upstream will occasionally be broken (as it is right now). This is because mpv also relies on API provided by Libav, and if FFmpeg hasn't merged that yet, it's not our problem - we provide a version of FFmpeg upstream with those changes merged, and it's called ffmpeg-mpv. Also adjust the README which still talked about FFmpeg releases.
* Bump libav* API usewm42017-10-301-90/+31
| | | | (Not tested on Windows and OSX.)
* build: require our own ffmpeg repowm42017-10-271-3/+11
| | | | | | | | | This is required now. Can't have FFmpeg upstream randomly break us and then not fix it (like this recent EOF issue). Upstream FFmpeg is of course still supported, but you will need to edit the build scripts. Official support is only with the master branch of our own repo.
* vd_lavc: use avcodec_fill_hw_frames_parameters() APIwm42017-10-271-0/+6
| | | | | | | | This removes the need for codec- and API-specific knowledge in the libavcodec hardware acceleration API user. For mpv, this removes the need for vd_lavc_hwdec.pixfmt_map and a few other things. (For now, we still keep the "old" parts for the sake of supporting older Libav, and FFgarbage.)
* Add DRM_PRIME Format Handling and Display for RockChip MPP decodersLionel CHAZALLON2017-10-231-0/+5
| | | | | | | | | | | This commit allows to use the AV_PIX_FMT_DRM_PRIME newly introduced format in ffmpeg that allows decoders to provide an AVDRMFrameDescriptor struct. That struct holds dmabuf fds and information allowing zerocopy rendering using KMS / DRM Atomic. This has been tested on RockChip ROCK64 device.
* build: make LGPL mode final (via --enable-gpl)wm42017-10-101-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rename --enable-preliminary-lgpl2 to --enable-gpl. This concludes the relicensing. Some things are still to do (relicensing some still-GPL optional code), but we consider the code included by --enable-gpl to be fully relicensed. The relicensing was performed by asking every known author for permission for relicensing it to LGPL version 2.1 "or later". If an author could not be contacted or permission could not be obtained, and the contribution was considered relevant for copyright purposes, the affected code was either excluded from LGPL mode (not built), or removed or rewritten. This is the standard in open source relicensing processes. Keep in mind that using LGPL mode is still on the user's own risk. Even though I claim that the relicensing was pretty clean and thorough (measured on the standards of the open source community¹), and I followed the advice of some actual experts, there is still a residual uncertainty due to the fact that I'm not an all-knowing entity (authors could have taken someone else's code and pretend it's their own) nor a lawyer (meaning I might lack associated authority or expertise), and the fact that the judicial system is far from deterministic. The relicensing was performed merely to the best of my knowledge. I reject all responsibility outside of that. This commit also cleans up the "Copyright" file to reflect the finalized relicensing process. ¹ Not to imply that the standards of commercial companies are much higher. Some major tech companies get away with stuff I would not consider clean. See #2033.
* vo_gpu: android: fix gpu contextAman Gupta2017-10-091-0/+1
* vo_gpu: add android opengl backendAman Gupta2017-10-091-2/+5
| | | | | | | | | | At the moment, rendering on Android requires ``--vo=opengl-cb`` and a lot of java<->c++ bridging code to receive the receive and react to the render callback in java. Performance also suffers with opengl-cb, due to the overhead of context switching in JNI. With this patch, Android can render using ``--vo=gpu --gpu-context=android`` (after setting ``--wid`` to point to an android.view.Surface on-screen).
* build: switch preliminary LGPL mode from v3 to v2.1wm42017-10-051-3/+3
| | | | | | | | | | | iive agreed to relicense things that are still in mpv to LGPLv2.1. So change the licenses of the affected files, and rename the configure switch for LGPL mode to --enable-preliminary-lgpl2. (The "preliminary" part will probably be removed from the configure switch soon as well.) Also player/main.c hasn't had GPL parts since a few commits ago.
* wayland_common: rewrite from scratchRostislav Pehlivanov2017-10-031-0/+9
| | | | | | | | | | | | The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
* vaapi: change license to LGPLwm42017-09-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | Originally mpv vaapi support was based on the MPlayer-vaapi patches. These were never merged in upstream MPlayer. The license headers indicated they were GPL-only. Although the actual author agreed to relicensing, the company employing him to write this code did not, so the original code is unusable to us. Fortunately, vaapi support was refactored and rewritten several times, meaning little code is actually left. The previous commits removed or moved that to GPL-only code. Namely, vo_vaapi.c remains GPL-only. The other code went away or became unnecessary mainly because libavcodec itself gained the ability to manage the hw decoder, and libavutil provides code to manage vaapi surfaces. We also changed to mainly using EGL interop, making any of the old rendering code unnecessary. hwdec_vaglx.c is still GPL. It's possibly relicensable, because much of it was changed, but I'm not too sure and further investigation would be required. Also, this has been disabled by default for a while now, so bothering with this is a waste of time. This commit simply disables it at compile time as well in LGPL mode.
* video: remove old videotoolbox supportwm42017-09-261-15/+1
| | | | | Like as in previous commits, you need a very recent FFmpeg (probably git master).
* wscript: remove redundant checkwm42017-09-261-6/+0
| | | | We're not using this function directly.
* video: drop old D3D11/DXVA2 supportwm42017-09-261-11/+1
| | | | | | | | | Now you need FFmpeg git, or something. This also gets rid of the last real use of gpu_memcpy(). libavutil does that itself. (vaapi.c still used it, but it was essentially unused, because the code path isn't really in use anymore. It wasn't even included due to the d3d-hwaccel dependency in wscript.)
* vo_gpu: vulkan: generalize SPIR-V compilerNiklas Haas2017-09-261-0/+4
| | | | | | | | | | | | | | In addition to the built-in nvidia compiler, we now also support a backend based on libshaderc. shaderc is sort of like glslang except it has a C API and is available as a dynamic library. The generated SPIR-V is now cached alongside the VkPipeline in the cached_program. We use a special cache header to ensure validity of this cache before passing it blindly to the vulkan implementation, since passing invalid SPIR-V can cause all sorts of nasty things. It's also designed to self-invalidate if the compiler gets better, by offering a catch-all `int compiler_version` that implementations can use as a cache invalidation marker.
* vo_gpu: vulkan: initial implementationNiklas Haas2017-09-261-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This time based on ra/vo_gpu. 2017 is the year of the vulkan desktop! Current problems / limitations / improvement opportunities: 1. The swapchain/flipping code violates the vulkan spec, by assuming that the presentation queue will be bounded (in cases where rendering is significantly faster than vsync). But apparently, there's simply no better way to do this right now, to the point where even the stupid cube.c examples from LunarG etc. do it wrong. (cf. 2. The memory allocator could be improved. (This is a universal constant) 3. Could explore using push descriptors instead of descriptor sets, especially since we expect to switch descriptors semi-often for some passes (like interpolation). Probably won't make a difference, but the synchronization overhead might be a factor. Who knows. 4. Parallelism across frames / async transfer is not well-defined, we either need to use a better semaphore / command buffer strategy or a resource pooling layer to safely handle cross-frame parallelism. (That said, I gave resource pooling a try and was not happy with the result at all - so I'm still exploring the semaphore strategy) 5. We aggressively use pipeline barriers where events would offer a much more fine-grained synchronization mechanism. As a result of this, we might be suffering from GPU bubbles due to too-short dependencies on objects. (That said, I'm also exploring the use of semaphores as a an ordering tactic which would allow cross-frame time slicing in theory) Some minor changes to the vo_gpu and infrastructure, but nothing consequential. NOTE: For safety, all use of asynchronous commands / multiple command pools is currently disabled completely. There are some left-over relics of this in the code (e.g. the distinction between dev_poll and pool_poll), but that is kept in place mostly because this will be re-extended in the future (vulkan rev 2). The queue count is also currently capped to 1, because of the lack of cross-frame semaphores means we need the implicit synchronization from the same-queue semantics to guarantee a correct result.
* android: posix_spawn(p) replacementsfan52017-09-221-2/+12
| | | | Signed-off-by: wm4 <wm4@nowhere>
* build: make vo_gpu + infrastructure non-optionalwm42017-09-221-8/+3
| | | | | Also readd the the error message for when no GL backends are found (why was this removed?).
* vo_opengl: refactor into vo_gpuNiklas Haas2017-09-211-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is done in several steps: 1. refactor MPGLContext -> struct ra_ctx 2. move GL-specific stuff in vo_opengl into opengl/context.c 3. generalize context creation to support other APIs, and add --gpu-api 4. rename all of the --opengl- options that are no longer opengl-specific 5. move all of the stuff from opengl/* that isn't GL-specific into gpu/ (note: opengl/gl_utils.h became opengl/utils.h) 6. rename vo_opengl to vo_gpu 7. to handle window screenshots, the short-term approach was to just add it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to ra itself (and vo_gpu altered to compensate), but this was a stop-gap measure to prevent this commit from getting too big 8. move ra->fns->flush to ra_gl_ctx instead 9. some other minor changes that I've probably already forgotten Note: This is one half of a major refactor, the other half of which is provided by rossy's following commit. This commit enables support for all linux platforms, while his version enables support for all non-linux platforms. Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the --opengl- options like --opengl-early-flush, --opengl-finish etc. Should be a strict superset of the old functionality. Disclaimer: Since I have no way of compiling mpv on all platforms, some of these ports were done blindly. Specifically, the blind ports included context_mali_fbdev.c and context_rpi.c. Since they're both based on egl_helpers, the port should have gone smoothly without any major changes required. But if somebody complains about a compile error on those platforms (assuming anybody actually uses them), you know where to complain.
* build: add preliminary LGPL modewm42017-09-211-10/+31
| | | | | | | See "Copyright" file for caveats. This changes the remaining "almost LGPL" files to LGPL, because we think that the conditions the author set for these was finally fulfilled.
* audio: make libaf derived code optionalwm42017-09-211-0/+4
| | | | | | | | | | | | | | | This code could not be relicensed. The intention was to write new filter code (which could handle both audio and video), but that's a bit of work. Write some code that can do audio conversion (resampling, downmixing, etc.) without the old audio filter chain code in order to speed up the LGPL relicensing. If you build with --disable-libaf, nothing in audio/filter/* is compiled in. It breaks a few features, such as --volume, --af, pitch correction on speed changes, replaygain. Most likely this adds some bugs, even if --disable-libaf is not used. (How the fuck does EOF notification work again anyway?)
* build: use unified dependency expressions instead of weird fieldswm42017-09-181-92/+81
| | | | | | | | | | | | | | | | Instead of "deps", "deps_neg", and "deps_any" fields, just have a single "deps" field, which changes from an array to a string. The string is now an expression, which can contain the operators &&, ||, !, and allows grouping with ( ). It's probably overkill. If it gets a maintenance burden, we can switch to specifiying the dep expressions as ASTs (or maybe eval()-able Python expressions), and we could simplify the code that determines the reason why a dependency is not fulfilled. The latter involves a complicated conversion of the expression AST to DNF. The parser is actually pretty simple, and pretty much follows:
* build: remove duplicate android option after 72a8120daIlya Tumaykin2017-09-171-4/+0
| | | | | | | | The first one (line 140) comes from 69650851f8 and is the correct one. The second one (line 731) comes from 72a8120daa and slipped in with the revert commit. Remove the second one.
* video: add metadata handling for spherical videowm42017-08-211-0/+6
| | | | | | | | | | | | | | This adds handling of spherical video metadata: retrieving it from demux_lavf and demux_mkv, passing it through filters, and adjusting it with vf_format. This does not include support for rendering this type of video. We don't expect we need/want to support the other projection types like cube maps, so we don't include that for now. They can be added later as needed. Also raise the maximum sizes of stringified image params, since they can get really long.
* Revert "x11: drop xscrnsaver use"Martin Herkt2017-08-201-0/+1
| | | | | | | | | | | | | | This broke screensaver/powersave inhibition with at least KDE and LXDE. This is a release blocker. Since fdo, KDE and GNOME idiots seem to be unable to reach a consensus on a simple protocol, this seems unlikely to get fixed upstream this year, so revert this change. Fixes #4752. Breaks #4706 but I don’t give a damn. This reverts commit 3f75b3c3439241c209349908fa190c0382e44f05.
* Revert "build: rpi: rely on pkgconfig for compiler flags"wm42017-08-151-1/+21
| | | | | | | | | This reverts commit ea40fa36eef15384b4c0218fb102f92f5cd1cdff. This caused strange runtime failure on Raspbian (when running mpv, vc_dispmanx_display_open() returned 0, while other dispmanx using programs were fine). The problem must have been something about the compiler flags, maybe linking order or set of include paths.
* x11: drop xscrnsaver usewm42017-08-081-1/+0
| | | | | | | | | | | It's an ancient X11 protocol extension that apparently nobody uses anymore (desktop environments in particular have replaced it with equally bad protocols that require tons of dependencies). Users keep complaining about it being a required dependency. The impact is likely minimal to none. Fixes #4706 and other annoying people.
* build: fix dependencies for Cygwin environmentfeixm12017-08-081-1/+1
| | | | | This replaces previous commit with same intentions. This time, with proper formating (no tabs in code).
* wscript: fix build of videotoolbox hwaccel for iOSAman Gupta2017-08-051-2/+2
* build: re-add and re-structurize the glob() checksJan Ekström2017-08-051-0/+10
| | | | | | | | * If we have glob() supported, we have `HAVE_GLOB = 1'. * If we have specifically POSIX glob(), we have `HAVE_GLOB_POSIX = 1`. * If we have specifically Win32 glob(), we have `HAVE_GLOB_WIN32 = 1`
* build: move Android environment check to main dependenciesJan Ekström2017-08-051-4/+4
| | | | | | Additionally change the description to better match what Android is, which is an "environment". The original positioning of this check was unfortunate.
* vd_lavc: decode embedded ICC profilesNiklas Haas2017-08-031-0/+6
| | | | | | | | | Since these need to be refcounted, we throw them directly into struct mp_image instead of being part of mp_colorspace. Even though they would semantically make more sense in mp_colorspace, having them there is really awkward because mp_colorspace is passed around and stored a lot, and this way their lifetime is exactly tied to the lifetime of the mp_image associated with it.
* d3d: make DXVA2 support optionalwm42017-06-301-5/+23
| | | | | | | | | | | | This partially reverts the change from a longer time ago to always build DXVA2 and D3D11VA together. To make it simpler, we change the following: - building with ANGLE headers is now required to build D3D hwaccels - if DXVA2 is enabled, D3D11VA is still forcibly built - the CLI vo_opengl ANGLE backend is now under --egl-angle-win32 This is done to reduce the dependency mess slightly.
* build: allow --disable-zlibwm42017-06-291-1/+1
| | | | | Since strictly speaking, it's still optional. It's just very much recommended not to disable it.
* Universal Windows Plaform (UWP) supportPedro Pombeiro2017-06-291-1/+10
| | | | | | | | libmpv only. Some things are still missing. Heavily reworked. Signed-off-by: wm4 <wm4@nowhere>
* build: change how some OS specific source files are selectedwm42017-06-291-10/+23
| | | | | | | | | | | | | | | | | | In a bunch of cases, we emulate highly platform specific APIs on a higher level across all OSes, such as IPC, terminal, subprocess handling, and more. We have source files for each OS, and they implement all the same mpv internal API. Selecting which source file to use on an OS can be tricky, because there is partially overlapping and emulated APIs (consider Cygwin on Windows). Add a pick_first_matching_dep() function to make this slightly easier and more structured. Also add dummy backends in some cases, to deal with APIs not being available. Clarify the Windows dependency identifiers, as these are the most confusing.
* build: replace glob() check and assume it's always in POSIXwm42017-06-291-6/+2
| | | | | POSIX requires glob(), so no need to check for it. Together with the fact that we can emulate glob() on Windows, glob() is always available.
* build: remove unnecessary dlopen checkwm42017-06-291-5/+0
| | | | Probably became unnecessary with the vf_dlopen removal.
* build: pick up new libavcodec D3D hwaccel APIwm42017-06-271-4/+8
| | | | | This was enabled for Libav already. The patches got merged into FFmpeg now.
* build: disable ancient V4L TV support by defaultwm42017-06-251-1/+4
* build: remove Linux DVB test fragmentwm42017-06-221-1/+1
| | | | | | | | | | | | Most of the DVB test fragment was added in 2e399f39 by someone who wasn't asked for LGPL relicensing permission. Thus remove it. (For some weird reason, the configure check wasn't even for the later added actual DVB code.) Since DVB is disabled by default, this isn't too bad. But if someone enables it, and the system doesn't support it, he will receive a weird compilation error. That has to be good enough, until maybe someone adds a new check.
* Revert "osdep: NetBSD pthread_setname_np()"wm42017-06-221-8/+1
| | | | | | | | | | This reverts commit 2e81698d2809836d4cd7f754a78598e7bdf96c0b. Seems like this was a patch applied from someone who can't agree to LGPL relicensing (see previous commit), with the author field not properly set. This is not so important anyway, so just revert it.
* build: simplify OSS checks and remove changes by "bugmen0t"wm42017-06-221-36/+3
| | | | | | | | | | | | | | | | | | The user bugmen0t was apparently a shared github account with publicly available login. Thus, we can't get LGPL relicensing permission from the people who used this account. To relicense successfully, we have to remove all their changes. This commit should remove 20d1fc13, f26fb009, defbe48d. It also should remove whatever test fragments were copied from the ancient configure, as well as some configure logic (potentially that device path stuff). I think this change still preserves the most important use-cases of OSS: BSDs, and the Linux OSS emulation (the latter for testing only). According to an OSS user, the 4front checks were probably broken anyway. The SunAudio stuff was probably for (Open)Solaris, which is dead. ao_oss.c itself will remain GPL, and still contains bugmen0t changes.
* vd: use ST.2086 / HDR10 MaxCLL in addition to mastering metadataNiklas Haas2017-06-181-0/+6
| | | | | | | | | | | | | MaxCLL is the more authoritative source for the metadata we are interested in. The use of mastering metadata is sort of a hack anyway, since there's no clearly-defined relationship between the mastering peak brightness and the actual content. (Unlike MaxCLL, which is an explicit relationship) Also move the parameter fixing to `fix_image_params` I don't know if the avutil check is strictly necessary but I've included it anyway to be on the safe side.
* vf_dlopen: remove this filterwm42017-06-181-6/+0
| | | | | | | | | | | | | | | | It was an attempt to move some MPlayer filters (which were removed from mpv) to external, loadable filters. That worked well, but then the MPlayer filters were ported to libavfilter (independently), so they're available again. Also there is a more widely supported and more advanced loadable filter system supported by mpv: vapoursynth. In conclusion, vf_dlopen is not useful anymore, confusing, and requires quite a bit of code (and probably wouldn't survive the rewrite of the mpv video filter chain, which has to come at some point). It has some implicit dependencies on internal conventions, like possibly the format names dropped in the previous commit. We also deprecated it last release. Drop it.
* js: wscript: use pkgconfig for mujs (recently added .pc and 1.0.0 tag)Avi Halachmi (:avih)2017-06-161-1/+1
* js: add javascript scripting support using MuJSAvi Halachmi (:avih)2017-06-141-0/+4
| | | | | | | | | | | | | | | Implements JS with almost identical API to the Lua support. Key differences from Lua: - The global mp, mp.msg and mp.utils are always available. - Instead of returning x, error, return x and expose mp.last_error(). - Timers are JS standard set/clear Timeout/Interval. - Supports CommonJS modules/require. - Added at mp.utils: getenv, read_file, write_file and few more. - Global print and dump (expand objects) functions. - mp.options currently not supported. See DOCS/man/javascript.rst for more details.
* d3d: add support for new libavcodec hwaccel APIwm42017-06-081-0/+8
| | | | | | Unfortunately quite a mess, in particular due to the need to have some compatibility with the old API. (The old API will be supported only in short term.)
* build: enable cplugins by defaultwm42017-06-071-1/+1
| | | | | | | | | | There's probably no reason to keep this disabled. The -rdynamic (and the approach we use) is probably a bit scary, but should not break anything. Just to be sure I'm hard-disabling this on win32 anyway. We know it can't work there in its current form. Fixes #4491.
* videotoolbox: support new libavcodec APIwm42017-05-241-3/+19
| | | | | | | | | | | The new API has literally no advantages (other than that we can drop mp_vt_download_image and other things later), but it's sort-of uniform with the other hwaccels. "--videotoolbox-format=no" is not supported with the new API, because it doesn't "fit in". Probably could be added later again. The iOS code change is untested (no way to test).
* vo_opengl: drop TLS usagewm42017-05-111-8/+0
| | | | | | | | | | | TLS is a headache. We should avoid it if we can. The involved mechanism is unfortunately entangled with the unfortunate libmpv API for returning pointers to host API objects. This has to be kept until we change the API somehow. Practically untested out of pure laziness. I'm sure I'll get a bunch of reports if it's broken.
* dvb: disable by defaultwm42017-05-111-0/+1
| | | | | | | | It fails building with some older kernel headers, and the current test does not auto-disable it in these cases. Since DVB isn't going to be used by many people, I think disabling it by default is reasonable.
* stream_smb: disable by default, mark as GPLv3wm42017-05-111-1/+2
| | | | | | | | | | It seems libsmbclient has been GPLv3 for years. Also, it's certainly not LGPL (unlike some of its support libs like talloc). Thus, mpv built with Samba support is GPLv3. Disable it by default, so we don't have to go through the trouble to indicate the correct license in our output, and we don't trick people into distributing stuff under the wrong license.
* 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]: [2]:
* 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 & 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 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/ 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 <>
* 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 <>
* 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 <>
* 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 <>)
* 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:
* 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
| | | | | | | | | | | | | There are at least 2 ways of using VAAPI without X11 (Wayland, DRM). Remove the X11 requirement from the decoder part and the EGL interop. This will be used by a following commit, which adds Wayland support. The worst about this is the decoder part, which includes a bad hack for using the decoder without any VO interop (also known as "vaapi-copy" mode). Separate the X11 parts so that they're self-contained. For the EGL interop code we do something similar (it's kept slightly simpler, because it essentially only has to translate between our silly MPGetNativeDisplay abstraction and the vaGetDisplay...() call).
* vo_opengl: vaapi: redo how EGL extensions are loadedwm42015-09-271-5/+0
| | | | | | | It looks like my hope that we can unconditionally include EGL headers in the OpenGL code is not coming true, because OSX does not support EGL at all. So I prefer loading the VAAPI EGL/GL specific extensions manually, because it's less of a mess. Partially reverts commit d47dff3f.
* wscript: add missing entry to help outputwm42015-09-251-1/+1
| | | | Fixes #2344.
* vaapi: use GPU memcpy for reading back from HW surfacewm42015-09-251-1/+1
| | | | | | | | | This makes it much faster if the surface is really mapped from GPU memory. It's slightly slower than system memcpy if used on system memory. We don't really know definitely in which type of memory it's located, so we use the GPU memcpy in all cases. Fixes #2317.
* video: refactor GPU memcpy usagewm42015-09-251-0/+5
| | | | | | | | | | | | | | | | | Make the GPU memcpy from the dxva2 code generally useful to other parts of the player. We need to check at configure time whether SSE intrinsics work at all. (At least in this form, they won't work on clang, for example. It also won't work on non-x86.) Introduce a mp_image_copy_gpu(), and make the dxva2 code use it. Do some awkward stuff to share the existing code used by mp_image_copy(). I'm hoping that FFmpeg will sooner or later provide a function like this, so we can remove most of this again. (There is a patch, bit it's stuck in limbo since forever.) All this is used by the following commit.
* vo_rpi, wayland: fix buildwm42015-09-251-5/+5
| | | | | | Broken by commit d47dff3f. If something is going to include EGL.h, header_fixes.h has to know. This definitely affected vo_rpi, and probably affects wayland builds (with x11egl didabled) as well.
* vo_opengl: support new VAAPI EGL interopwm42015-09-251-0/+5
| | | | | | | | | | | | | | | | | | | | | | | Should work much better than the old GLX interop code. Requires Mesa 11, and explicitly selecting the X11 EGL backend with: --vo=opengl:backend=x11egl Should it turn out that the new interop works well, we will try to autodetect EGL by default. This code still uses some bad assumptions, like expecting surfaces to be in NV12. (This is probably ok, because virtually all HW will use this format. But we should at least check this on init or so, instead of failing to render an image if our assumption doesn't hold up.) This repo was a lot of help: The kodi code was also helpful (the magic FourCC it uses for EGL_LINUX_DRM_FOURCC_EXT are nowhere documented, and EGL_IMAGE_INTERNAL_FORMAT_EXT as used in ffvademo does not actually exist). (This is the 3rd VAAPI GL interop that was implemented in this player.)
* vo_opengl: add mechanism to retrieve Display from EGL contextwm42015-09-251-1/+5
| | | | | | | | | | The VAAPI EGL interop code will need access to the X11 Display. While GLX could return it from the current GLX context, EGL has no such mechanism. (At least no standard one supported by all implementations.) So mpv makes up such a mechanism. For internal purposes, this is very rather awkward solution, but it's needed for libmpv anyway.
* vo_opengl: load certain EGL extensions needed for VAAPI EGL interopwm42015-09-251-0/+5
| | | | | | | | | These extensions use a bunch of EGL types, so we need to include the EGL headers in common.h to use our GL function loader with this. In the future, we should probably require presence of the EGL headers to reduce the hacks. This might be not so simple at least with OSX, so for now this has to do.
* vo_opengl: enable X11 EGL backend by defaultwm42015-09-241-1/+0
| | | | | Originally, this was disabled, because it was useless and I was afraid it could possibly break autodetection and proper fallback.
* build: allow disabling vapoursynth completelywm42015-09-221-7/+8
| | | | | | | | | | | It's possible to build vf_vapoursynth with either the Python or Lua backend (or both or none). The check for the vapoursynth core itself was hidden away and couldn't be disabled, which would link mpv with vapoursynth even if all backends were disabled. Rearrange the checks so that the core will be disabled if no backend is found (or both are disabled). This duplicates the check for vapoursynth.pc, but since it's trivial, this is not that bad.
* video: do not use deprecated libavutil pixdesc fieldswm42015-09-101-0/+6
| | | | | | These were normalized and are saner now. We want to use the new fields, and also get rid of the deprecation warnings, so use them. There's no release yet which uses these, so some ifdeffery is unfortunately needed.
* audio/filter: remove af_bs2b toowm42015-09-041-4/+0
| | | | | | | Some users still use this filter, so the filter was going to be kept. But I overlooked that libavfilter provides this filter. Remove the redundant wrapper from mpv. Something like --af=lavfi=bs2b should work and give exactly the same results.
* audio/filter: remove some useless filterswm42015-09-031-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | All of these filters are considered not useful anymore by us. Some have replacements in libavfilter (useable through af_lavfi). af_center, af_extrastereo, af_karaoke, af_sinesuppress, af_sub, af_surround, af_sweep: pretty simple and useless filters which probably nobody ever wants. af_ladspa: has a replacement in libavfilter. af_hrtf: the algorithm doesn't work properly on most sources, and the implementation was buggy and complicated. (The filter was inherited from MPlayer; but even in mpv times we had to apply fixes that fixed major issues with added noise.) There is a ladspa filter if you still want to use it. af_export: I'm not even sure what this is supposed to do. Possibly it was meant for GUIs rendering audio visualizations, but it couldn't really work well. For example, the size of the audio depended on the samplerate (fixed number of samples only), and it couldn't retrieve the complete audio, only fragments. If this is really needed for GUIs, mpv should add native visualization, or a proper API for it.
* Revert "build: workaround for broken waf crap"Stefano Pigozzi2015-08-191-7/+1
| | | | This reverts commit 1b7883a3e57a39edfd39732efde5cd02417e3ebd.
* build: workaround for broken waf crapwm42015-08-181-1/+7
| | | | | Even though the rpi check fails, it'll define "HAVE_RPI 1" in config.h. Why? Who knows...
* vo_rpi: use EGL to render subtitleswm42015-08-181-11/+5
| | | | | | | | Slightly faster than using the dispmanx mess (perhaps to a large amount due to the rather stupid C-only unoptimized ASS->RGBA blending code). Do this by reusing vo_opengl's subtitle renderer, and vo_opengl's RPI backend.
* stream: libarchive wrapper for reading compressed archiveswm42015-08-171-0/+5
| | | | | | | | | | | | | | | | | | | | This works similar to the existing .rar support, but uses libarchive. libarchive supports a number of formats, including zip and (most of) rar. Unfortunately, seeking does not work too well. Most libarchive readers do not support seeking, so it's emulated by skipping data until the target position. On backwards seek, the file is reopened. This works fine on a local machine (and if the file is not too large), but will perform not so well over network connection. This is disabled by default for now. One reason is that we try libarchive on every file we open, before trying libavformat, and I'm not sure if I trust libarchive that much yet. Another reason is that this breaks multivolume rar support. While libarchive supports seeking in rar, and (probably) supports multivolume archive, our support of libarchive (probably) does not. I don't care about multivolume rar, but vocal users do.
* video: remove old vdpau hwaccel API usagewm42015-08-101-8/+0
| | | | | | | While the "old" libavcodec vdpau API is not deprecated (only the very- old API is), it's still relatively complicated code that badly duplicates the much simpler newer vdpau code. It exists only for the sake of older FFmpeg releases; get rid of it.
* build: fix build with --disable-tv --enable-pvrwm42015-08-061-0/+1
| | | | | These share some code (frequencies.c at least), so linking was failing. Fix by making pvr depend on tv.
* build: fix conditions for building gl_hwdec_vda.cwm42015-08-051-1/+1
| | | | | This contains code for the VT and VDA case, thus must be build if at least 1 of them is enabled.
* hwdec: add VideoToolbox supportSebastien Zwickert2015-08-051-0/+19
| | | | | | | | VDA is being deprecated in OS X 10.11 so this is needed to keep hwdec working. The code needs libavcodec support which was added recently (to FFmpeg git, libav doesn't support it). Signed-off-by: Stefano Pigozzi <>
* build: make charset detectors dependent on iconv and group themwm42015-08-021-4/+11
* build: fix version.h creationStefano Pigozzi2015-07-121-4/+10
| | | | | Previous code did not retrigger a relink when version.h changed since it didn't use a waf task.
* vaapi: drop compatibility crap and vo_vaapi deinterlacerwm42015-07-081-1/+1
| | | | | | | | | | | Drop libva versions below 0.34.0. These are ancient, so I don't care. Drop the vo_vaapi deinterlacer as well. With 0.34.0, VPP is always available, and deinterlacing is done with vf_vavpp. The vaCreateSurfaces() function changes its signature - actually it did in 0.34.0 or so, and the <va/va_compat.h> defined a macro to make it use the old signature.
* av_log: print FFmpeg versionwm42015-07-031-0/+6
| | | | | The individual library versionsd are pretty useless. This will actually tell us at least the git hash or git tag of the FFmpeg build.
* build: always regenerate version hashwm42015-06-301-0/+7
| | | | | | | | | Until now, it only used the hash from the previous configure run, instead of trying to get the latest hash. The "old" build system did this correctly - we just have to use the existing logic in Since waf supports separate build dirs, extend with an argument for setting the path of version.h.
* test: update cmocka version to 1.0Stefano Pigozzi2015-06-131-1/+1
* vdpau: add support for the "new" libavcodec vdpau APIwm42015-05-281-0/+8
| | | | | | | | | Yet another of these dozens of hwaccel changes. This time, libavcodec provides utility functions, which initialize the vdpau decoder and map codec profiles. So a lot of work the API user had to do falls away. This also will give us support for high bit depth profiles, and possibly HEVC once libavcodec supports it.
* vda: add support for nv12 image formatsStefano Pigozzi2015-05-131-0/+7
| | | | | | | | | The hardware always decodes to nv12 so using this image format causes less cpu usage than uyvy (which we are currently using, since Apple examples and other free software use that). The reduction in cpu usage can add up to quite a bit, especially for 4k or high fps video. This needs an accompaning commit in libavcodec.
* cocoa: always compile OSX application code with cocoawm42015-05-021-6/+0
| | | | | | | | | | | | | | This unbreaks compiling command line player and libmpv at the same time. The problem was that doing so silently disabled the OSX application thing - but the command line player can not use the vo_opengl Cocoa backend without it. The OSX application code is basically dead in libmpv, but it's not that much code anyway. If you want a mpv binary that does not create an OSX application singleton (and creates a menu etc.), you must disable cocoa completely, as cocoa can't be used anyway in this case.
* vo_drm: disable VT switcher for non-Linux systemsMarcin Kurczewski2015-04-191-0/+6
* vo_drm: add KMS/DRM renderer supportMarcin Kurczewski2015-04-161-0/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vaapi: fight with Intel's broken video decoding GL interopwm42015-04-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Use texture-from-pixmap instead of vaapi's "native" GLX support. Apparently the latter is unused by other projects. Possibly it's broken due that, and Intel's inability to provide anything non-broken in relation to video. The new code basically uses the X11 output method on a in-memory pixmap, and maps this pixmap as texture using standard GLX mechanisms. This requires a lot of X11 and GLX boilerplate, so the code grows. (I don't know why libva's GLX interop doesn't just do the same under the hood, instead of bothering the world with their broken/unmaintained "old" method, whatever it did. I suspect that Intel programmers are just genuine sadists.) This change was suggested in issue #1765. The old GLX support is removed, as it's redundant and broken anyway. One remaining issue is that the first vaPutSurface() call fails with an unknown error. It returns -1, which is pretty strange, because vaapi error codes are normally positive. It happened with the old GLX code too, but does not happen with vo_vaapi. I couldn't find out why.
* build: make posix_spawn() mandatorywm42015-03-301-1/+7
| | | | | | | It was already accidentally used unconditionally by command.c. Apparently this worked well for us, so don't change anything about, but should it be unavailable, fail at configure time instead of compile time.
* RPI supportwm42015-03-291-5/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This requires FFmpeg git master for accelerated hardware decoding. Keep in mind that FFmpeg must be compiled with --enable-mmal. Libav will also work. Most things work. Screenshots don't work with accelerated/opaque decoding (except using full window screenshot mode). Subtitles are very slow - even simple but huge overlays can cause frame drops. This always uses fullscreen mode. It uses dispmanx and mmal directly, and there are no window managers or anything on this level. vo_opengl also kind of works, but is pretty useless and slow. It can't use opaque hardware decoding (copy back can be used by forcing the option --vd=lavc:h264_mmal). Keep in mind that the dispmanx backend is preferred over the X11 ones in case you're trying on X11; but X11 is even more useless on RPI. This doesn't correctly reject extended h264 profiles and thus doesn't fallback to software decoding. The hw supports only up to the high profile, and will e.g. return garbage for Hi10P video. This sets a precedent of enabling hw decoding by default, but only if RPI support is compiled (which most hopefully it will be disabled on desktop Linux platforms). While it's more or less required to use hw decoding on the weak RPI, it causes more problems than it solves on real platforms (Linux has the Intel GPU problem, OSX still has some cases with broken decoding.) So I can live with this compromise of having different defaults depending on the platform. Raspberry Pi 2 is required. This wasn't tested on the original RPI, though at least decoding itself seems to work (but full playback was not tested).
* input: remove Linux joystick supportwm42015-03-241-5/+0
| | | | | | | | | | | Why did this exist in the first place? Other than being completely useless, this even caused some regressions in the past. For example, there was the case of a laptop exposing its accelerometer as joystick device, which led to extremely fun things due to the default mappings of axis movement being mapped to seeking. I suppose those who really want to use their joystick to control a media player (???) can configure it as mouse device or so.
* input: remove classic LIRC supportwm42015-03-241-4/+0
| | | | It's much easier to configure remotes as X11 input devices.
* audio: remove internal libmpg123 wrapperwm42015-03-241-4/+0
| | | | | | | We've been prefering the libavcodec mp3 decoder for half a year now. There is likely no benefit at all for using the libmpg123 one. It's just a maintenance burden, and tricks users into thinking it's a required dependency.
* build: fix missing windows librariesKevin Mitchell2015-03-161-2/+2
* build: simplify windows checkswm42015-03-111-23/+12
| | | | | There's no reason to do finegrained checks for libraries which always must be present. It also reduces the number of extra dependencies.
* build: disable tests by defaultStefano Pigozzi2015-03-101-0/+1
| | | | | Having them autodetect is a bad idea since it would link cmocka in the main mpv binary (which users don't want).
* build: make vdpau and dxva2 checks nicerwm42015-03-061-2/+2
| | | | | | Using check_statement() with an empty statement just to check for the header is quite a hack. Fix check_headers() (so it takes a "use" parameter), and use it for the checks instead.
* build: check whether hwaccels are enabled in FFmpegwm42015-03-051-3/+5
| | | | | FFmpeg can be compiled with them disabled, and then it won't provide the public headers specific to these APIs, causing mpv compilation failure.
* Remove some FFmpeg/Libav compatibility hackswm42015-03-031-43/+0
| | | | | | All of these are now in the supported FFmpeg and Libav versions. The 3 remaining API checks are for FFmpeg-only things.
* build: bump required FFmpeg/Libav librarieswm42015-03-031-9/+10
| | | | | | | | | | | | | | | | The af_lavrresample commit made compilation fail on Libav 10, so I think it's time to require somewhat more recent dependencies. Libav 11 is the latest release, and FFmpeg 2.4 seems to correspond to Libav 11. So use these. Also adjust the configure failure message. Instead of (accidentally) printing the pkg-config versions twice, print the release version numbers too. This is helpful, because the release version numbers are completely different from the pkg-config ones. I will probably remove some compatibility hacks in the following commits too.
* Revert "Revert recent vo_opengl related commits"Niklas Haas2015-02-281-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | Omitted a simple, but devastasting check. Fixed the relevant commits now. This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab. diff --git a/video/out/gl_video.c b/video/out/gl_video.c index 9c8a643..f1ea03e 100644 --- a/video/out/gl_video.c +++ b/video/out/gl_video.c @@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p) shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma); shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma); shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886", - gamma_fun == MP_CSP_TRC_BT_1886); + use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886); shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB", - gamma_fun == MP_CSP_TRC_SRGB); + use_linear_light && gamma_fun == MP_CSP_TRC_SRGB); shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid); if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3) shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
* Revert recent vo_opengl related commitswm42015-02-281-7/+0
| | | | | | | | | | | | | | | Breaks vo_opengl by default. I'm hot able to fix this myself, because I have no clue about the overcomplicated color management logic. Also, whilethis is apparently caused by commit fbacd5, the following commits all depend on it, so revert them too. This reverts the following commits: e141caa97dade07f4d7e0d6c208bcd3493e712ed 653b0dd5295453d9661f673b4ebd02c5ceacf645 729c8b3f641e633474be612e66388c131a1b5c92 fbacd5de31de964f7cd562304ab1c9b4a0d76015 Fixes #1636.
* screenshots: check for AVFrame csp supportNiklas Haas2015-02-281-0/+7
| | | | Apparently, libav stable is old enough to not have these fields.
* input: avoid creating world-writeable file with --input-unix-socketwm42015-02-261-0/+4
| | | | | This requires fchmod(), which is not necessarily available everywhere. It also might not work at all. (It does work on Linux.)
* remove dead commentStefano Pigozzi2015-02-251-2/+0
* build: move QuartzCore linking to the cocoa checkStefano Pigozzi2015-02-251-1/+1
| | | | | It's needed for the DisplayLink functions so it must be enabled for the basic cocoa code.
* wscript: adjust some pkg-config checkswm42015-02-231-2/+2
| | | | | Make the version a separate argument, like in all other pkg-config checks.
* build: slightly improve libass version number test failure messagewm42015-02-211-2/+3
* build: require recent libasswm42015-02-181-1/+1
| | | | | | | | | Nobody should use an older version. It's perfectly backwards and forward compatible, so distros have no excuse not to package a recent version. Older versions lack tons of bug fixes (some of them crashing bugs, and potentially security relevant). With love to Debian, which is still on 0.10.2.
* vf_vapoursynth: replace a hack with a newer VS API functionwm42015-02-161-1/+1
| | | | | The new function does exactly what we need. Replaces the old hack, which created the vscore by running an empty script.
* af_rubberband: pitch correction with librubberbandwm42015-02-111-0/+4
| | | | | | | | | If "--af=rubberband" is used, librubberband will be used to speed up or slow down audio with pitch correction. This still has some problems: the audio delay is not calculated correctly, so the audio position jitters around by a few milliseconds. This will probably ruin video timing.
* build: add option to generate a clang compilation databaseStefano Pigozzi2015-02-051-0/+8
| | | | | | | | The compilation database is a JSON file[1] storing all compilation flags. That is useful for tools using libclang for code completion and error reporting (for example: YouCompleteMe for vim). [1]:
* build: disable pdf build by defaultwm42015-02-021-0/+1
| | | | | rst2pdf keeps having sporadic layouting failures, causing build failures.
* build: fix v4l2 support on NetBSDwm42015-01-311-5/+12
| | | | | It was accidentally broken. Tested by a NetBSD user. May help with other BSDs.
* build: remove bogus client API examples buildwm42015-01-231-7/+0
| | | | | | | | | | | The symlink trick made waf go crazy (deleting source files, getting tangled up in infinite recursion... I wish I was joking). This means we still can't build the client API examples in a reasonable way using the include files of the local repository (instead of globally installed headers). Not building them at all is better than deleting source files. Instead, provide some manual instructions how to build each example (except for the Qt examples, which provide qmake project files).
* build: reduce worst case with mismatching FFmpeg pkg-config fileswm42015-01-201-8/+8
| | | | | | | | | | | | | | | | | | | Handles mismatching libavfilter/libavdevice and libavcodec slightly better. libavfilter and libavdevice are optional, and thus are checked separately and at a later point of the build. But if a user system has at least 2 FFmpeg installations, and one of them lacks libavfilter or libavdevice, the build script will pick up the libavfilter/libavdevice package of the "other" FFmpeg installation. The moment waf picks these up, all include paths will start pointing at the "wrong" FFmpeg, and the FFmpeg API checks done earlier might be wrong too, leading to obscure and hard to explain compilation failures. Just moving the libavfilter/libavdevice checks before the FFmpeg API checks somewhat deals with this issue. Certainly not a proper solution, but since the change is harmless, and there is no proper solution, and the change doesn't actually add anything new, why not.
* win32: remove check for SetPriorityClass()wm42015-01-201-5/+0
| | | | | | | | | | This function is always available, which is reflected by the fact that the configure check doesn't actually bother to check for its existence. Instead, MinGW and Cygwin imply it. The check was probably "needed" when the priority code was still in a separate source file. Remove the check, and use _WIN32 for testing for the win32 API (in a bunch of other places too).
* build: prefer libswresample over libavresample on FFmpegwm42015-01-021-5/+5
| | | | | | | | | | I hoped we could always use libavresample, but the FFmpeg project is being too dickish to enable libavresample by default - which means we need our libswresample-to-libavresample hack anyway. Give up, and use the "supported" one of the duplicated libraries when compiling against FFmpeg (relying on the fact that libswresample won't be present if compiling against Libav).
* build: try to make examples build both in-tree and out-of-treewm42015-01-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | The examples simple.c and cocoabasic.m can be compiled without installing libmpv. But also, they didn't use the correct include path libmpv programs normally use, so they couldn't be built with a properly installed system-libmpv. That's pretty bad for examples, which are supposed to show how to use libmpv correctly. So do some bullshit that symlinks libmpv to a "mpv" include directory under the build directory. This name-mismatch is a direct consequence of the bullshit done in 499a6758 (requested in #539 for dumb reasons). (We don't want to name the client API headers directory "mpv", because that would be too unspecific, and clashes with having the mpv binary in the same directory.) If you have spaces or other "unusual" characters in your paths, the build will break, because I couldn't find out where waf hides its function to escape shell parameters (or a way to invoke programs without involving the shell). Neither does such a thing to be documented, nor do they seem to have a clear way to do this in their code. This also doesn't compile the Qt examples, because everything becomes even more terrible from there on.
* win32: add native wrappers for pthread functionswm42015-01-011-0/+7
| | | | | | | Off by default, use --enable-win32-internal-pthreads . This probably still needs a lot more testing. It also won't work on Windows XP.
* ao_portaudio: remove this audio outputwm42014-12-291-6/+0
| | | | | It's just completely useless. We have good native support for all 3 desktop platforms, and ao_sdl or ao_openal as fallbacks.
* chmap_sel: add multichannel fallback heuristicStefano Pigozzi2014-12-291-0/+4
| | | | | | | | | | | | Instead of just failing during channel map selection, try to select a close layout that makes most sense and upmix/downmix to that instead of failing AO initialization. The heuristic is rather simple, and uses the following steps: 1) If mono is required always prefer stereo to a multichannel upmix. 2) Search for an upmix that is an exact superset of the required channel map. 3) Search for a downmix that is the exact subset of the required channel map. 4) Search for either an upmix or downmix that is the closest (minimum difference of channels) to the required channel map.
* win32: add mmap() emulationwm42014-12-261-6/+2
| | | | | | | | Makes all of overlay_add work on windows/mingw. Since we now don't explicitly check for mmap() anymore (it's always present), this also requires us to make af_export.c compile, but I haven't tested it.
* build: require alsa libs not older than 6 yearswm42014-12-161-1/+1
| | | | | Some IEC958 flags we use have been introduced in 2008, which makes compilation fail on older systems.
* build: update to waf 1.8.4Stefano Pigozzi2014-12-041-1/+1
* video: remove things forgotten in previous commitwm42014-12-031-6/+0
| | | | Oops.
* video/filter: kill vf_pp (libpostproc)wm42014-12-031-4/+0
| | | | | | | | | This is an ancient filter, and we assume it's not useful anymore. If you really want this, it's still available in libavfilter (e.g. via --vf=lavfi=[pp...]). The disadvantage is that mpv doesn't pass through QP information to libavfilter. (This was probably the reason vf_pp still was part of mpv - it was slightly easier to pass QP internally.)
* build: move --cplayer to build optionsStefano Pigozzi2014-11-281-4/+5
| | | | This way it’s near to it’s libmpv counterparts
* build: move --dvbin to TV features, remove --dvbStefano Pigozzi2014-11-281-9/+4
* build: fix typosStefano Pigozzi2014-11-281-2/+2
| | | thanks to @Nikoli
* wscript: move down some less important checkswm42014-11-171-8/+8
* build: check for mingw-w64 explicitlywm42014-11-171-1/+16
| | | | | And fail building if not any of MingW-w64 or POSIX are found. Obviously, mpv needs one of those 2.
* atomics: add atomic_compare_exchange_strong()wm42014-11-091-0/+1
| | | | | | | | | | | | | | | | As usual, we use C11 semantics, and emulate it if <stdatomic.h> is not available. It's a bit messy with __sync_val_compare_and_swap(). We assume it has "strong" semantics (it can't fail sporadically), but I'm not sure if this is really the case. On the other hand, weak semantics don't seem to be possible, since the builtin can't distinguish between the two failure cases that could occur. Also, to match the C11 interface, use of gcc builtins is unavoidable. Add a check to the build system to make sure the compiler supports them (although I don't think there's any compiler which supports __sync_*, but not these extensions). Needed for the following commit.
* vo_opengl: minimal EGL on X11 supportwm42014-11-041-0/+7
| | | | | | Pretty useless and only good for testing. Does not include any form of GLES support.
* build: remove bundle support from wafStefano Pigozzi2014-11-011-6/+0
| | | | Use TOOLS/ instead. It's just better and less hacky.
* build: fix 'ar' invocation when cross-compilingwm42014-11-011-1/+3
| | | | | | | | This shouldn't use the host's 'ar' when building static libs. It only worked until now because Linux 'ar' is usually built with PE support. Couldn't confirm whether it works, because this dumb crap is just broken when cross-compiling to mingw.
* Drop libquvi supportwm42014-10-251-16/+0
| | | | | | | | | | | No development activity (or even any sign of life) for almost a year. A replacement based on youtube-dl will probably be provided before the next mpv release. Ask on the IRC channel if you want to test. Simplify the Lua check too: libquvi linking against a different Lua version than mpv was a frequent issue, but with libquvi gone, no direct dependency uses Lua, and such a clash is rather unlikely.
* video: initial dxva2 supportwm42014-10-251-0/+5
| | | | | Shamelessly stolen from ffmpeg. It probably doesn't work - you can debug it yourself.
* build: enable cdda:// by default againwm42014-10-251-1/+0
| | | | | | Apparently people want this. (???) See #1214.
* terminal: drop ncurses/terminfo/termcap supportwm42014-10-231-13/+0
| | | | | | It was disabled since the last release, and nobody complained loudly. Further details see commit 4b5c3ea7.
* osdep: NetBSD pthread_setname_np()wm42014-10-221-1/+8
| | | | | | From: bugmen0t on github Fixes #1207.
* Set thread name for debuggingwm42014-10-191-0/+19
| | | | | | | | | | Especially with other components (libavcodec, OSX stuff), the thread list can get quite populated. Setting the thread name helps when debugging. Since this is not portable, we check the OS variants in waf configure. old-configure just gets a special-case for glibc, since doing a full check here would probably be a waste of effort.
* fix build on OS X and BSDStefano Pigozzi2014-10-191-2/+3
* lua: add an utility function for starting processeswm42014-10-191-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because 1) Lua is terrible, and 2) popen() is terrible. Unfortunately, since Unix is also terrible, this turned out more complicated than I hoped. As a consequence and to avoid that this code has to be maintained forever, add a disclaimer that any function in Lua's utils module can disappear any time. The complexity seems a bit ridiculous, especially for a feature so far removed from actual video playback, so if it turns out that we don't really need this function, it will be dropped again. The motivation for this commit is the same as with 8e4fa5fc. Note that there is an "#ifndef __GLIBC__". The GNU people are very special people and thought it'd be convenient to actually declare "environ", even though the POSIX people, which are also very special people, state that no header declares this and that the user has to declare this manually. Since the GNU people overtook the Unix world with their very clever "embrace, extend, extinguish" strategy, but not 100%, and trying to build without _GNU_SOURCE is hopeless; but since there might be Unix environments which support _GNU_SOURCE features partially, this means that in practice "environ" will be randomly declared or not declared by system headers. Also, gcc was written by very clever people too, and prints a warning if an external variable is declared twice (I didn't check, but I suppose redeclaring is legal C, and not even the gcc people are clever enough to only warn against a definitely not legal C construct, although sometimes they do this), ...and since we at mpv hate compiler warnings, we seek to silence them all. Adding a configure test just for a warning seems too radical, so we special-case this against __GLIBC__, which is hopefully not defined on other libcs, especially not libcs which don't implement all aspects of _GNU_SOURCE, and redefine "environ" on systems even if the headers define it already (because they support _GNU_SOURCE - as I mentioned before, the clever GNU people wrote software THAT portable that other libcs just gave up and implemented parts of _GNU_SOURCE, although probably not all), which means that compiling mpv will print a warning about "environ" being redefined, but at least this won't happen on my system, so all is fine. However, should someone complain about this warning, I will force whoever complained about this warning to read this ENTIRE commit message, and if possible, will also force them to eat a printed-out copy of the GNU Manifesto, and if that is not enough, maybe this person could even be forced to convince the very clever POSIX people of not doing crap like this: having the user to manually declare somewhat central symbols - but I doubt it's possible, because the POSIX people are too far gone and only care about maintaining compatibility with old versions of AIX and HP-UX. Oh, also, this code contains some subtle and obvious issues, but writing about this is not fun.
* cocoa: allow to disable apple remote at compile timeStefano Pigozzi2014-10-171-0/+5
| | | | | Actually doesn't remove the related flags so that one can still pass the option with the option doing nothing.
* vf_vapoursynth: add standalone Lua scriptingwm42014-10-121-13/+17
* build: update waf to version 1.8.1Stefano Pigozzi2014-10-111-1/+1
| | | | Fixes #1164
* build: make zsh completion directory configurablePhilip Sequeira2014-10-111-0/+1
| | | | Also, use the zsh default location (rather than the Debian one).
* audio: skip samples and adjust timestamps ourselveswm42014-10-031-0/+6
| | | | | | | | | | This gets rid of this warning: Could not update timestamps for skipped samples. This required an API addition to FFmpeg (otherwise it would instead doing arithmetic on the timestamps itself), so whether it works depends on the FFmpeg version.
* audio/out: disable ao_sndio by defaultwm42014-09-261-1/+2
| | | | | Don't build it, move it down the autoprobe list even if it's enabled. It doesn't work well enough.
* build: update minimum wayland versionAlexander Preisinger2014-09-191-2/+2
| | | | Uh oh.
* input: use libwaio for pipe input on Windowswm42014-09-141-0/+11
| | | | | | | | | | | | Use libwaio to read from pipes (stdin or named pipes) on Windows. This liberates us from nasty issues, such as pipes (as created by most programs) not being possible to read in a non-blocking or event-driven way. Although it would be possible to do that in a somewhat sane way on Vista+, it's still not easy, and on XP it's especially hard. libwaio handles these things for us. Move pipe.c to pipe-unix.c, and remove Windows specific things. Also adjust the input.c code to make this work cleanly.
* ao_oss: use poll(), drop --disable-audio-select supportwm42014-09-111-5/+0
| | | | | | | | | | | | | | Replace select() usage with poll() (and reduce code duplication). Also, while we're at it, drop --disable-audio-select, since it has the wrong name anyway. And I have doubts that this is needed anywhere. If it is, it should probably fallback to doing the right thing by default, instead of requiring the user to do it manually. Since nobody has done that yet, and since this configure option has been part of MPlayer ever since ao_oss was added, it's probably safe to say it's not needed. The '#ifdef SNDCTL_DSP_GETOSPACE' was pointless, since it's already used unconditionally in another place.
* build: fix everythingwm42014-09-101-1/+1
| | | | A missing dependency entry made ./waf configure always fail.
* input: remove central select() callwm42014-09-101-7/+0
| | | | | This is now unused. Get rid of it and all surrounding infrastructure, and replace the remaining "wakeup pipe" with a semaphore.
* vo_corevideo: remove this VOStefano Pigozzi2014-09-061-9/+3
| | | | | | | This was kept in the codebase because it is slightly faster than --vo=opengl on really old Intel cards (from the GMA era). Time to kill it, and let it rest. Fixes #1061
* build: handle insane libavcodec API bullshitwm42014-09-051-0/+6
| | | | | | | | | | | | | | | | | | | | | The oldest supported FFmpeg release doesn't provide av_vdpau_alloc_context(). With these versions, the application has no other choice than to hard code the size of AVVDPAUContext. (On the other hand, there's av_alloc_vdpaucontext(), which does the same thing, but is FFmpeg specific - not sure if it was available early enough, so I'm not touching it.) Newer FFmpeg and Libav releases require you to call this function, for ABI compatibility reasons. It's the typcal lakc of foresight that make FFmpeg APIs terrible. mpv successfully pretended that this crap didn't exist (ABI compat. is near impossible to reach anyway) - but it appears newer developments in Libav change the function from initializing the struct with all-zeros to something else, and mpv vdpau decoding would stop working as soon as this new work is relewased. So, add a configure test (sigh). CC: @mpv-player/stable
* build: disable terminfo and termcap code by defaultwm42014-08-211-0/+2
| | | | If nobody complains soon enough, I will remove the code completely.
* x11: listen to xrandr eventswm42014-08-171-1/+1
| | | | | | | | | | | If the Xrandr configuration changes, re-read it. So if you change display modes or screen configuration, it will update the framedrop refresh rate accordingly. This passes the rootwin to XRRSelectInput(), which may or may not be allowed. But it works, and the documentation (which is worse than used toilet paper, great job Xorg) doesn't forbid it, or in fact say anything about what the window parameter is even used for.
* build: use pkg-config for xscreensaverwm42014-08-161-2/+1
* build: drop check for XF86keysym.hwm42014-08-161-5/+0
| | | | | | This is always included in the Xorg development headers. Strictly speaking it's not necessarily available with other X implementations, but these are hopefully all dead.
* x11: use xrandr to retrieve display refresh ratewm42014-08-161-4/+3
| | | | | | | | | | | | | | | | | Drop use of the ancient XF86VM, and use the slightly less ancient Xrandr extension to retrieve the refresh rate. Xrandr has the advantage that it supports multiple monitors (at least the modern version of it). For now, we don't attempt any dynamic reconfiguration. We don't request and listen to Xrandr events, and we don't notify the VO code of changes in the refresh rate. (The later works by assuming that X coordinates map directly to Xrandr coordinates, which probably is wrong with compositing window manager, at least if these use complicated transformations. But I know of no API to handle this.) It would be nice to drop use of the Xinerama extension too, but unfortunately, at least one EWMH feature uses Xinerama screen numbers, and I don't know how that maps to Xrandr outputs.
* demux_lavf: support new metadata update APIwm42014-08-141-0/+6
| | | | | This Libav-invented API is of course completely different from the FFmpeg-one. (The fun part is that I approved of both.)
* build: allow to disable building the cplayerStefano Pigozzi2014-08-061-0/+4
* build: expose waf variants to the userStefano Pigozzi2014-08-061-0/+27
| | | | | This allows the user to execute multiple configuration and build steps. It can be used for several scenarios where you need different compiler flags.
* build: cocoa-application config targetFRAU KOUJIRO2014-08-061-11/+23
| | | | | I had to put it after video options because it depends on cocoa; is there anywhere better to put it rather than making a new group?
* build: list exported symbols explicitlywm42014-08-051-3/+1
| | | | | | | | | | | Instead of using a regex to match names to be exported from the libmpv dynamic shared library, use a libmpv.def file, which lists all exported functions explicitly. This reduces the platform specifics in I'm not sure if the separate compile_sym task is still needed (it could probably be collapsed, which would concentrate the platform specifics into one place).
* build: fix cross-compilation of libmpvwm42014-08-051-1/+3
| | | | | | | libmpv requires nm for creating the list of exported symbols (this is done in We should probably just make this list static instead, but since this involves platform-specific code, for now this quick-fix will do.
* vda: only support the new hwaccel 1.2 API (remove old code)Stefano Pigozzi2014-08-011-16/+2
| | | | | | | | | Since the new hwaccel API is now merged in ffmpeg's stable release, we can finally remove support for the old API. I pretty much kept lu_zero's new code unchanged and just added some error printing (that we had with the old glue code) to make the life of our users less miserable.
* ao_pulse: remove hacks for ancient PulseAudio versionswm42014-07-261-1/+1
| | | | | | | | | | | This was needed by very old (0.9) versions only. Get rid of it. Unfortunately, I can't cross-check with the original bug report, since the bug URL leads to this: Internal Server Error TracError: IOError: [Errno 2] No such file or directory: '/home/lennart/svn/trac/pulseaudio/VERSION'
* build: enable compiler optimization by defaultTsukasa OMOTO2014-07-201-0/+9
* Revert "Remove DVD and Bluray support"wm42014-07-151-0/+13
| | | | | | This reverts commit 4b93210e0c244a65ef10a566abed2ad25ecaf9a1. *shrug*
* Remove DVD and Bluray supportwm42014-07-141-13/+0
| | | | It never worked well. Just remux your DVD and BD images to mkv.
* build: allow compilation without any atomicswm42014-07-051-4/+7
| | | | | | | | | | | | | | | | | | | Not all compilers on all platforms have atomics available (even if they could, technically speaking). We don't use atomics that much, only the following things rely on it: 1. the audio pull code, and all audio outputs using it 2. updating global msg levels 3. reading log messages through the client API Just disable 1. and 3. if atomics are not available. For 2., using fake- atomics isn't too bad; at worst, message levels won't properly update under certain situations (but most likely, it will work just fine). This means if atomics are not available, the client API function mpv_request_log_messages() will do nothing. CC: @mpv-player/stable
* video: Add BT.2020-NCL colorspace and transfer functionNiklas Haas2014-06-221-0/+6
| | | | Source:!!PDF-E.pdf
* build: remove BSD-specific /usr/local include path additionswm42014-06-201-8/+0
| | | | | | It seems it's generally cleaner to leave this stuff to the BSDs. Additionally, the NetBSD part wasn't even correct, because it made the compiler prefer the system include path before local include files.
* build: check for 64bit stdatomic.h operations tooAlessandro Ghedini2014-06-171-3/+3
| | | | | This fixes the build on platform where the atomic calls can't be turned into lock-free instructions and thus need the external libatomic library (e.g. mips).
* gl_lcms: use thread-safe lcms API, require lcms2 2.6wm42014-06-161-1/+1
| | | | | | | | | | | | | | The error log callback was not thread-safe and not library-safe. And apparently there were some other details that made it not library-safe, such as a global lcms plugin registry. Switch the the thread-safe API provided by lcms2 starting with 2.6. Remove our approximate thread-safety hacks. Note that lcms basically provides 2 APIs now, the old functions, and the thread-safe alternatives whose names end with THR. Some functions don't change, because they already have a context of some sort. Care must be taken not to accidentally use old APIs.
* build: add '--enable-libmpv-static' optionxylosper2014-06-161-1/+7
| | | | Signed-off-by: wm4 <wm4@nowhere>
* build: disable zsh completions by default, fixes e.g. cross compilationwm42014-06-091-0/+1
| | | | | | | | The Perl script generating the completions actually invokes mpv, and it runs during the build. This is not sane and breaks at least cross compilation. As a workaround, disable the completions by default for now.
* build: generate and install zsh completion scriptAlessandro Ghedini2014-06-081-0/+4
* wscript: update waf version check to the version in bootstrap.pywm42014-06-061-1/+1
* demux_lavf: support new rotation metadata APIwm42014-06-011-0/+6
* stream: remove VCD supportwm42014-06-011-11/+0
| | | | | | | | | If a single person complains, I will readd it. But I don't expect that this will happen. The main reason for removing this is that it's some of the most unclean code remaining, it's unmaintained, and I've never ever heard of someone using it.
* tv: remove sysinfo() usagewm42014-05-301-5/+0
| | | | | | This call was used limited the buffer size if installed RAM was below 16 MB. This stopped being useful a decade ago. The check could also overflow on 32 bit systems. Just get rid of it.
* build: disable PortAudio by defaultwm42014-05-291-0/+1
| | | | | | | | | This was originally added because we thought this would make a good portable audio API, which would give us good behavior on Windows, Linux, and OSX. But this hope was disappointed: it's not reliable enough (nice deadlocks on Linux when seeking, i.e. resetting the audio device), doesn't have enough features (no channel maps, no digital passthrough), and in general just is not very good.
* build: disable cdda and vcd by defaultwm42014-05-241-1/+3
| | | | | Let's see if anyone complains. cdda is relatively inoffensive, but the vcd code is the definition of ifdef-hell.
* stream_file: readjust some windows ifdefferywm42014-05-241-4/+0
| | | | | | | | | | Also sneak in some cosmetics. setmode() exists on Windows/msvcrt only, so there's no need for a config test. I couldn't reproduce the problem with seekable pipes on wine, so axe it. (I'm aware that it still could be an issue on real Windows.)
* build: "tv-v4l2" needs "tv"wm42014-05-221-0/+1
| | | | Fixes #795.
* Fix the build on OpenBSD and FreeBSDJuan Francisco Cantero Hurtado2014-05-211-1/+1
| | | | | | Without this change, the compiler uses by default the "talloc.h" file installed by the package libtalloc within /usr/local/include. Found and tested on OpenBSD but FreeBSD has the same patch on its ports tree.
* atomics: switch to C11 stdatomic.hwm42014-05-211-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | In my opinion, we shouldn't use atomics at all, but ok. This switches the mpv code to use C11 stdatomic.h, and for compilers that don't support stdatomic.h yet, we emulate the subset used by mpv using the builtins commonly provided by gcc and clang. This supersedes an earlier similar attempt by Kovensky. That attempt unfortunately relied on a big copypasted freebsd header (which also depended on much more highly compiler-specific functionality, defined reserved symbols, etc.), so it had to be NIH'ed. Some issues: - C11 says default initialization of atomics "produces a valid state", but it's not sure whether the stored value is really 0. But we rely on this. - I'm pretty sure our use of the __atomic... builtins is/was incorrect. We don't use atomic load/store intrinsics, and access stuff directly. - Our wrapper actually does stricter typechecking than the stdatomic.h implementation by gcc 4.9. We make the atomic types incompatible with normal types by wrapping them into structs. (The FreeBSD wrapper does the same.) - I couldn't test on MinGW.
* vda: Hwaccel 1.2 supportLuca Barbato2014-05-121-0/+7
| | | | Use the new context and the default functions provided.
* build: bump required libpostproc versionAlessandro Ghedini2014-04-251-1/+1
| | | | | The CPU autodetect feature was added in 52.2.100 and is lacking from the stand-alone version at
* Remove CPU detection and inline asm handlingwm42014-04-191-6/+2
| | | | | | | | | | | | | | Not needed anymore. I'm not opposed to having asm, but inline asm is too much of a pain, and it was planned long ago to eventually get rid fo all inline asm uses. For the note, the inline asm use that was removed with the previous commits was almost worthless. It was confined to video filters, and most video filtering is now done with libavfilter. Some mpv filters (like vf_pullup) actually redirect to libavfilter if possible. If asm is added in the future, it should happen in the form of external files.
* Remove radio://wm42014-04-131-18/+2
| | | | | It was disabled by default, works only for analogue radio, and I bet nobody uses it.
* vf_lavfi: copy AVFrame metadata into vf_lavfi privKevin Mitchell2014-04-131-0/+6
| | | | | | | | store it as mp_tas and add VFCTRL_GET_METADATA to access it from elsewhere Signed-off-by: wm4 <wm4@nowhere> old-configure test by wm4.
* video: add VapourSynth filter bridgewm42014-04-121-0/+4
| | | | | | | | | | | | Mainly meant to apply simple VapourSynth filters to video at runtime. This has various restrictions, which are listed in the manpage. Additionally, this actually copies video frames when converting frame references from mpv to VapourSynth, and a second time when going from VapourSynth to mpv. This is inefficient and could probably be easily improved. But for now, this is simpler, and in fact I'm not sure if we even can references VapourSynth frames after the core has been destroyed.
* build: bump libbluray minimum versionStefano Pigozzi2014-04-051-1/+1
| | | | | The code uses BD_OVERLAY_HIDE which seems to be available from 0.3.0. Update the pkg-config query.
* build: check if replaygain side data is availableAlessandro Ghedini2014-04-041-0/+6
| | | | | | Signed-off-by: wm4 <wm4@nowhere> old-configure change by wm4.
* build: only check for Linux fstatfs on LinuxJames Ross-Gowan2014-03-171-0/+1
| | | | | | This check incorrectly passed on Cygwin. While Cygwin has the statfs.f_type field, it contains the volume's FileSystemAttributes, which aren't useful for detecting network mounts.
* build: simplify libavfilter configure checkswm42014-03-161-14/+1
| | | | | This is all not needed anymore. In particular, remove all configure switches except --enable-libavfilter.
* af_lavrresample: remove avresample_set_channel_mapping() fallbackswm42014-03-161-7/+0
| | | | | | | This function is now always available. Also remove includes of reorder_ch.h from some AOs (these are just old relicts).
* vd_lavc: remove compatibility crapwm42014-03-161-22/+5
| | | | | | | All this code was needed for compatibility with very old libavcodec versions only (such as Libav 9). Includes some now-possible simplifications too.
* build: drop support for Libav 9wm42014-03-161-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | I have no tolerance for this garbage anymore. There are tons of issues with it (see e.g. previous commit), and there is no reason to use it either. Use Libav git, or Libav 10 when it's released. This also drops support for earlier FFmpeg release, which have exactly the same issues as Libav 9. FFmpeg 2.1.4 is still supported, because it's the latest release, and is reasonably recent. (Although this will probably also be dropped as soon as FFmpeg 2.2 is released.) Assumed version table (lots of nonsensical numbers): FFmpeg 2.1.4 FFmpeg (n2.2-rc2) Libav (v10_beta2) lavu 52.48.101 52.66.100 53.3.0 lavc 55.39.101 55.52.102 55.34.1 lavf 55.19.104 55.33.100 55.12.0 lsws 2.5.101 2.5.101 2.1.2 lavi 3.90.100 4.2.100 4.2.0 lswr 0.17.104 0.18.100 - lavr 1.1.0 1.2.0 1.1.0 libpostproc and libavdevice are not interesting. Following this commit, code needed just to support old Libav versions will start to be removed.
* af_lavfi: beat it into working with Libavwm42014-03-131-7/+1
| | | | | | | | | | | | | | | | | | | The main incompatibility was that Libav didn't have av_opt_set_int_list. But since that function is excessively ugly and idiotic (look how it handles types), I'm not missing it much. Use an aformat filter instead to handle the functionality that was indirectly provided by it. This is similar to how vf_lavfi works. The other incompatibility was channel handling. Libav consistently uses channel layouts only, why ffmpeg still requires messing with channel counts to some degree. Get rid of most channel count uses (and hope channel layouts are "exact" enough). Only in one case FFmpeg fails with a runtime check if we feed it AVFrames with channel count unset. Another issue were AVFrame accessor functions. FFmpeg introduced these for ABI compatibility with Libav. I refuse to use them, and it's not my problem if FFmpeg doesn't manage to provide a stable ABI for fields provided both by FFmpeg and Libav.
* build: make check for BSD fstatfs() a bit more strictwm42014-03-121-1/+1
| | | | | | | | | Linux also has fstatfs(), and the test relied on certain system include files being available on BSD, but not on Linux. It would break if Linux added the missing includes for some reason. Make it a bit stricter, and check for the struct statfs field the code needs.
* stream_file: network file system detection for LinuxPhilip Sequeira2014-03-121-0/+5
| | | | | | Addresses issue #558 on Linux systems. Signed-off-by: wm4 <wm4@nowhere>
* build: rename --enable-shared switchwm42014-03-111-2/+2
| | | | | | | Rename it to --enable-libmpv-shared. The option name didn't really tell much. When we add the possibility to create a static library, it would also be bad if that were named --enable-static (because it would sound like it does what --static-build does).
* build: fix compilation with MinGW-w64Hans-Kristian Arntzen2014-03-091-2/+14
| | | | | | References to WinMM/OLE/UUID were missing. Signed-off-by: wm4 <wm4@nowhere>
* configure: fix typoNyx0uf2014-02-241-1/+1
| | | | When using help, the output for --enable-shared was : `--enable-shared enable enable shared library [disable]`
* stream_file: activate cache with files on network file systemsStefano Pigozzi2014-02-171-0/+5
| | | | | | | | Detected 'protocols' are AFP, nfs, smb and webdav. This can be extended on request. This is currently only implemented for BSD systems (using fstatfs). This addresses issue #558 on the above platforms.
* build: bump libmpg123 versionwm42014-02-131-1/+1
| | | | | | | | | The minimum required version was bumped in the old configure script, but for the waf build system is was somehow forgotten or overlooked. Probably happened while the waf build system was developed in a separate branch. Closes #546.
* Add a client API examplewm42014-02-101-0/+5
* build: add option to build a librarywm42014-02-101-0/+7
| | | | | | | | | | | | | This library will export the client API functions. Note that this doesn't allow compiling the command line player to link against this library yet. The reason is that there's lots of weird stuff required to setup the execution environment (mostly Windows and OSX specifics), as well as things which are out of scope of the client API and every application has to do on its own. However, since the mpv command line player basically reuses functions from the mpv core to implement these things, it's not very easy to separate the command line player form the mpv core.
* demux_lavf: get updated metadata from a packet if availableBen Boeckel2014-02-061-0/+6
| | | | The side_data type is brand new in ffmpeg.
* wayland: change minimum versionAlexander Preisinger2014-02-021-2/+2
| | | | | Change minimum version to 1.3 and remove the version checking in the source code.
* waf: rename --enable-sdl to --enable-sdl1wm42014-01-251-1/+1
| | | | Grossly misleading.
* Detect Lua on FreeBSDGrzegorz Blach2014-01-151-1/+1
* Switch PDF manual generation to rst2pdfMartin Herkt2014-01-081-4/+2
| | | | | | | This finally gets rid of the LaTeX dependency. We should actually be using docultils directly here, but I didn't do this because of all the potential Python 2/3 breakage.
* build: don't depend on both libavresample and libswresamplewm42014-01-051-0/+1
| | | | | | When both libavresample and libswresample were detected, the script enabled both at the same time. This is not supported; although nothing bad happened apparently. Make the dependencies both mutually exclusive.
* build: fix cocoa configure check on OS X 10.7Stefano Pigozzi2014-01-021-5/+1
| | | | | It failed because the 10.7 SDK doesn't natively support array and dictionary subscripting.
* build: fix typoStefano Pigozzi2014-01-011-1/+1
* build: make configure fail if both __atomic and __sync are not availableStefano Pigozzi2014-01-011-2/+16
* build: check for libatomic and __atomic operationsAlessandro Ghedini2013-12-311-0/+7
| | | | | | Add check in old-configure as well. Reformat the check to use a maximum of 80 columns in the wscript. Signed-off-by: Stefano Pigozzi <>
* build: add flag for inline assemblyStefano Pigozzi2013-12-291-0/+5
| | | | | This is used to disable inline assembly (useful for old version of binutils like the one in OpenBSD).
* build: disable SDL by defaultStefano Pigozzi2013-12-291-2/+4
| | | | old-configure already behaves like this. Adapt wscript to the same default.
* build: fix shm detection on OpenBSDStefano Pigozzi2013-12-261-1/+1
| | | | Fixes #427
* input: remove LIRCCD supportwm42013-12-161-4/+0
| | | | | | | This removes support for the "LIRC Client Daemon", which is separate from LIRC, and hasn't been maintained for 10 years. See github issue #413.
* build: dvdnav needs dvdreadNikoli2013-12-131-0/+1
* Add prelimimary (basic, possibly broken) dvdnav supportwm42013-12-121-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | This readds a more or less completely new dvdnav implementation, though it's based on the code from before commit 41fbcee. Note that this is rather basic, and might be broken or not quite usable in many cases. Most importantly, navigation highlights are not correctly implemented. This would require changes in the FFmpeg dvdsub decoder (to apply a different internal CLUT), so supporting it is not really possible right now. And in fact, I don't think I ever want to support it, because it's a very small gain for a lot of work. Instead, mpv will display fake highlights, which are an approximate bounding box around the real highlights. Some things like mouse input or switching audio/subtitles stream using the dvdnav VM are not supported. Might be quite fragile on transitions: if dvdnav initiates a transition, and doesn't give us enough mpeg data to initialize video playback, the player will just quit. This is added only because some users seem to want it. I don't intend to make mpv a good DVD player, so the very basic minimum will have to do. How about you just convert your DVD to proper video files?
* build: prefer 4Front OSS to native implementationsbugmen0t2013-12-071-7/+7
| | | | | | | | | | | | | | | | If sys/soundcard.h is actually linux/soundcard.h then it supports only OSSv3 API. This may happen when OSSLIBDIR == /usr while forgetting to replace sys/soundcard.h from glibc. However, after fa620ff waf prefers native implementation which is inferior on Linux. To fix try making waf prefer oss-audio-4front. It's quite unusual to have 4Front OSS installed where native implementation is superior, anyway. Signed-off-by: bugmen0t <@> Make the false positives path also undef the 4Front define. Signed-off-by: Stefano Pigozzi <> Fixes #396
* build: fix linking to CoreFoundationagiz2013-12-061-1/+1
| | | | | | | | If only coreaudio was activativated and not cocoa, the build failed for missing CoreFoundation. Signed-off-by: Stefano Pigozzi <> Fixes #395
* build: link ARC to get subscripting implementationStefano Pigozzi2013-12-061-1/+2
| | | | | This is needed on OS X 10.7 to handle Objective-C subscripting correctly. It was present in the old configure, but I forgot it in the wscript.
* vo_opengl: support for vda hardware decodingStefano Pigozzi2013-12-021-0/+5
| | | | | | | | | | | The harder work was done in the previous commits. After that this feature comes out almost for free. The only problem is I can't get the textures created with CGLTexImageIOSurface2D to download properly, thus the code performs download using some CoreVideo APIs. If someone knows why download of textures created with CGLTexImageIOSurface2D doesn't work please contact me :)
* build: reject broken roaraudio sndio emulationwm42013-12-021-1/+1
| | | | | | | | roaraudio has some sort of sndio emulation, but apparently its header file is either blatantly broken, or an old version from the past. The sio_onvol() function has the wrong return type (void instead of int), and the SIO_DEVANY symbol is missing entirely. This broke the build, because the configure check was successful anyway.
* build: don't check libsmbclient version numberwm42013-11-301-1/+1
| | | | Rationale see github issues #385. Fixes #385.
* build: reimplement the OSS checks using a more declarative approachStefano Pigozzi2013-11-291-5/+35
| | | | | | | | | | | | | | | | | | The OSS checks were a big mess and quite buggy. This reimplementes them using a declarative approach and clearly distinguishing between the various OSS implementations. The code should now almost be auto-documenting. We currently support the following implementations of OSS: * platform-specific (with `sys/soundcard.h`) * SunAudio (default on NetBSD and useable on OpenBSD even if we have sndio support there). * 4Front (default on FreeBSD) Since now each OSS check also checks for the appropriate soundcard header, remove the old soundcard check. Many thanks to @bugmen0t for in depth info about all the BSDs. Check #380 and #359 for more info on this commit.
* build: add options for enabling and disabling any libquvi versionsNikoli2013-11-291-0/+7
| | | | Makes packaging a bit simpler.
* Take care of some libavutil deprecations, drop support for FFmpeg 1.0wm42013-11-291-1/+1
| | | | | | | | | | | | | | PIX_FMT_* -> AV_PIX_FMT_* (except some pixdesc constants) enum PixelFormat -> enum AVPixelFormat Losen some version checks in certain newer pixel formats. av_pix_fmt_descriptors -> av_pix_fmt_desc_get This removes support for FFmpeg 1.0.x, which is even older than Libav 9.x. Support for it probably was already broken, and its libswresample was rejected by our build system anyway because it's broken. Mostly untested; it does compile with Libav 9.9.
* build: make pthreads mandatorywm42013-11-281-6/+3
| | | | | | | | | | | pthreads should be available anywhere. Even if not, for environment without threads a pthread wrapper could be provided that can't actually start threads, thus disabling features that require threads. Make pthreads mandatory in order to simplify build dependencies and to reduce ifdeffery. (Admittedly, there wasn't much complexity, but maybe we will use pthreads more in the future, and then it'd become a real bother.)
* build: make --disable-gl disable all the gl backendsStefano Pigozzi2013-11-281-0/+4
| | | | Fixes #369
* build: add custom -I/-L flags for the BSDs [2]Stefano Pigozzi2013-11-281-4/+4
| | | | Fixup commit. .append() seems to to nothing.
* build: add custom -I/-L flags for the BSDsStefano Pigozzi2013-11-271-0/+8
| | | | Apparently this is needed for stuff like iconv.
* build: add a gdi check for windowsStefano Pigozzi2013-11-261-0/+6
| | | | | Incidentally this seems wrong in the configure as well because only gl-win32 depends on it instead of also making direct3d depend on this (as I did here).
* build: store dependencies as listsStefano Pigozzi2013-11-241-0/+3
| | | | | | | | | | | | | In Python sets are unordered, so iterating them after converting to a list always leads to different results. The code iterated on them to collect all the flags to pass to the compiler, and since the order of the flags changed, waf would rebuild all of the C files. Seems like in Python 2 this worked as expected by pure chance. This commit stores the sets as lists, and converts them to sets when the set operations are needed. Fixes #363
* build: make sure cwd is in Python's sys.pathStefano Pigozzi2013-11-231-0/+1
| | | | | | | | | Apparently some packaging systems (homebrew does this for example) change `sys.path` before they run any Python script to ensure that only the correct Python modules can be loadable. We need to make sure cwd is in `sys.path` since we need to load `` from there.
* build: remove abusive commentStefano Pigozzi2013-11-221-1/+0
| | | | | The check seems to be working anyway, even without sys/video.h. So ./configure was maybe wrong.
* build: unbreak PVR configure testwm42013-11-221-1/+1
* switch the build system to wafStefano Pigozzi2013-11-211-0/+759
This commit adds a new build system based on waf. configure and Makefile are deprecated effective immediately and someday in the future they will be removed (they are still available by running ./old-configure). You can find how the choice for waf came to be in `DOCS/waf-buildsystem.rst`. TL;DR: we couldn't get the same level of abstraction and customization with other build systems we tried (CMake and autotools). For guidance on how to build the software now, take a look at and the cross compilation guide. CREDITS: This is a squash of ~250 commits. Some of them are not by me, so here is the deserved attribution: - @wm4 contributed some Windows fixes, renamed configure to old-configure and contributed to the bootstrap script. Also, GNU/Linux testing. - @lachs0r contributed some Windows fixes and the bootstrap script. - @Nikoli contributed a lot of testing and discovered many bugs. - @CrimsonVoid contributed changes to the bootstrap script.