| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
| |
Make the version a separate argument, like in all other pkg-config
checks.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
The new function does exactly what we need. Replaces the old hack, which
created the vscore by running an empty script.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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]: http://clang.llvm.org/docs/JSONCompilationDatabase.html
|
|
|
|
|
| |
rst2pdf keeps having sporadic layouting failures, causing build
failures.
|
|
|
|
|
| |
It was accidentally broken. Tested by a NetBSD user. May help with other
BSDs.
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
Off by default, use --enable-win32-internal-pthreads .
This probably still needs a lot more testing. It also won't work on
Windows XP.
|
|
|
|
|
| |
It's just completely useless. We have good native support for all 3
desktop platforms, and ao_sdl or ao_openal as fallbacks.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Some IEC958 flags we use have been introduced in 2008, which makes
compilation fail on older systems.
|
| |
|
|
|
|
| |
Oops.
|
|
|
|
|
|
|
|
|
| |
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.)
|
|
|
|
| |
This way it’s near to it’s libmpv counterparts
|
| |
|
|
|
| |
thanks to @Nikoli
|
| |
|
|
|
|
|
| |
And fail building if not any of MingW-w64 or POSIX are found. Obviously,
mpv needs one of those 2.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Pretty useless and only good for testing.
Does not include any form of GLES support.
|
|
|
|
| |
Use TOOLS/osxbundle.py instead. It's just better and less hacky.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Shamelessly stolen from ffmpeg. It probably doesn't work - you can debug
it yourself.
|
|
|
|
|
|
| |
Apparently people want this. (???)
See #1214.
|
|
|
|
|
|
| |
It was disabled since the last release, and nobody complained loudly.
Further details see commit 4b5c3ea7.
|
|
|
|
|
|
| |
From: bugmen0t on github
Fixes #1207.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Actually doesn't remove the related flags so that one can still pass the
option with the option doing nothing.
|
| |
|
|
|
|
| |
Fixes #1164
|
|
|
|
| |
Also, use the zsh default location (rather than the Debian one).
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Don't build it, move it down the autoprobe list even if it's enabled. It
doesn't work well enough.
|
|
|
|
| |
Uh oh.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
A missing dependency entry made ./waf configure always fail.
|
|
|
|
|
| |
This is now unused. Get rid of it and all surrounding infrastructure,
and replace the remaining "wakeup pipe" with a semaphore.
|
|
|
|
|
|
|
| |
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
|