summaryrefslogtreecommitdiffstats
path: root/wscript
Commit message (Collapse)AuthorAgeFilesLines
* libplacebo: bump minimum dependency to 4.157Niklas Haas2022-02-031-1/+1
| | | | | | This has been the latest stable release for about half a year now. This version in particular lets us get rid of all the deprecation warnings in the older code. (See the following commits)
* build: rename libplacebo version checkNiklas Haas2022-02-031-1/+1
| | | | | Rename from "libplacebo-v4" to "libplacebo-next" to more closely capture the intent, since this will become libplacebo v5 eventually (tm).
* wscript: bump libplacebo version requirement to 4.190Jan Ekström2022-02-021-2/+2
| | | | | | | | Was done in meson.build as part of a9cb2e2821adb40e7548e8233390e79706104041 , but the waf wscript was missed. This brings the two files in sync again.
* build: remove aviocontext bytes_read checkDudemanguy2022-01-251-9/+0
| | | | | | | | | | | | | | | | This define was always just a stopgap for that two month period (August 2021 - October 2021) where the bytes_read field in ffmpeg was completely missing. Before that time, it was a private member in a struct (which mpv used). Afterwards, it officially became public. Fortunately, the lack of this field never actually made it into a release, so it could have only possibly affected people building from the master branch. Since ffmpeg 5.0 came out recently, and it's been plenty of months since that two month window, we can go ahead and drop this check. This finishes up the work done in 78cfeee2b93830f2988508a653b508336147b79d. Sidenote: the cached ffmpeg version in the mingw ci were from that time period when the bytes_read field was missing. The N in the workflow is bumped to force a full rebuild and fresh clone of ffmpeg.
* ao_sndio: bugfix and small refactoring for #8314Andrew Krasavin2022-01-221-2/+1
| | | | | | | | Changes: * fixed hangups in the loop function and in some other cases * refactoring according to @michaelforney's recommendations in #8314 * a few minor and/or cosmetic changes * ability to build ao_sndio using meson
* ao_sndio: add this audio output againrim2022-01-221-0/+6
| | | | | | | | | Changes: - rewrite to use new internal MPV API; - code refactoring; - fix buffers size calculations; - buffer set to auto; - reset() - clean/reinit device only after errors;
* ao_pipewire: Add PipeWire audio backendThomas Weißschuh2022-01-171-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | The AO provides a way for mpv to directly submit audio to the PipeWire audio server. Doing this directly instead of going through the various compatibility layers provided by PipeWire has the following advantages: * It reduces complexity of going through the compatibility layers * It allows a richer integration between mpv and PipeWire (for example for metadata) * Some users report issues with the compatibility layers that to not occur with the native AO For now the AO is ordered after all the other relevant AOs, so it will most probably not be picked up by default. This is for the following reasons: * Currently it is not possible to detect if the PipeWire daemon that mpv connects to is actually driving the system audio. (https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1835) * It gives the AO time to stabilize before it is used by everyone. Based-on-patch-by: Oschowa <oschowa@web.de> Based-on-patch-by: Andreas Kempf <aakempf@gmail.com> Helped-by: Ivan <etircopyhdot@gmail.com>
* wscript: switch shaderc checks to pkgconfigsfan52021-12-191-3/+3
| | | | | | Shaderc has been shipping .pc files for almost three years and we all know of the advantages. If this turns out to be problematic the old checks can be re-added but I'd like to avoid doing this preemptively.
* context_drm_egl: use gbm_surface_create_with_modifiersPhilip Langdale2021-11-101-1/+1
| | | | | | | | | The GBM supporting nvidia driver doesn't support creating surfaces without modifiers and using modifiers is more and more recommended as the right way to do this. Enumerating modifiers is painfully verbose, but necessary if we are to allow the driver to pick the best possible one.
* vo_gpu_next: fix resource exhaustion on minimized windowsNiklas Haas2021-11-081-2/+2
| | | | | | | | This required an upstream API change to implement in a way that doesn't unnecessarily re-push or upload frames that won't be used. I consider this a big enough bug to justify bumping the minimum version for it. Closes #9401
* vo_gpu_next: add new libplacebo-based rendererNiklas Haas2021-11-031-0/+6
| | | | | | | | | | | | | As discussed in #8799, this will eventually replace vo_gpu. However, it is not yet complete. Currently missing: - OpenGL contexts - hardware decoding - blend-subtitles=video - VOCTRL_SCREENSHOT However, it's usable enough to cover most use cases, and as such is enough to start getting in some crucial testing.
* {wscript,demux_lavf}: clean up last bits of !FFMPEG_STRICT_ABIJan Ekström2021-10-261-4/+8
| | | | | | | | | | | | | | | | | The bytes_read struct member in AVIOContext is now officially public, so its usage no longer has to be specified as non-compliance with FFmpeg's ABI/API rules. That said, unfortunately there was a short period of time between August 2021 and October 2021 where the struct member did not exist in FFmpeg's git master, so keep a feature check for it alive for now to enable building with those versions. Thankfully, no release version of FFmpeg will be without this field, so it should be possible to drop this check with time. Finally, simplify the function in case the struct member is not found. After all, there is zero reason to iterate through the AVIO contexts if we cannot get the information we require.
* drm_common: utilize drmGetDevices when iterating over cardsJan Ekström2021-10-251-1/+1
| | | | | | | | | | | | Based on the idea behind emersion's change to drm_info (https://github.com/ascent12/drm_info/commit/869e789a645b92a99e592a230fe39b0c59a2cd7d). Lets us by default skip devices which are not capable of doing what the DRM master output requires (not primary devices), as some devices have card0 actually not be such. Negative part is that the number given to drm-connector is no longer a direct mapping against a file name.
* wscript: bump libplacebo minimum versionNiklas Haas2021-10-041-1/+1
| | | | Switching to v3 allows us to drop the use of deprecated/removed members.
* build: lua 5.1/5.2: use generic version namesAvi Halachmi (:avih)2021-10-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TL;DR: use --lua=XXX for pkg-config name XXX, e.g. --lua=lua-5.1 . For unversioned 'lua.pc', use the name luadef51/luadef52 . Autodetection remains the same (5.2 names, luajit, 5.1 names). The old names are still supported, but not auto-detected. Before this patch, if one wanted to choose a specific lua version when more than one is installed, then the names were a mess, e.g. 51obsd is also the name detected on Arch linux, and other (distro) names are also not unique to a specific distro/platform. So to ask mpv to choose the package name (specifically, the pkg-config file name), one needs to look at the mpv sources and find the (arbitrary) distro name which has the same lua version naming as they do on their own system, e.g. --lua=51obsd on Arch. This is a pain. Now we add generic names: - luadef51/luadef52 - generic pkg-config lua.pc (version is inside). - lua* - exactly the pkg-config name, e.g. --lua=lua-51 for lua-51.pc (the names are curated, e.g. --lua=foo won't detect foo.pc). - The legacy names (e.g. 51deb) are still supported, but undocumented, and the new generic names take precedence during auto-detection. The fact that the generic names all start with "lua" has an additional benefit that it shows right after "lua" at the output of mpv -v, while the old names start with numbers, so they're first at the list, making it hard to understand that e.g. "51obsd" is the lua version. None of these names are actually used at the mpv code. The C code checks the version using the lua headers (LUA_VERSION_NUM).
* build: enable strict FFmpeg ABI compatibility by defaultJan Ekström2021-09-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Its define (HAVE_FFMPEG_STRICT_ABI) is now utilized in a single location, where an internal libavformat struct member is utilized. This struct member is now (after around 10 years) finally removed from public visibility in FFmpeg's master. After a review of functionality, the information in bytes_read is passed onto the demuxer layer, and then utilized for {cache,hack}_unbuffered_read_bytes. This information is then utilized for: 1. Calculation of bytes_per_second in demux/demux.c::update_cache, which fills the information for properties "cache-speed" as well as "raw-input-rate" (of which stats.lua is the most prominent user). 2. bytes_per_second also affects how often update_cache is called in addition to the two locations it is called unconditionally in (read_packet, demux_update). In other words, the information provided does not appear to control crucial mpv functionality, but rather its lack would seem to mostly affect the speed of certain properties updating, or having valid values. For the former, stream size as well as timed metadata get updated in update_cache - although the demux layer does throttle the update of certain things to once per second in that function. For the latter, "cache-speed" and "raw-input-rate" lose read data statistics from AVIOContexts opened by the opened FFmpeg AVFormatContext itself, as opposed to the primary one - which goes through mpv's stream reading implementation. By enabling this feature, and disabling this abuse of private API lets users build mpv by default with the latest master FFmpeg, thus giving us the breathing room to look into some of the details of this case, and either decide to: 1. Post a patch to add this information back to FFmpeg proper. 2. Remove or replace this functionality in another manner. End user impact: Any IO not handled by mpv itself - but rather by IO contexts newly opened by the input format - is not visible through the properties "cache-speed" and "raw-input-rate". Examples of such input formats are the HLS and DASH readers in FFmpeg. Historical git references: - Addition of unbuffered_read_bytes: 4dfaa373846e79f1bc34b50426c1584b948c0eb6 - Rework to have the reporting function: ebf183eeec388d87a19415ee01970b21b6ef6832 Fixes #9159
* af_scaletempo2: use gcc vectors to speed up inner loopNiklas Haas2021-05-261-0/+4
| | | | | | | | | | This brings my scaletempo2 benchmark down from ~22s to ~7s on my machine (-march=native), and down to ~11s with a generic compile. Guarded behind an appropriate #ifdef to avoid being ableist against people who have the clinical need to run obscure platforms. Closes #8848
* ao_oss: add this audio output againrim2021-03-151-0/+5
| | | | | | | | | | | Changes: - code refactored; - mixer options removed; - new mpv sound API used; - add sound devices detect (mpv --audio-device=help will show all available devices); - only OSSv4 supported now; Tested on FreeBSD 12.2 amd64.
* vo_gpu: libplacebo: require v2.72.0Niklas Haas2021-02-231-1/+1
| | | | | | | | | | | | It's about a year old, and packaged pretty much everywhere that bothers to package libplacebo at all. Older versions are only a thing on LTS, which will probably also use older mpv so it works out. Starting with v2.72.0, libplacebo validates all of its parameters internally and turns them into function failures. Doing it twice is awfully redundant, so we can drop the parameter validation. Also allows us to drop some preprocessor macros.
* mac: drop build support for swift versions earlier than version 4.1der richter2021-01-131-1/+1
| | | | | | | | | | | | this drops support for swift <4.1 and with this support for xcode <=9.2. this was the last setup that is officially working on macOS 10.12. our old legacy build macOS 10.12 + xcode 9.2 is replaced by macOS 10.13 + xcode 9.4.1 with swift 4.1. the macOS 10.13 + xcode 10.1 VM is replaced by the latest macOS 10.14 + xcode 11.3.1 VM. this is the oldest version officially supported by Apple. this is in preparations for the following commit.
* build: fail configure if --lua is specified and Lua isn't foundPhilip Sequeira2020-12-221-3/+3
| | | | | | | | | Should result in: "You manually enabled the feature 'lua', but the autodetection check failed." The moved bit of code was probably intended to do that all along, but it was running too late, so the code that actually checked for Lua didn't know it was explicitly asked for and quietly disabled it if not found.
* build: restore support for non-pkgconfig zlibMia Herkt2020-12-061-1/+3
| | | | Some platforms do not offer a .pc file for zlib, e.g. Android.
* build: use pkg-config for zlibMia Herkt2020-12-061-3/+1
| | | | | | Zlib has had a .pc file since 2010, and the default search paths we use here can break the build on some distros (notably openSUSE Tumbleweed, which our Travis builds use). Just check pkg-config instead.
* build: fix macOS arm buildsder richter2020-11-221-1/+1
| | | | | | | | | | | remove the hardcoded swift target version and move the version restriction to configure. this was a bad idea anyway and could lead to mismatched object files between obj-c and swift. fix travis 10.12 legacy build. also update the SDK version parser to handle the new macOS 11 scheme. Fixes #8281
* video/out/vo_sixel.c: Implement sixel as a output deviceShreesh Adiga2020-11-071-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Based on the implementation of ffmpeg's sixel backend output written by Hayaki Saito https://github.com/saitoha/FFmpeg-SIXEL/blob/sixel/libavdevice/sixel.c Sixel is a protocol to display graphics in a terminal. This commit adds support to play videos on a sixel enabled terminal using libsixel. With --vo=sixel, the output will be in sixel format. The input frame will be scaled to the user specified resolution (--vo-sixel-width and --vo-sixel-height) using swscaler and then encoded using libsixel and output to the terminal. This method requires high cpu and there are high frame drops for 720p and higher resolution videos and might require using lesser colors and have drop in quality. Docs have all the supported options listed to fine tune the output quality. TODO: A few parameters of libsixel such as the sixel_encode_policy and the SIXEL_XTERM16 variables are hardcoded, might want to expose them as command line options. Also the initialization resolution is not automatic and if the user doesn't specify the dimensions, it picks 320x240 as the default resolution which is not optimal. So need to automatically pick the best fit resolution for the current open terminal window size.
* build: disable wayland if linux/input-event-codes.h isn’t availableEmmanuel Gil Peyrot2020-10-251-1/+5
| | | | | | | | | | | | | The wl_pointer interface defines button argument as “a button code as defined in the Linux kernel's linux/input-event-codes.h header file, e.g. BTN_LEFT.” We could #define these few buttons ourselves, but there is no system to test it on, so for now let’s disable Wayland support on them. This is a call to non-Linux system maintainers, please help test this backend on your system and report issues you find, or even working state.
* Revert "demux: add a POS"wm42020-10-081-5/+0
| | | | | | This reverts commit 4f18e7927bacd2e887f8cca48a967804ce7adf86. It was a mistake, and barely anyone needs this.
* demux: add a POSwm42020-10-081-0/+5
| | | | | | I regret doing this so much, it's fucking garbage. Fixes: #5100
* build: disable GLXwm42020-09-181-2/+3
| | | | | | Nobody needs this anymore. If not too many people complain, we'll remove this completely. Many already consider X11 and OpenGL legacy, so we don't need TWO X11/OpenGL backends.
* sd_ass: replace deprecated ASS_OVERRIDE_BIT_FONT_SIZEOneric2020-08-281-1/+1
| | | | This requires a slightly more recent libass than before
* build: change filenames of generated fileswm42020-06-041-1/+1
| | | | Force them into a more consistent naming schema.
* build: allow wlshm on more Wayland platforms after a6000d311421Jan Beich2020-05-181-6/+6
|
* osdep: remove posix_spawn() helpers and wrapperswm42020-05-151-16/+0
| | | | See previous commit. Farewell, useless shitty POSIX function.
* build: link against single EGL providerJan Palus2020-05-141-10/+9
| | | | | when building with rpi EGL is provided by librcmegl library and libEGL should not be linked then
* build: fallback to default pc file locations on rpiJan Palus2020-05-141-2/+4
|
* zimg: remove C11 aligned_alloc() requirementwm42020-05-011-6/+0
| | | | | It's not available on Windows because MinGW is fucking horrible and Microsoft are fucking assholes.
* build: restore BSD thread names after 9f461b85bfa3Jan Beich2020-04-231-1/+1
| | | | | | | | | | | | | | On FreeBSD non-POSIX threading functions are in a separate header. DragonFly and OpenBSD adopted FreeBSD header and extensions. ../test.c:3:3: error: implicit declaration of function 'pthread_set_name_np' is invalid in C99 [-Werror,-Wimplicit-function-declaration] { pthread_set_name_np(pthread_self(), "ducks"); return 0; } ^ ../osdep/threads.c:47:5: error: implicit declaration of function 'pthread_set_name_np' is invalid in C99 [-Werror,-Wimplicit-function-declaration] pthread_set_name_np(pthread_self(), tname); ^ Signed-off-by: Jan Beich <jbeich@FreeBSD.org>
* build: detect VT_GETMODE on FreeBSD and DragonFlyJan Beich2020-04-221-1/+7
| | | | | | | | | | | | | | | | $ ./waf configure Checking for vt.h : no Checking for DRM : vt.h not found [...] ../test.c:1:10: fatal error: 'sys/vt.h' file not found #include <sys/vt.h> ^~~~~~~~~~ $ build/mpv --gpu-context=drm /path/to/video.mkv Error parsing option gpu-context (option parameter could not be parsed) Setting commandline option --gpu-context=drm failed. Exiting... (Fatal error)
* build: only check for EGL pc in one build optionNicolas F2020-04-021-7/+5
| | | | | | | | | | | | | | | | | Previously, EGL as provided by a pkg-config was checked for independently in several places. The effect this had is that --disable-egl would not actually disable EGL from the build, as this only affected the "egl" option relied upon by egl-x11. wayland-gl and egl-drm did their own EGL checks. By making wayland-gl and drm-egl depend on egl instead, we fix this behaviour and can simplify egl-helpers a bit, as we can now simply check whether egl or one of the other features providing some non-pc egl is enabled, instead of checking every single thing that might be pulling in egl. Future work could make the "egl" option just be a catchall for any EGL implementation, so that brcmegl and angle and Android can piggyback on the egl option as well.
* ao_oss: remove this audio outputwm42020-03-281-5/+0
| | | | | | | | | | Ancient Linux audio output. Apparently it survived until now, because some BSDs (but not all) had use of this. But these should work with ao_sdl or ao_openal too (that's why these AOs exist after all). ao_oss itself has the problem that it's virtually unmaintainable from my point of view due to all the subtle (or non-subtle) difference. Look at the ifdef mess and the multiple code paths (that shouldn't exist) in the removed source code.
* ao_rsound: remove this audio outputwm42020-03-281-4/+0
| | | | | | I wonder what this even is. I've never heard of anyone using it, and can't find a corresponding library that actually builds with it. Good enough to remove.
* ao_sndio: remove this audio outputwm42020-03-281-6/+0
| | | | | | It was always marked as "experimental", and had inherent problems that were never fixed. It was disabled by default, and I don't think anyone is using it.
* input: remove deprecated --input-file optionwm42020-03-281-5/+0
| | | | | This was deprecated 2 releases ago. The deprecation changelog entry says that there are no plans to remove it short-term, but I guess I lied.
* build: make libass non-optionalwm42020-03-181-13/+2
| | | | | | | | | | | | | | Using mpv without libass isn't really supported, since it's not only used to display ASS subtitles, but all text subtitles, and even OSD. At least 1 user complained that the player printed a warning if built without libass. Avoid trying to create the impression that using this software without libass is in any way supported or desirable, and make it fully mandatory. (As far as making dependencies optional goes, I'd rather make ffmpeg optional, which is an oversized and bloated library, rather than something tiny like libass.)
* osdep: add a pthread debugging wrapperwm42020-03-181-0/+9
| | | | | | | | | | | | | | | | | | | | Because pthread failures are virtually undebuggable (which sure is pretty strange, given all these heavy instrumentation tools these days). Of course it affects only files which include osdep/threads.h. I'm departing from the usual way to add symbols with config.h and using "#if", and defining it on the compiler command line + "#ifdef" because I don't want to include config.h from a header (which would be necessary in this case) to keep things slightly cleaner. Maybe this is misguided, but still. This would have been easier if mpv defined its own wrappers for all thread functions. But we don't (which to be honest is probably better than e.g. going crazy like VLC and essentially reimplementing everything). This seems to be a good compromise. Since it's off by default and basically a developer tool, the minor undefined behavior (redefining reserved symbols) isn't much of an issue.
* build: make C11 atomics mandatorywm42020-03-131-14/+5
| | | | | | | | | | The emulation is pretty bad, and C11 compilers are everywhere now. It's time to retire the emulation, which was always meant as temporary hack for transition. In theory, a user can still use --disable-stdatomic to enable the emulation code, but that's sort of hidden. Actual support will be removed after the next release or so.
* build: disable RPI vendor blob auto-detectionwm42020-03-051-0/+1
| | | | | | | Apparently this bit-rotted a lot, and now causes more problems that it helps. In particular picking up broadcom EGL instead of Mesa EGL will break things. With RPI getting proper Mesa/DRM/V4L support, this problem should solve itself as well.
* stream_smb: remove thiswm42020-03-051-7/+0
| | | | | | | | | | | This required libsmbclient, which is a heavy dependency, and as a library, has all kinds of problems. For one, the API requires completely unacceptable global state (in particular, leaks auth state), and is not thread-safe (meaning concurrent reads to multiple files block each other). There are better replacements: you can use the Linux kernel's builtin CIFS support, fusesmb, or contribute supoport for libdsm.
* build: remove fchmod() checkwm42020-02-191-4/+0
| | | | | | This is UNIX-only code, and this function has been in POSIX since forever. Even Android has it. The test should be unnecessary, so remove it.
* Remove remains of Libav compatibilitywm42020-02-161-64/+8
| | | | | | | | | | | | | | |