summaryrefslogtreecommitdiffstats
path: root/wscript
Commit message (Collapse)AuthorAgeFilesLines
* 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/osxbundle.py 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 syms.py. 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 syms.py). 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: http://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2020-0-201208-I!!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 req