summaryrefslogtreecommitdiffstats
path: root/wscript
Commit message (Collapse)AuthorAgeFilesLines
* bash completion: add initial implementation of bash completionPhilip Langdale2020-01-091-0/+1
| | | | | | While we've had a zsh completion script for a while, we haven't had one for bash. This one is reasonably comprehensive, although there are improvements one could imagine for certain options.
* build: fix minimum libarchive versionwm42020-01-071-1/+1
| | | | | | Seems like 3.3.3 was not correct and too early. Fixes: #7334
* stream_libarchive: enable rar5 supportwm42020-01-041-1/+1
| | | | | | | | | | We whitelist formats (and not all of them). RAR v5 is a separated format entry for inexplicable reasons. (It's a separate implementation, but who really wants to support only either of the rar formats?) I'm not sure if it was libarchive 3.3.3. Their git history is absolutely chaotic. These people do not know how to use git. I couldn't be bothered to dig deeper.
* video: cuda: add explicit context creation for copy hwaccelsPhilip Langdale2019-12-291-2/+7
| | | | | | | | | | | | | | | | | | | | | In the distant past, the cuviddec backed copy hwaccel could be configured directly using lavc options. However, since that time, we gained support for automatic hw ctx creation which ended up bypassing the lavc options. Rather than trying to find a way to pass those options again, a better idea is to make the 'cuda-decode-device' option, used by the interop hwaccels, work for the copy hwaccels too. And that's pretty simple: we have to add a create function that checks the option and passes it on to ffmpeg. Note that this does require a slight re-jig to the configuration flags, as we now have a scenario where we want to build with support for the cuda copy hwaccels but not the interop ones. So we need a distinct configuration flag for that combination. Fixes #7295.
* vo_gpu: hwdec_vaegl: remove support for old-style interopPhilip Langdale2019-12-281-4/+4
| | | | | | | | | | | | | In vaapi 1.1.0 (which confusingly is libva release 2.1.0), they introduced a new surface export API that is more efficient, and we've been supporting that and the old API ever since (Feb 2018). If we drop support for the old API, we can do some fairly nice cleanup of the code. Note that the pkgconfig entries are explicitly versioned by the API version and not the library version. I confirmed the upstream pkgconfig files.
* build: fix build with disabled swift and Media Playerder richter2019-12-231-0/+5
| | | | | | | | | | | | | | when swift is disabled some headers are not included. one of them is the options/options.h header that is needed for the vo_sub_opts struct. we include it to fix the build without swift. the second problem is the build time check for the macOS 10.12.2 features or more specific the Media Player support. since it is a swift feature we can not use it when swift is disabled. add a separate Media Player check that also depends on swift and use that new preprocessor variable as a build time check instead. Fixes #7282
* build: downgrade EGL requirement from 1.5 to 1.4wm42019-12-161-4/+4
| | | | | | | | | | With the previous commit, there's no need for 1.5 anymore. And in fact, it's just too dangerous to rely on 1.5 because of all the EGL craziness. For example, you might get a 1.5 EGL system library, but a driver might still give you 1.4 at runtime. If you assume that you can call 1.5 functions, you will probably get random crashes in this case. What a cursed API. (The same problem exists with EGL 1.3, but fortunately nothing seems to use that anymore. We can just ignore that problem.)
* mac: replace old event tap for media key support with MediaPlayerder richter2019-12-151-0/+5
| | | | | | | | | | | | | | | the old event tap has several problems, like no proper priority support or having to set accessibility permissions for mpv or the terminal. it is now replaced by the new MediaPlayer which has proper priority support and isn't as greedy as previously. this only includes Media Key support and not any of the other features included in the MediaPlayer framework, like proper Now Playing data (only set dummy data for now). this is only available on macOS 10.12.2 and higher. also removes some unnecessary redefines. Fixes #6389
* mac: remove Apple Remote supportder richter2019-12-151-5/+0
| | | | | | the Apple Remote has long been deprecated and abandoned by Apple. current macs don't come with support for it anymore. support might be re-added with the next commit.
* build: fix zimg message in configure outputwm42019-12-061-1/+1
| | | | It's useful as software scaler in general, not just that video filter.
* x11: require EGL 1.5 and use eglGetPlatformDisplay()wm42019-11-161-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | eglGetPlatform() is a broken API, since it takes a windowing specific argument, yet is supposed to work for multiple APIs at the same time. On Linux, it can take both a X11 "Display" and a "wl_display". Obviously there is no way to specify what kind of display the argument is (it's just a void*). Mesa has _eglNativePlatformDetectNativeDisplay, which does funny stuff to try to guess the display type, including trying to call mincore() to determine whether the pointer can be accessed at all. I guess this recently accidentally broke (as a bug), but on the other hand, maybe it's time to do this properly. The fix is using eglGetPlaformDisplay(). This requires EGL 1.5, plus Mesa needs to support the associated platform extension (EGL_KHR_platform_x11). Since I see no reasonable way to do this in a compatible way, just require that EGL 1.5 is available. The problem is that EGL 1.4 seems to require you to create a display to query EGL version and extension, and you have a chicken-and-egg problem. It's very stupid. Maybe you could jump through some more hoops to get something compatible, but fuck that. Users on "too old" Mesa will fall back to GLX (which we keep around for a regrettable company known by the name of Nvidia). I think Wayland and GBM should do the same. They're sufficiently bleeding-edge that you can expect them to have EGL 1.5. On the other hand, the cursed RPI code will have to stay with a eglGetDisplay(). Speculative fix for #7154. (Rant about EGL follows. Actually I deleted it.)
* wscript: add --enable-ta-leak-report optionwm42019-11-081-0/+7
| | | | Kind of more convenient because I'm lazy.
* wscript: remove outdated --enable-libafwm42019-11-081-6/+0
| | | | | | | This stopped doing anything since how many years? The only actual effect was that af_rubberband was made GPL only. Now it is available in LGPL builds too.
* test: make tests part of the mpv binarywm42019-11-081-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, each .c file in test/ was built as separate, self-contained binary. Each binary could be run to execute the tests it contained. Change this and make them part of the normal mpv binary. Now the tests have to be invoked via the --unittest option. Do this for two reasons: - Tests now run within a "properly" initialized mpv instance, so all services are available. - Possibly simplifying the situation for future build systems. The first point is the main motivation. The mpv code is entangled with mp_log and the option system. It feels like a bad idea to duplicate some of the initialization of this just so you can call code using them. I'm also getting rid of cmocka. There wouldn't be any problem to keep it (it's a perfectly sane set of helpers), but NIH calls. I would have had to aggregate all tests into a CMUnitTest list, and I don't see how I'd get different types of entry points easily. Probably easily solvable, but since we made only pretty basic use of this library, NIH-ing this is actually easier (I needed a list of tests with custom metadata anyway, so all what was left was reimplement the assert_* helpers). Unit tests now don't output anything, and if they fail, they'll simply crash and leave a message that typically requires inspecting the test code to figure out what went wrong (and probably editing the test code to get more information). I even merged the various test functions into single ones. Sucks, but here you go. chmap_sel.c is merged into chmap.c, because I didn't see the point of this being separate. json.c drops the print_message() to go along with the new silent-by-default idea, also there's a memory leak fix unrelated to the rest of this commit. The new code is enabled with --enable-tests (--enable-test goes away). Due to waf's option parser, --enable-test still works, because it's a unique prefix to --enable-tests.
* stream: turn into a ring buffer, make size configurablewm42019-11-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In some corner cases (see #6802), it can be beneficial to use a larger stream buffer size. Use this as argument to rewrite everything for no reason. Turn stream.c itself into a ring buffer, with configurable size. The latter would have been easily achievable with minimal changes, and the ring buffer is the hard part. There is no reason to have a ring buffer at all, except possibly if ffmpeg don't fix their awful mp4 demuxer, and some subtle issues with demux_mkv.c wanting to seek back by small offsets (the latter was handled with small stream_peek() calls, which are unneeded now). In addition, this turns small forward seeks into reads (where data is simply skipped). Before this commit, only stream_skip() did this (which also mean that stream_skip() simply calls stream_seek() now). Replace all stream_peek() calls with something else (usually stream_read_peek()). The function was a problem, because it returned a pointer to the internal buffer, which is now a ring buffer with wrapping. The new function just copies the data into a buffer, and in some cases requires callers to dynamically allocate memory. (The most common case, demux_lavf.c, required a separate buffer allocation anyway due to FFmpeg "idiosyncrasies".) This is the bulk of the demuxer_* changes. I'm not happy with this. There still isn't a good reason why there should be a ring buffer, that is complex, and most of the time just wastes half of the available memory. Maybe another rewrite soon. It also contains bugs; you're an alpha tester now.
* build: fix strict ABI optionwm42019-11-041-0/+1
| | | | Fixes: #7118
* build: make vo_sdl conflict with cocoawm42019-10-251-0/+1
| | | | | | | | | | These are inherently incompatible. As far as I'm aware, SDL must be used from the main thread on OSX. (Technically, this condition is wrong: the problem happens on OSX in general, or more precisely, when SDL uses Cocoa. I didn't find the waf OSX dependency name after 5 second of searching, so I'm just using cocoa, without which mpv is useless on OSX anyway.)
* input: add gamepad support through SDL2Stefano Pigozzi2019-10-231-4/+19
| | | | | | | | | | | | | | | The code is very basic: - only handles gamepads, could be extended for generic joysticks in the future. - only has button mappings for controllers natively supported by SDL2. I heard more can be added through env vars, there's also ways to load mappings from text files, but I'd rather not go there yet. Common ones like Dualshock are supported natively. - analog buttons (TRIGGER and AXIS) are mapped to discrete buttons using an activation threshold. - only supports one gamepad at a time. the feature is intented to use gamepads as evolved remote controls, not play multiplayer games in mpv :)
* build: add --enable-ffmpeg-strict-abi optionwm42019-10-211-0/+4
| | | | | | | | | This can be used by distros to disable all known FFmpeg ABI violations. Currently only 1 is known, in demux_lavf.c. In addition to if-defing out the access to the private FFmpeg field, this disables the possibly fragile nested open callbacks, which make sense only if the aforementioned field can be accessed.
* build: lower required FFmpeg versionwm42019-10-201-1/+1
| | | | | | | | The FFmpeg version was last bumped a long time ago, except in commit 1638fa7b4663e4ad46ccd9750, where it was used for some obscure pixel format. This is pretty annoying, so make it optional.
* vo_wlshm: use memfd_create() instead of shm_open()Emmanuel Gil Peyrot2019-10-171-0/+6
| | | | | | | | | | | This syscall avoids the need to guess an unused filename in /dev/shm and allows seals to be placed on it. We immediately return if no fd got returned, as there isn’t anything we can do otherwise. Seals especially allow the compositor to drop the SIGBUS protections, since the kernel promises the fd won’t ever shrink. This removes support for any platform but Linux from this vo.
* vo_gpu/d3d11: add support for configuring swap chain formatJan Ekström2019-10-131-1/+1
| | | | | | | Query information on the system output most linked to the swap chain, and either utilize a user-configured format, or either 8bit RGBA or 10bit RGB with 2bit alpha depending on the system output's bit depth.
* cocoa-cb: remove get_property_* usages and split up mpv helperder richter2019-10-061-1/+1
| | | | | | | | | | all the get_property_* usages were removed because in some circumstances they can lead to deadlocks. they were replaced by accessing the vo and mp_vo_opts structs directly, like on other vos. additionally the mpv helper was split into a mpv and libmpv helper, to differentiate between private and public APIs and for future changes like a macOS vulkan context for vo=gpu.
* build: lower version requirement for EGLMarvin Schmidt2019-09-291-1/+1
| | | | | | | | `egl.pc` can be provided either by mesa or libglvnd. The latter doesn't follow the same version scheme as mesa but instead uses the API version that the library exposes, which is 1.5 for EGL[1] [1] https://github.com/NVIDIA/libglvnd/commit/0dfaea2bcb7cdcc785f95e244223bd004a2d7fba#diff-b58a140c00ea99fb9a708e15afaade62R8
* build: silence OpenGL deprecation warnings on macOS for C/objCRodger Combs2019-09-281-1/+2
| | | | | We know of the deprecation since 10.14, and thus we do not need to be reminded of it with each compiled file.
* wscript: check tvOS define's value to be nonzeroJan Ekström2019-09-271-1/+4
| | | | | | TARGET_OS_TV seems to always be defined, but set according to the build configuration. This fixes all Apple configurations being mis-identified as tvOS.
* zsh completion: move generation to runtime and improvePhilip Sequeira2019-09-271-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The completion function itself now parses --list-options on the first tab press and caches the results. This does mean a slight delay on that first tab press, but it will only do this if the argument being completed looks like an option (i.e. starts with "-"), so there is never a delay when just completing a file name. I've also put some effort into making it reasonably fast; on my machine it's consistently under 100 ms, more than half of which is mpv itself. Installation of zsh completion is now done unconditionally because it's nothing more than copying a file. If you really don't want it installed, set zshdir to empty: `./waf configure --zshdir= ...` Improvements in functionality compared to the old script: * Produces the right results for mpv binaries other than the one it was installed with (like a dev build for testing changes). * Does not require running mpv at build time, so it won't cause problems with cross compilation. * Handles aliases. * Slightly nicer handling of options that take comma-separated values and/or sub-options: A space is now inserted at the end instead of a comma, allowing you to immediately start typing the next argument, but typing a comma will still remove the automatically added space, and = and : will now do that too, so you can immediately add a sub-option. * More general/flexible handling of values for options that print their possible values with --option=help. The code as is could handle quite a few more options (*scale, demuxers, decoders, ...), but nobody wants to maintain that list here so we'll just stick with what the old completion script already did.
* vo_gpu: hwdec_drmprime_drm: add hwdec ctxJonas Karlman2019-09-271-1/+1
| | | | | | | This allows to use drm hwaccels that require a hwdevice. Tested with v4l2request hwaccel and cedrus driver on an allwinner device running mpv with --vo=gpu --gpu-context=drm --hwdec=drm.
* wscript: detect tvOS and disable posix-spawn usageAman Gupta2019-09-261-1/+5
| | | | | | cc #5331 Signed-off-by: Aman Gupta <aman@tmm1.net>
* wscript: Fix test for ffmpeg drmprime supportPhilip Langdale2019-09-221-2/+9
| | | | | | | This test requires libavutil headers but there is no avutil dependency for it to use. So let's add one, and also reorder the ffmpeg tests ahead of the video tests so that the avutil dependency can be used.
* test: fix cmocka assert_float_equal shadowing warningswm42019-09-211-1/+1
| | | | | | | | | Just use cmocka's function. It takes an epsilon argument, which we now provide directly. There's no assert_double_equal() in cmocka (and the float variant actually forces a conversion to the float type), but fortunately we didn't use it.
* waf: fix wayland-scanner deprecation warningdudemanguy2019-09-211-2/+2
| | | | | | Use `private-code` instead of `code` here. Also this bumps up the required wayland-client/wayland-cursor version to 1.15 which is still pretty old anyway.
* rpi: Update for modern systemsCameron Cawley2019-09-201-17/+6
|
* vf_fingerprint: use aligned_alloc instead of posix_memalignwm42019-09-191-0/+6
| | | | | | | | | | | I was assuming posix_memalign was the most portable function to use, but MinGW does not provide it for some reason. Switch to C11 aligned_alloc() which someone suggested was provided by MinGW (but actually isn't, someone probably confused it with the incompatible _aligned_malloc), and add a configure check. Even though it turned out that MinGW doesn't provide it, the function is slightly more elegant than posix_memalign(), so stay with it.
* video: add vf_fingerprint and a skip-logo scriptwm42019-09-191-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | skip-logo.lua is just what I wanted to have. Explanations are on the top of that file. As usual, all documentation threatens to remove this stuff all the time, since this stuff is just for me, and unlike a normal user I can afford the luxuary of hacking the shit directly into the player. vf_fingerprint is needed to support this script. It needs to scale down video frames as part of its operation. For that, it uses zimg. zimg is much faster than libswscale and generates more correct output. (The filter includes a runtime fallback, but it doesn't even work because libswscale fucks up and can't do YUV->Gray with range adjustment.) Note on the algorithm: seems almost too simple, but was suggested to me. It seems to be pretty effective, although long time experience with false positives is missing. At first I wanted to use dHash [1][2], which is also pretty simple and effective, but might actually be worse than the implemented mechanism. dHash has the advantage that the fingerprint is smaller. But exact matching is too unreliable, and you'd still need to determine the number of different bits for fuzzier comparison. So there wasn't really a reason to use it. [1] https://pypi.org/project/dhash/ [2] http://www.hackerfactor.com/blog/index.php?/archives/529-Kind-of-Like-That.html
* build: better POSIX checkwm42019-09-191-3/+1
| | | | This is the "official" method to do this.
* vf_vapourynth: remove Lua backendwm42019-09-191-11/+1
| | | | | | | | | | | | | | | I once created this because someone wanted to use vapoursynth without the Python dependency. No idea if anyone ever actually used it. It's sort of icky (it calls itself "lazy" to preempt complaints about how much it sucks), and complicates the build process. Kill it. It seems much more promising to have something like this: https://github.com/vapoursynth/vapoursynth/issues/386 This would either solve the build distribution problem by relaxing the Python dependency, and/or allow a Lua backend to be included without pain.
* vo_gpu: remove mali-fbdevwm42019-09-191-11/+2
| | | | | Useless at this point, I don't even know if it still works, or how to test it.
* vo_gpu: hwdec_vaapi: Refactor Vulkan and OpenGL interops for VAAPIPhilip Langdale2019-09-151-6/+1
| | | | | | Like hwdec_cuda, you get a big #ifdef mess if you try and keep the OpenGL and Vulkan interops in the same file. So, I've refactored them into separate files in a similar way.
* Remove classic Linux analog TV support, and DVB runtime controlswm42019-09-131-43/+6
| | | | | | | | | | | | | | | | | | | | | | | | Linux analog TV support (via tv://) was excessively complex, and whenever I attempted to use it (cameras or loopback devices), it didn't work well, or would have required some major work to update it. It's very much stuck in the analog past (my favorite are the frequency tables in frequencies.c for analog TV channels which don't exist anymore). Especially cameras and such work fine with libavdevice and better than tv://, for example: mpv av://v4l2:/dev/video0 (adding --profile=low-latency --untimed even makes it mostly realtime) Adding a new input layer that targets such "modern" uses would be acceptable, if anyone is interested in it. The old TV code is just too focused on actual analog TV. DVB is rather obscure, but has an active maintainer, so don't remove it. However, the demux/stream ctrl layer must go, so remove controls for channel switching. Most of these could be reimplemented by using the normal method for option runtime changes.
* Remove libdvdread support in favor of libdvdnavwm42019-09-131-11/+0
| | | | | | | | | | | stream_dvd.c contained large amounts of ancient, unmaintained code, which has been historically moved to libdvdnav. Basically, it's full of low level parsing of DVD on-disc structures. Kill it for good. Users can use the remaining dvdnav support (which basically operates in non-menu mode). Users have reported that libdvdread sometimes works better, but this is just libdvdnav's problem and not ours.
* cocoa-cb: migrate to swift 5 with swift 4 fallbackder richter2019-07-211-2/+3
| | | | | | | | | | | | | this migrates our current swift code to version 5 and 4. building is support from 10.12.6 and xcode 9.1 onwards. dynamic linking is the new default, since Apple removed static libs from their new toolchains and it's the recommended way. additionally the found macOS SDK version is printed since it's an important information for finding possible errors now. Fixes #6470
* cocoa-cb: conditional compilation for Dark Mode and Material featuresder richter2019-07-211-1/+11
| | | | Fixes #6621
* build: add Swift dynamic linking supportder richter2019-07-211-0/+5
| | | | | | | | | | | | | | | this is in preparation for the upcoming swift 5 transition, where static linking was replaced by dynamic linking the swift libraries as the preferred way, by Apple. furthermore Apple removed the static swift libs from their dev Tools starting with xcode 10.2/swift 5. because of ABI incompatibility dynamic linking for swift versions prior to 5 doesn't use the system lib path for the dynamic swift libs. for now static linking is still the default, but that will be changed when swift 5 support is added and swift 3 support is dropped. Fixes #6232
* vo_gpu: hwdec_vaapi: Add Vulkan interopPhilip Langdale2019-07-081-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | This change introduces a vulkan interop path for the vaapi hwdec. The basic principles are mostly the same as for EGL, with the exported dma_buf being imported by Vukan. The biggest difference is that we cannot reuse the texture as we do with OpenGL - there's no way to rebind a VkImage to a different piece of memory, as far as I can see. So, a new texture is created on each map call. I did not bother implementing a code path for the old libva API as I think it's safe to assume any system with a working vulkan driver will have access to a newer libva. Note that we are using separate layers for the vaapi surface, just as is done for EGL. This is because libplacebo doesn't support multiplane images. This change does not include format negotiation because no driver implements the vk_ext_image_drm_format_modifier extension that would be required to do that. In practice, the two formats we care about (nv12, p010) work correctly, so we are not blocked. A separate change had to be made in libplacebo to filter out non-fatal validation errors related to surface sizes due to the lack of format negotiation.
*