2013-07-16 11:28:28 +00:00
# vi: ft=python
import sys, os, re
sys.path.insert(0, os.path.join(os.getcwd(), 'waftools'))
2013-11-23 09:58:19 +00:00
sys.path.insert(0, os.getcwd())
2018-10-27 15:27:01 +00:00
from shlex import split
2013-07-16 11:28:28 +00:00
from waflib.Configure import conf
2016-10-21 06:51:17 +00:00
from waflib.Tools import c_preproc
2023-01-24 03:45:43 +00:00
from waflib.Tools.compiler_c import c_compiler
2013-07-16 11:28:28 +00:00
from waflib import Utils
from waftools.checks.generic import *
from waftools.checks.custom import *
2016-10-21 06:51:17 +00:00
c_preproc.go_absolute=True # enable system folders
c_preproc.standard_includes.append('/usr/local/include')
2023-01-24 03:45:43 +00:00
c_compiler['win32'].remove('msvc')
2018-07-01 19:09:45 +00:00
APPNAME = 'mpv'
2017-06-27 11:47:46 +00:00
"""
Dependency identifiers (for win32 vs. Unix):
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
wscript / C source meaning
2017-06-27 11:47:46 +00:00
--------------------------------------------------------------------------
posix / HAVE_POSIX: defined on Linux, OSX, Cygwin
(Cygwin emulates POSIX APIs on Windows)
mingw / __MINGW32__: defined if posix is not defined
(Windows without Cygwin)
os-win32 / _WIN32: defined if basic windows.h API is available
win32-desktop / HAVE_WIN32_DESKTOP: defined if desktop windows.h API is available
2017-06-27 11:50:58 +00:00
uwp / HAVE_UWP: defined if building for UWP (basic Windows only)
2017-06-27 11:47:46 +00:00
"""
2013-07-16 11:28:28 +00:00
build_options = [
{
2017-10-10 14:21:01 +00:00
'name': '--lgpl',
'desc': 'LGPL (version 2.1 or later) build',
2017-09-21 11:50:18 +00:00
'default': 'disable',
'func': check_true,
}, {
'name': 'gpl',
2017-10-10 14:21:01 +00:00
'desc': 'GPL (version 2 or later) build',
'deps': '!lgpl',
2017-09-21 11:50:18 +00:00
'func': check_true,
}, {
2014-11-28 14:55:54 +00:00
'name': '--cplayer',
'desc': 'mpv CLI player',
'default': 'enable',
'func': check_true
}, {
2014-03-11 22:56:19 +00:00
'name': '--libmpv-shared',
2014-02-24 10:50:21 +00:00
'desc': 'shared library',
2014-02-10 20:25:22 +00:00
'default': 'disable',
'func': check_true
2014-06-16 09:22:46 +00:00
}, {
'name': '--libmpv-static',
'desc': 'static library',
'default': 'disable',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': '!libmpv-shared',
2014-06-16 09:22:46 +00:00
'func': check_true
2014-02-10 20:25:22 +00:00
}, {
2013-07-16 11:28:28 +00:00
'name': '--static-build',
'desc': 'static build',
'default': 'disable',
'func': check_true
}, {
'name': '--build-date',
'desc': 'whether to include binary compile time',
'default': 'enable',
'func': check_true
2014-07-19 16:45:43 +00:00
}, {
'name': '--optimize',
'desc': 'whether to optimize',
'default': 'enable',
'func': check_true
2013-07-16 11:28:28 +00:00
}, {
'name': '--debug-build',
'desc': 'whether to compile-in debugging information',
'default': 'enable',
'func': check_true
test: make tests part of the mpv binary
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.
2019-11-07 21:42:14 +00:00
}, {
'name': '--tests',
'desc': 'unit tests (development only)',
'default': 'disable',
'func': check_true
2019-11-07 23:43:46 +00:00
}, {
# Reminder: normally always built, but enabled by MPV_LEAK_REPORT.
# Building it can be disabled only by defining NDEBUG through CFLAGS.
'name': '--ta-leak-report',
'desc': 'enable ta leak report by default (development only)',
'default': 'disable',
'func': check_true
2013-07-16 11:28:28 +00:00
}, {
'name': '--manpage-build',
'desc': 'manpage generation',
'func': check_ctx_vars('RST2MAN')
2015-12-29 19:57:09 +00:00
}, {
'name': '--html-build',
'desc': 'html manual generation',
'func': check_ctx_vars('RST2HTML'),
'default': 'disable',
2013-07-16 11:28:28 +00:00
}, {
'name': '--pdf-build',
'desc': 'pdf manual generation',
2014-01-08 15:00:40 +00:00
'func': check_ctx_vars('RST2PDF'),
2015-02-02 11:06:06 +00:00
'default': 'disable',
2013-07-16 11:28:28 +00:00
}, {
'name': 'libdl',
'desc': 'dynamic loader',
'func': check_libs(['dl'], check_statement('dlfcn.h', 'dlopen("", 0)'))
2017-01-12 16:37:11 +00:00
}, {
'name': '--cplugins',
'desc': 'C plugins',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'libdl && !os-win32',
2017-03-02 13:40:14 +00:00
'func': check_cc(linkflags=['-rdynamic']),
2013-12-29 16:34:31 +00:00
}, {
2014-04-19 15:09:24 +00:00
# does nothing - left for backward and forward compatibility
2013-12-29 16:34:31 +00:00
'name': '--asm',
2014-04-19 15:09:24 +00:00
'desc': 'inline assembly (currently without effect)',
2013-12-29 16:34:31 +00:00
'default': 'enable',
'func': check_true,
2021-05-22 19:03:52 +00:00
}, {
'name': '--vector',
'desc': 'GCC vector instructions',
'func': check_statement([], 'float v __attribute__((vector_size(32)))'),
2015-02-05 20:00:23 +00:00
}, {
'name': '--clang-database',
'desc': 'generate a clang compilation database',
'func': check_true,
'default': 'disable',
2019-04-21 14:57:02 +00:00
} , {
'name': '--swift-static',
'desc': 'static Swift linking',
'deps': 'os-darwin',
2019-07-20 10:16:37 +00:00
'func': check_ctx_vars('SWIFT_LIB_STATIC'),
'default': 'disable'
2013-07-16 11:28:28 +00:00
}
]
main_dependencies = [
{
'name': 'noexecstack',
'desc': 'compiler support for noexecstack',
'func': check_cc(linkflags='-Wl,-z,noexecstack')
}, {
'name': 'noexecstack',
'desc': 'linker support for --nxcompat --no-seh --dynamicbase',
'func': check_cc(linkflags=['-Wl,--nxcompat', '-Wl,--no-seh', '-Wl,--dynamicbase'])
} , {
'name': 'libm',
'desc': '-lm',
'func': check_cc(lib='m')
2014-09-14 14:21:04 +00:00
}, {
'name': 'mingw',
'desc': 'MinGW',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'os-win32',
2016-11-17 11:46:18 +00:00
'func': check_statement('stdlib.h', 'int x = __MINGW32__;'
2014-11-17 22:47:30 +00:00
'int y = __MINGW64_VERSION_MAJOR'),
}, {
'name': 'posix',
'desc': 'POSIX environment',
2019-06-29 23:23:20 +00:00
'func': check_statement(['unistd.h'], 'long x = _POSIX_VERSION'),
2017-08-04 21:42:35 +00:00
}, {
'name': '--android',
'desc': 'Android environment',
2018-07-21 08:38:54 +00:00
'func': check_statement('android/api-level.h', '(void)__ANDROID__'), # arbitrary android-specific header
2021-10-18 14:50:39 +00:00
}, {
'name': '--android-media-ndk',
'desc': 'Android Media APIs',
'deps': 'android',
# header only, library is dynamically loaded
'func': check_statement('media/NdkImageReader.h', 'int x = AIMAGE_FORMAT_PRIVATE'),
2019-09-26 17:30:48 +00:00
}, {
'name': '--tvos',
'desc': 'tvOS environment',
2019-09-27 15:08:42 +00:00
'func': check_statement(
['TargetConditionals.h', 'assert.h'],
'static_assert(TARGET_OS_TV, "TARGET_OS_TV defined to zero!")'
),
2018-07-21 08:38:54 +00:00
}, {
'name': '--egl-android',
'desc': 'Android EGL support',
'deps': 'android',
'groups': [ 'gl' ],
'func': check_cc(lib=['android', 'EGL']),
2014-11-17 22:47:30 +00:00
}, {
'name': 'posix-or-mingw',
2015-03-11 22:40:54 +00:00
'desc': 'development environment',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'posix || mingw',
2014-11-17 22:47:30 +00:00
'func': check_true,
'req': True,
'fmsg': 'Unable to find either POSIX or MinGW-w64 environment, ' \
'or compiler does not work.',
2018-07-08 15:05:13 +00:00
}, {
'name': '--swift',
'desc': 'macOS Swift build tools',
'deps': 'os-darwin',
2020-12-25 13:47:35 +00:00
'func': compose_checks(check_swift('4.1'), check_macos_sdk('10.10')),
2017-06-27 11:50:58 +00:00
}, {
'name': '--uwp',
'desc': 'Universal Windows Platform',
'default': 'disable',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'os-win32 && mingw && !cplayer',
2017-06-27 11:50:58 +00:00
'func': check_cc(lib=['windowsapp']),
2015-03-11 22:40:54 +00:00
}, {
2017-06-27 11:47:46 +00:00
'name': 'win32-desktop',
'desc': 'win32 desktop APIs',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': '(os-win32 || os-cygwin) && !uwp',
2017-10-30 12:01:20 +00:00
'func': check_cc(lib=['winmm', 'gdi32', 'ole32', 'uuid', 'avrt', 'dwmapi', 'version']),
2015-01-01 14:10:42 +00:00
}, {
'name': '--win32-internal-pthreads',
'desc': 'internal pthread wrapper for win32 (Vista+)',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'os-win32 && !posix',
2015-01-01 14:10:42 +00:00
'func': check_true,
2013-07-16 11:28:28 +00:00
}, {
2013-11-28 18:28:38 +00:00
'name': 'pthreads',
2013-07-16 11:28:28 +00:00
'desc': 'POSIX threads',
'func': check_pthreads,
2013-11-28 18:28:38 +00:00
'req': True,
'fmsg': 'Unable to find pthreads support.'
2020-03-18 21:34:48 +00:00
}, {
# NB: this works only if a source file includes osdep/threads.h
# also, technically, triggers undefined behavior (reserved names)
'name': '--pthread-debug',
'desc': 'pthread runtime debugging wrappers',
'default': 'disable',
'func': check_cc(cflags='-DMP_PTHREAD_DEBUG'),
# The win32 wrapper defines pthreads symbols as macros only.
'deps_neg': 'win32-internal-pthreads',
2016-09-06 18:13:30 +00:00
}, {
2020-03-12 11:52:51 +00:00
'name': '--stdatomic',
'desc': 'C11 stdatomic.h',
2014-06-17 18:03:19 +00:00
'func': check_libs(['atomic'],
2014-05-20 23:04:47 +00:00
check_statement('stdatomic.h',
2014-06-17 18:03:19 +00:00
'atomic_int_least64_t test = ATOMIC_VAR_INIT(123);'
2020-03-12 11:52:51 +00:00
'atomic_fetch_add(&test, 1)')),
'req': True,
'fmsg': 'C11 atomics are required; you may need a newer compiler',
2013-07-16 11:28:28 +00:00
}, {
'name': 'librt',
'desc': 'linking with -lrt',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'pthreads',
2013-07-16 11:28:28 +00:00
'func': check_cc(lib='rt')
}, {
'name': '--iconv',
'desc': 'iconv',
'func': check_iconv,
'req': True,
'fmsg': "Unable to find iconv which should be part of a standard \
compilation environment. Aborting. If you really mean to compile without \
iconv support use --disable-iconv.",
}, {
'name': 'dos-paths',
'desc': 'w32/dos paths',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'os-win32 || os-cygwin',
2013-07-16 11:28:28 +00:00
'func': check_true
2017-08-04 21:47:16 +00:00
}, {
'name': 'glob-posix',
'desc': 'glob() POSIX support',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': '!(os-win32 || os-cygwin)',
2017-08-04 21:47:16 +00:00
'func': check_statement('glob.h', 'glob("filename", 0, 0, 0)'),
2013-07-16 11:28:28 +00:00
}, {
2017-06-27 10:37:47 +00:00
'name': 'glob-win32',
2013-07-16 11:28:28 +00:00
'desc': 'glob() win32 replacement',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': '!posix && (os-win32 || os-cygwin)',
2013-07-16 11:28:28 +00:00
'func': check_true
2017-08-04 21:47:16 +00:00
}, {
'name': 'glob',
'desc': 'any glob() support',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'glob-posix || glob-win32',
2017-08-04 21:47:16 +00:00
'func': check_true,
2015-04-19 07:09:37 +00:00
}, {
'name': 'vt.h',
'desc': 'vt.h',
'func': check_statement(['sys/vt.h', 'sys/ioctl.h'],
'int m; ioctl(0, VT_GETMODE, &m)'),
2019-09-21 20:17:32 +00:00
}, {
'name': 'consio.h',
'desc': 'consio.h',
'deps': '!vt.h',
'func': check_statement(['sys/consio.h', 'sys/ioctl.h'],
'int m; ioctl(0, VT_GETMODE, &m)'),
vo_opengl: add DRM EGL backend
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>
2015-11-07 18:06:57 +00:00
}, {
'name': 'gbm.h',
'desc': 'gbm.h',
'func': check_cc(header_name=['stdio.h', 'gbm.h']),
2014-10-19 21:32:34 +00:00
}, {
'name': 'glibc-thread-name',
'desc': 'GLIBC API for setting thread name',
'func': check_statement('pthread.h',
'pthread_setname_np(pthread_self(), "ducks")',
use=['pthreads']),
}, {
'name': 'osx-thread-name',
'desc': 'OSX API for setting thread name',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': '!glibc-thread-name',
2014-10-19 21:32:34 +00:00
'func': check_statement('pthread.h',
'pthread_setname_np("ducks")', use=['pthreads']),
}, {
'name': 'bsd-thread-name',
'desc': 'BSD API for setting thread name',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': '!(glibc-thread-name || osx-thread-name)',
2019-09-21 20:05:35 +00:00
'func': check_statement(['pthread.h', 'pthread_np.h'],
2017-06-22 08:32:48 +00:00
'pthread_set_name_np(pthread_self(), "ducks")',
2014-10-21 23:02:55 +00:00
use=['pthreads']),
2014-02-17 11:51:38 +00:00
}, {
'name': 'bsd-fstatfs',
'desc': "BSD's fstatfs()",
'func': check_statement(['sys/param.h', 'sys/mount.h'],
2014-03-11 23:49:16 +00:00
'struct statfs fs; fstatfs(0, &fs); fs.f_fstypename')
2014-03-11 19:27:50 +00:00
}, {
'name': 'linux-fstatfs',
'desc': "Linux's fstatfs()",
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'os-linux',
2014-03-11 19:27:50 +00:00
'func': check_statement('sys/vfs.h',
'struct statfs fs; fstatfs(0, &fs); fs.f_namelen')
2020-10-25 12:06:41 +00:00
}, {
'name': 'linux-input-event-codes',
'desc': "Linux's input-event-codes.h",
'func': check_cc(header_name=['linux/input-event-codes.h']),
2014-10-11 23:31:20 +00:00
}, {
'name' : '--lua',
'desc' : 'Lua',
'func': check_lua,
2014-12-13 16:27:47 +00:00
}, {
'name' : '--javascript',
'desc' : 'Javascript (MuJS backend)',
2017-06-16 12:24:24 +00:00
'func': check_pkg_config('mujs', '>= 1.0.0'),
2013-07-16 11:28:28 +00:00
}, {
2020-03-18 21:45:59 +00:00
'name': 'libass',
2013-07-16 11:28:28 +00:00
'desc': 'SSA/ASS support',
2020-08-28 13:59:04 +00:00
'func': check_pkg_config('libass', '>= 0.12.2'),
2013-07-16 11:28:28 +00:00
'req': True,
2015-02-21 16:13:38 +00:00
'fmsg': "Unable to find development files for libass, or the version " +
2020-03-18 21:45:59 +00:00
"found is too old. Aborting."
2013-07-16 11:28:28 +00:00
}, {
2017-06-28 13:33:21 +00:00
'name': '--zlib',
2013-07-16 11:28:28 +00:00
'desc': 'zlib',
2020-12-06 00:16:12 +00:00
'func': any_check(check_pkg_config('zlib'),
check_libs(['z'], check_statement('zlib.h', 'inflate(0, Z_NO_FLUSH)'))),
2013-07-16 11:28:28 +00:00
'req': True,
2020-12-06 00:16:12 +00:00
'fmsg': 'Unable to find development files for zlib.'
2014-07-14 23:49:02 +00:00
}, {
'name': '--libbluray',
'desc': 'Bluray support',
'func': check_pkg_config('libbluray', '>= 0.3.0'),
2017-03-15 00:20:47 +00:00
#'default': 'disable',
2014-07-14 23:49:02 +00:00
}, {
'name': '--dvdnav',
'desc': 'dvdnav support',
2017-09-21 11:50:18 +00:00
'deps': 'gpl',
2017-03-31 15:43:20 +00:00
'func': check_pkg_config('dvdnav', '>= 4.2.0',
'dvdread', '>= 4.1.0'),
2017-03-15 00:20:47 +00:00
'default': 'disable',
2013-07-16 11:28:28 +00:00
}, {
'name': '--cdda',
'desc': 'cdda support (libcdio)',
2017-09-21 11:50:18 +00:00
'deps': 'gpl',
2013-07-16 11:28:28 +00:00
'func': check_pkg_config('libcdio_paranoia'),
2017-03-15 00:20:47 +00:00
'default': 'disable',
2015-08-01 22:12:36 +00:00
}, {
'name': '--uchardet',
'desc': 'uchardet support',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'iconv',
2015-08-01 22:12:36 +00:00
'func': check_pkg_config('uchardet'),
2015-02-10 22:50:17 +00:00
}, {
'name': '--rubberband',
'desc': 'librubberband support',
'func': check_pkg_config('rubberband', '>= 1.8.0'),
video: add vf_fingerprint and a skip-logo script
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
2019-07-15 01:20:40 +00:00
}, {
'name': '--zimg',
2019-12-06 18:16:30 +00:00
'desc': 'libzimg support (high quality software scaler)',
video: add vf_fingerprint and a skip-logo script
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
2019-07-15 01:20:40 +00:00
'func': check_pkg_config('zimg', '>= 2.9'),
2013-07-16 11:28:28 +00:00
}, {
'name': '--lcms2',
'desc': 'LCMS2 support',
2014-06-16 14:57:19 +00:00
'func': check_pkg_config('lcms2', '>= 2.6'),
2014-04-12 15:51:19 +00:00
}, {
'name': '--vapoursynth',
2019-06-29 23:20:06 +00:00
'desc': 'VapourSynth filter bridge',
2015-09-22 09:46:57 +00:00
'func': check_pkg_config('vapoursynth', '>= 24',
'vapoursynth-script', '>= 23'),
stream: libarchive wrapper for reading compressed archives
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.
2015-08-16 22:55:26 +00:00
}, {
'name': '--libarchive',
'desc': 'libarchive wrapper for reading zip files and more',
2020-01-07 21:31:35 +00:00
'func': check_pkg_config('libarchive >= 3.4.0'),
Remove classic Linux analog TV support, and DVB runtime controls
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.
2019-09-13 15:16:18 +00:00
}, {
'name': '--dvbin',
'desc': 'DVB input module',
'deps': 'gpl',
'func': check_true,
'default': 'disable',
2019-10-22 14:41:19 +00:00
}, {
'name': '--sdl2',
'desc': 'SDL2',
'func': check_pkg_config('sdl2'),
'default': 'disable',
}, {
'name': '--sdl2-gamepad',
'desc': 'SDL2 gamepad input',
'deps': 'sdl2',
'func': check_true,
2022-04-29 03:16:13 +00:00
}, {
'name': 'jpegxl',
'desc': 'JPEG XL support via libavcodec',
'func': check_pkg_config('libavcodec >= 59.27.100'),
2022-07-16 01:17:41 +00:00
}, {
'name': 'rubberband-3',
'desc': 'new engine support for librubberband',
'func': check_pkg_config('rubberband >= 3.0.0'),
2013-07-16 11:28:28 +00:00
}
]
2016-06-09 19:05:33 +00:00
libav_dependencies = [
2013-07-16 11:28:28 +00:00
{
2017-12-05 08:25:00 +00:00
'name': 'ffmpeg',
Remove remains of Libav compatibility
Libav seems rather dead: no release for 2 years, no new git commits in
master for almost a year (with one exception ~6 months ago). From what I
can tell, some developers resigned themselves to the horrifying idea to
post patches to ffmpeg-devel instead, while the rest of the developers
went on to greener pastures.
Libav was a better project than FFmpeg. Unfortunately, FFmpeg won,
because it managed to keep the name and website. Libav was pushed more
and more into obscurity: while there was initially a big push for Libav,
FFmpeg just remained "in place" and visible for most people. FFmpeg was
slowly draining all manpower and energy from Libav. A big part of this
was that FFmpeg stole code from Libav (regular merges of the entire
Libav git tree), making it some sort of Frankenstein mirror of Libav,
think decaying zombie with additional legs ("features") nailed to it.
"Stealing" surely is the wrong word; I'm just aping the language that
some of the FFmpeg members used to use. All that is in the past now, I'm
probably the only person left who is annoyed by this, and with this
commit I'm putting this decade long problem finally to an end. I just
thought I'd express my annoyance about this fucking shitshow one last
time.
The most intrusive change in this commit is the resample filter, which
originally used libavresample. Since the FFmpeg developer refused to
enable libavresample by default for drama reasons, and the API was
slightly different, so the filter used some big preprocessor mess to
make it compatible to libswresample. All that falls away now. The
simplification to the build system is also significant.
2020-02-16 14:14:55 +00:00
'desc': 'FFmpeg library',
2022-11-29 19:16:57 +00:00
'func': check_pkg_config('libavutil', '>= 56.70.100',
'libavcodec', '>= 58.134.100',
'libavformat', '>= 58.76.100',
'libswscale', '>= 5.9.100',
'libavfilter', '>= 7.110.100',
'libswresample', '>= 3.9.100'),
2013-07-16 11:28:28 +00:00
'req': True,
'fmsg': "Unable to find development files for some of the required \
Remove remains of Libav compatibility
Libav seems rather dead: no release for 2 years, no new git commits in
master for almost a year (with one exception ~6 months ago). From what I
can tell, some developers resigned themselves to the horrifying idea to
post patches to ffmpeg-devel instead, while the rest of the developers
went on to greener pastures.
Libav was a better project than FFmpeg. Unfortunately, FFmpeg won,
because it managed to keep the name and website. Libav was pushed more
and more into obscurity: while there was initially a big push for Libav,
FFmpeg just remained "in place" and visible for most people. FFmpeg was
slowly draining all manpower and energy from Libav. A big part of this
was that FFmpeg stole code from Libav (regular merges of the entire
Libav git tree), making it some sort of Frankenstein mirror of Libav,
think decaying zombie with additional legs ("features") nailed to it.
"Stealing" surely is the wrong word; I'm just aping the language that
some of the FFmpeg members used to use. All that is in the past now, I'm
probably the only person left who is annoyed by this, and with this
commit I'm putting this decade long problem finally to an end. I just
thought I'd express my annoyance about this fucking shitshow one last
time.
The most intrusive change in this commit is the resample filter, which
originally used libavresample. Since the FFmpeg developer refused to
enable libavresample by default for drama reasons, and the API was
slightly different, so the filter used some big preprocessor mess to
make it compatible to libswresample. All that falls away now. The
simplification to the build system is also significant.
2020-02-16 14:14:55 +00:00
FFmpeg libraries. Git master is recommended."
2022-06-01 20:50:49 +00:00
}, {
'name': 'av-channel-layout',
'desc': 'FFmpeg AVChannelLayout API',
'func': check_pkg_config('libavutil', '>= 57.24.100'),
build: reduce worst case with mismatching FFmpeg pkg-config 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.
2015-01-20 14:53:40 +00:00
}, {
'name': '--libavdevice',
'desc': 'libavdevice',
2022-11-29 19:16:57 +00:00
'func': check_pkg_config('libavdevice', '>= 58.13.100'),
2017-10-30 19:55:42 +00:00
}
2013-07-16 11:28:28 +00:00
]
audio_output_features = [
{
2019-10-22 14:41:19 +00:00
'name': '--sdl2-audio',
'desc': 'SDL2 audio output',
'deps': 'sdl2',
'func': check_true,
2020-11-24 01:22:40 +00:00
}, {
'name': '--oss-audio',
'desc': 'OSSv4 audio output',
'func': check_statement(['sys/soundcard.h'], 'int x = SNDCTL_DSP_SETPLAYVOL'),
'deps': 'posix && gpl',
2022-01-06 20:54:21 +00:00
}, {
'name': '--pipewire',
'desc': 'PipeWire audio output',
2022-10-26 13:45:53 +00:00
'func': check_pkg_config('libpipewire-0.3', '>= 0.3.19')
2020-11-25 03:10:19 +00:00
}, {
'name': '--sndio',
'desc': 'sndio audio input/output',
2022-01-11 16:23:52 +00:00
'func': check_pkg_config('sndio'),
2020-11-25 03:10:19 +00:00
'default': 'disable'
2013-07-16 11:28:28 +00:00
}, {
'name': '--pulse',
'desc': 'PulseAudio audio output',
2014-07-26 20:40:27 +00:00
'func': check_pkg_config('libpulse', '>= 1.0')
2013-07-16 11:28:28 +00:00
}, {
'name': '--jack',
'desc': 'JACK audio output',
2017-09-21 11:50:18 +00:00
'deps': 'gpl',
2013-07-16 11:28:28 +00:00
'func': check_pkg_config('jack'),
}, {
'name': '--openal',
'desc': 'OpenAL audio output',
2018-08-16 01:30:02 +00:00
'func': check_pkg_config('openal', '>= 1.13'),
2013-07-16 11:28:28 +00:00
'default': 'disable'
2016-02-14 17:03:47 +00:00
}, {
'name': '--opensles',
'desc': 'OpenSL ES audio output',
'func': check_statement('SLES/OpenSLES.h', 'slCreateEngine', lib="OpenSLES"),
2013-07-16 11:28:28 +00:00
}, {
'name': '--alsa',
'desc': 'ALSA audio output',
2015-02-23 14:56:55 +00:00
'func': check_pkg_config('alsa', '>= 1.0.18'),
2013-07-16 11:28:28 +00:00
}, {
'name': '--coreaudio',
'desc': 'CoreAudio audio output',
'func': check_cc(
fragment=load_fragment('coreaudio.c'),
2013-12-06 09:17:20 +00:00
framework_name=['CoreFoundation', 'CoreAudio', 'AudioUnit', 'AudioToolbox'])
2016-10-19 22:08:48 +00:00
}, {
'name': '--audiounit',
'desc': 'AudioUnit output for iOS',
'func': check_cc(
fragment=load_fragment('audiounit.c'),
framework_name=['Foundation', 'AudioToolbox'])
2013-07-16 11:28:28 +00:00
}, {
'name': '--wasapi',
'desc': 'WASAPI audio output',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'os-win32 || os-cygwin',
2015-03-11 22:40:54 +00:00
'func': check_cc(fragment=load_fragment('wasapi.c')),
2013-07-16 11:28:28 +00:00
}
]
video_output_features = [
{
2019-10-22 14:41:19 +00:00
'name': '--sdl2-video',
'desc': 'SDL2 video output',
'deps': 'sdl2',
2019-10-25 20:02:16 +00:00
'deps_neg': 'cocoa',
2019-10-22 14:41:19 +00:00
'func': check_true,
}, {
2013-07-16 11:28:28 +00:00
'name': '--cocoa',
'desc': 'Cocoa',
2014-01-02 19:34:14 +00:00
'func': check_cocoa
vo_opengl: add DRM EGL backend
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>
2015-11-07 18:06:57 +00:00
}, {
'name': '--drm',
'desc': 'DRM',
2019-09-21 20:17:32 +00:00
'deps': 'vt.h || consio.h',
2021-01-18 21:28:28 +00:00
'func': check_pkg_config('libdrm', '>= 2.4.75'),
vo_opengl: add DRM EGL backend
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>
2015-11-07 18:06:57 +00:00
}, {
'name': '--gbm',
'desc': 'GBM',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'gbm.h',
2021-11-03 03:26:47 +00:00
'func': check_pkg_config('gbm', '>= 17.1.0'),
2017-10-01 20:16:49 +00:00
} , {
2022-10-16 14:36:21 +00:00
'name': 'wayland-scanner',
2017-10-01 20:16:49 +00:00
'desc': 'wayland-scanner',
'func': check_program('wayland-scanner', 'WAYSCAN')
} , {
2022-10-16 14:36:21 +00:00
'name': 'wayland-protocols',
2017-10-01 20:16:49 +00:00
'desc': 'wayland-protocols',
'func': check_wl_protocols
2013-07-16 11:28:28 +00:00
} , {
'name': '--wayland',
'desc': 'Wayland',
2020-10-25 12:06:41 +00:00
'deps': 'wayland-protocols && wayland-scanner && linux-input-event-codes',
2019-09-19 20:37:00 +00:00
'func': check_pkg_config('wayland-client', '>= 1.15.0',
'wayland-cursor', '>= 1.15.0',
2013-07-16 11:28:28 +00:00
'xkbcommon', '>= 0.3.0'),
2022-10-29 18:07:34 +00:00
} , {
'name': 'wayland-protocols-1-24',
'desc': 'wayland-protocols version 1.24+',
'deps': 'wayland',
'func': check_pkg_config('wayland-protocols >= 1.24'),
wayland: add support for content-type protocol
The content-type protocol allows mpv to send compositor a hint about the
type of content being displayed on its surface so it could potentially
make some sort of optimization. Fundamentally, this is pretty simple but
since this requires a very new wayland-protocols version (1.27), we have
to mess with the build to add a new define and add a bunch of if's in
here. The protocol itself exposes 4 different types of content: none,
photo, video, and game.
To do that, let's add a new option (wayland-content-type) that lets
users control what hint to send to the compossitor. Since the previous
commit adds a VOCTRL that notifies us about the content being displayed,
we can also add an auto value to this option. As you'd expect, the
compositor hint would be set to photo if mpv's core detects an image,
video for other things, and it is set to none for the special case of
forcing a window when there is not a video track. For completion's sake,
game is also allowed as a value for this option, but in practice there
shouldn't be a reason to use that.
2022-11-15 21:51:45 +00:00
} , {
'name': 'wayland-protocols-1-27',
'desc': 'wayland-protocols version 1.27+',
'deps': 'wayland',
'func': check_pkg_config('wayland-protocols >= 1.27'),
2023-01-23 20:16:43 +00:00
} , {
'name': 'wayland-protocols-1-31',
'desc': 'wayland-protocols version 1.31+',
'deps': 'wayland',
'func': check_pkg_config('wayland-protocols >= 1.31'),
2020-05-16 07:21:27 +00:00
} , {
'name': 'memfd_create',
'desc': "Linux's memfd_create()",
'deps': 'wayland',
'func': check_statement('sys/mman.h',
'memfd_create("mpv", MFD_CLOEXEC | MFD_ALLOW_SEALING)')
2013-07-16 11:28:28 +00:00
} , {
'name': '--x11',
'desc': 'X11',
2017-09-21 11:50:18 +00:00
'deps': 'gpl',
2017-04-21 05:30:03 +00:00
'func': check_pkg_config('x11', '>= 1.0.0',
2017-08-20 07:11:26 +00:00
'xscrnsaver', '>= 1.0.0',
2017-04-21 05:30:03 +00:00
'xext', '>= 1.0.0',
'xinerama', '>= 1.0.0',
x11: support xorg present extension
This builds off of present_sync which was introduced in a previous
commit to support xorg's present extension in all of the X11 backends
(sans vdpau) in mpv. It turns out there is an Xpresent library that
integrates the xorg present extention with Xlib (which barely anyone
seems to use), so this can be added without too much trouble. The
workflow is to first setup the event by telling Xorg we would like to
receive PresentCompleteNotify (there are others in the extension but
this is the only one we really care about). After that, just call
XPresentNotifyMSC after every buffer swap with a target_msc of 0. Xorg
then returns the last presentation through its usual event loop and we
go ahead and use that information to update mpv's values for vsync
timing purposes. One theoretical weakness of this approach is that the
present event is put on the same queue as the rest of the XEvents. It
would be nicer for it be placed somewhere else so we could just wait
on that queue without having to deal with other possible events in
there. In theory, xcb could do that with special events, but it doesn't
really matter in practice.
Unsurprisingly, this doesn't work on NVIDIA. Well NVIDIA does actually
receive presentation events, but for whatever the calculations used make
timings worse which defeats the purpose. This works perfectly fine on
Mesa however. Utilizing the previous commit that detects Xrandr
providers, we can enable this mechanism for users that have both Mesa
and not NVIDIA (to avoid messing up anyone that has a switchable
graphics system or such). Patches welcome if anyone figures out how to
fix this on NVIDIA.
Unlike the EGL/GLX sync extensions, the present extension works with any
graphics API (good for vulkan since its timing extension has been in
development hell). NVIDIA also happens to have zero support for the
EGL/GLX sync extensions, so we can just remove it with no loss. Only
Xorg ever used it and other backends already have their own present
methods. vo_vdpau VO is a special case that has its own fancying timing
code in its flip_page. This presumably works well, and I have no way of
testing it so just leave it as it is.
2022-06-10 16:49:38 +00:00
'xpresent', '>= 1.0.0',
2017-04-21 05:30:03 +00:00
'xrandr', '>= 1.2.0'),
2013-07-16 11:28:28 +00:00
} , {
'name': '--xv',
'desc': 'Xv video output',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'x11',
2013-07-16 11:28:28 +00:00
'func': check_pkg_config('xv'),
} , {
'name': '--gl-cocoa',
'desc': 'OpenGL Cocoa Backend',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'cocoa',
2013-11-28 07:36:41 +00:00
'groups': [ 'gl' ],
2016-10-19 20:40:10 +00:00
'func': check_statement('IOSurface/IOSurface.h',
'IOSurfaceRef surface;',
2019-04-05 08:12:41 +00:00
framework='IOSurface',
cflags=['-DGL_SILENCE_DEPRECATION'])
2013-07-16 11:28:28 +00:00
} , {
'name': '--gl-x11',
2020-09-18 13:16:24 +00:00
'desc': 'OpenGL X11/GLX (deprecated/legacy)',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'x11',
2013-11-28 07:36:41 +00:00
'groups': [ 'gl' ],
2013-07-16 11:28:28 +00:00
'func': check_libs(['GL', 'GL Xdamage'],
check_cc(fragment=load_fragment('gl_x11.c'),
2020-09-18 13:16:24 +00:00
use=['x11', 'libdl', 'pthreads'])),
'default': 'disable',
2020-04-18 18:38:52 +00:00
}, {
'name': '--rpi',
'desc': 'Raspberry Pi support',
'func': check_egl_provider(name='brcmegl', check=any_check(
check_pkg_config('brcmegl'),
check_pkg_config('/opt/vc/lib/pkgconfig/brcmegl.pc')
)),
'default': 'disable',
x11: require EGL 1.5 and use eglGetPlatformDisplay()
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.)
2019-11-16 19:54:42 +00:00
} , {
2019-12-15 23:37:18 +00:00
'name': '--egl',
'desc': 'EGL 1.4',
x11: require EGL 1.5 and use eglGetPlatformDisplay()
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.)
2019-11-16 19:54:42 +00:00
'groups': [ 'gl' ],
2020-04-18 18:38:52 +00:00
'func': check_egl_provider('1.4')
2014-11-03 23:12:04 +00:00
} , {
'name': '--egl-x11',
'desc': 'OpenGL X11 EGL Backend',
2019-12-15 23:37:18 +00:00
'deps': 'x11 && egl',
2014-11-03 23:12:04 +00:00
'groups': [ 'gl' ],
x11: require EGL 1.5 and use eglGetPlatformDisplay()
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.)
2019-11-16 19:54:42 +00:00
'func': check_true,
vo_opengl: add DRM EGL backend
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>
2015-11-07 18:06:57 +00:00
} , {
'name': '--egl-drm',
'desc': 'OpenGL DRM EGL Backend',
2020-03-30 20:31:50 +00:00
'deps': 'drm && gbm && egl',
vo_opengl: add DRM EGL backend
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>
2015-11-07 18:06:57 +00:00
'groups': [ 'gl' ],
2020-03-30 20:31:50 +00:00
'func': check_true,
2013-07-16 11:28:28 +00:00
} , {
'name': '--gl-wayland',
'desc': 'OpenGL Wayland Backend',
2020-03-30 20:31:50 +00:00
'deps': 'wayland && egl',
2013-11-28 07:36:41 +00:00
'groups': [ 'gl' ],
2020-03-30 20:31:50 +00:00
'func': check_pkg_config('wayland-egl', '>= 9.0.0')
2013-07-16 11:28:28 +00:00
} , {
'name': '--gl-win32',
'desc': 'OpenGL Win32 Backend',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'win32-desktop',
2013-11-28 07:36:41 +00:00
'groups': [ 'gl' ],
2013-07-16 11:28:28 +00:00
'func': check_statement('windows.h', 'wglCreateContext(0)',
lib='opengl32')
2015-11-30 13:56:02 +00:00
} , {
'name': '--gl-dxinterop',
'desc': 'OpenGL/DirectX Interop Backend',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'gl-win32',
2015-11-30 13:56:02 +00:00
'groups': [ 'gl' ],
'func': compose_checks(
check_statement(['GL/gl.h', 'GL/wglext.h'], 'int i = WGL_ACCESS_WRITE_DISCARD_NV'),
check_statement('d3d9.h', 'IDirect3D9Ex *d'))
2015-11-13 13:04:30 +00:00
} , {
'name': '--egl-angle',
2017-06-30 10:27:15 +00:00
'desc': 'OpenGL ANGLE headers',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'os-win32 || os-cygwin',
2015-11-13 13:04:30 +00:00
'groups': [ 'gl' ],
2016-05-11 10:33:49 +00:00
'func': check_statement(['EGL/egl.h', 'EGL/eglext.h'],
'int x = EGL_D3D_TEXTURE_2D_SHARE_HANDLE_ANGLE')
2016-11-22 22:26:43 +00:00
} , {
'name': '--egl-angle-lib',
'desc': 'OpenGL Win32 ANGLE Library',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'egl-angle',
2016-11-22 22:26:43 +00:00
'groups': [ 'gl' ],
'func': check_statement(['EGL/egl.h'],
'eglCreateWindowSurface(0, 0, 0, 0)',
2017-02-19 12:25:23 +00:00
lib=['EGL', 'GLESv2', 'dxguid', 'd3d9',
'gdi32', 'stdc++'])
2017-06-30 10:27:15 +00:00
}, {
'name': '--egl-angle-win32',
'desc': 'OpenGL Win32 ANGLE Backend',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'egl-angle && win32-desktop',
2017-06-30 10:27:15 +00:00
'groups': [ 'gl' ],
'func': check_true,
2013-07-16 11:28:28 +00:00
} , {
'name': '--vdpau',
'desc': 'VDPAU acceleration',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'x11',
2013-07-16 11:28:28 +00:00
'func': check_pkg_config('vdpau', '>= 0.2'),
} , {
'name': '--vdpau-gl-x11',
'desc': 'VDPAU with OpenGL/X11',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'vdpau && gl-x11',
2013-07-16 11:28:28 +00:00
'func': check_true,
}, {
'name': '--vaapi',
'desc': 'VAAPI acceleration',
vaapi: change license to LGPL
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.
2017-09-29 16:44:47 +00:00
'deps': 'libdl && (x11 || wayland || egl-drm)',
2019-12-12 01:40:19 +00:00
'func': check_pkg_config('libva', '>= 1.1.0'),
2015-09-27 18:09:10 +00:00
}, {
'name': '--vaapi-x11',
'desc': 'VAAPI (X11 support)',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'vaapi && x11',
2019-12-12 01:40:19 +00:00
'func': check_pkg_config('libva-x11', '>= 1.1.0'),
2015-09-27 19:24:35 +00:00
}, {
'name': '--vaapi-wayland',
'desc': 'VAAPI (Wayland support)',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'vaapi && gl-wayland',
2019-12-12 01:40:19 +00:00
'func': check_pkg_config('libva-wayland', '>= 1.1.0'),
2022-09-27 16:12:54 +00:00
}, {
'name': 'dmabuf-wayland',
'desc': 'Wayland dmabuf support',
'deps': 'wayland && memfd_create && (vaapi-wayland || drm)',
2022-05-18 14:35:53 +00:00
'func': check_true,
2016-01-20 18:41:29 +00:00
}, {
'name': '--vaapi-drm',
'desc': 'VAAPI (DRM/EGL support)',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'vaapi && egl-drm',
2019-12-12 01:40:19 +00:00
'func': check_pkg_config('libva-drm', '>= 1.1.0'),
2015-09-24 22:20:57 +00:00
}, {
'name': '--vaapi-x-egl',
'desc': 'VAAPI EGL on X11',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'vaapi-x11 && egl-x11',
2015-09-27 18:09:10 +00:00
'func': check_true,
}, {
'name': 'vaapi-egl',
'desc': 'VAAPI EGL',
2019-09-15 03:05:21 +00:00
'deps': 'vaapi-x-egl || vaapi-wayland || vaapi-drm',
2015-09-24 22:20:57 +00:00
'func': check_true,
2013-07-16 11:28:28 +00:00
}, {
'name': '--caca',
'desc': 'CACA',
2017-09-21 11:50:18 +00:00
'deps': 'gpl',
2013-07-16 11:28:28 +00:00
'func': check_pkg_config('caca', '>= 0.99.beta18'),
}, {
'name': '--jpeg',
'desc': 'JPEG support',
'func': check_cc(header_name=['stdio.h', 'jpeglib.h'],
lib='jpeg', use='libm'),
}, {
'name': '--direct3d',
'desc': 'Direct3D support',
2017-09-21 11:50:18 +00:00
'deps': 'win32-desktop && gpl',
2013-07-16 11:28:28 +00:00
'func': check_cc(header_name='d3d9.h'),
2017-12-24 19:11:27 +00:00
}, {
'name': 'shaderc-shared',
'desc': 'libshaderc SPIR-V compiler (shared library)',
'deps': '!static-build',
'groups': ['shaderc'],
2021-12-19 16:43:22 +00:00
'func': check_pkg_config('shaderc'),
2017-12-24 19:11:27 +00:00
}, {
'name': 'shaderc-static',
'desc': 'libshaderc SPIR-V compiler (static library)',
'deps': '!shaderc-shared',
'groups': ['shaderc'],
2021-12-19 16:43:22 +00:00
'func': any_check(check_pkg_config('shaderc_combined'),
check_pkg_config('shaderc_static')),
vo_gpu: d3d11: initial implementation
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: https://github.com/rossy/crossc
- 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.
2017-09-07 10:18:06 +00:00
}, {
'name': '--shaderc',
'desc': 'libshaderc SPIR-V compiler',
2017-12-24 19:11:27 +00:00
'deps': 'shaderc-shared || shaderc-static',
'func': check_true,
2019-06-14 02:56:30 +00:00
}, {
'name': 'spirv-cross-shared',
'desc': 'SPIRV-Cross SPIR-V shader converter (shared library)',
'deps': '!static-build',
'groups': ['spirv-cross'],
'func': check_pkg_config('spirv-cross-c-shared'),
}, {
'name': 'spirv-cross-static',
'desc': 'SPIRV-Cross SPIR-V shader converter (static library)',
'deps': '!spirv-cross-shared',
'groups': ['spirv-cross'],
'func': check_pkg_config('spirv-cross'),
vo_gpu: d3d11: initial implementation
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: https://github.com/rossy/crossc
- 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.
2017-09-07 10:18:06 +00:00
}, {
2019-04-16 08:18:50 +00:00
'name': '--spirv-cross',
'desc': 'SPIRV-Cross SPIR-V shader converter',
2019-06-14 02:56:30 +00:00
'deps': 'spirv-cross-shared || spirv-cross-static',
'func': check_true,
vo_gpu: d3d11: initial implementation
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: https://github.com/rossy/crossc
- 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.
2017-09-07 10:18:06 +00:00
}, {
'name': '--d3d11',
'desc': 'Direct3D 11 video output',
2019-04-16 08:18:50 +00:00
'deps': 'win32-desktop && shaderc && spirv-cross',
2019-10-11 21:35:22 +00:00
'func': check_cc(header_name=['d3d11_1.h', 'dxgi1_6.h']),
2016-10-19 19:07:05 +00:00
} , {
'name': '--ios-gl',
2017-04-07 12:30:51 +00:00
'desc': 'iOS OpenGL ES hardware decoding interop support',
2016-10-19 19:07:05 +00:00
'func': check_statement('OpenGLES/ES3/glext.h', '(void)GL_RGB32F'), # arbitrary OpenGL ES 3.0 symbol
2016-02-08 21:06:51 +00:00
} , {
'name': '--plain-gl',
'desc': 'OpenGL without platform-specific code (e.g. for libmpv)',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'libmpv-shared || libmpv-static',
2016-02-08 21:06:51 +00:00
'func': check_true,
2016-09-13 15:03:24 +00:00
}, {
2015-03-29 13:12:11 +00:00
'name': '--gl',
vo_opengl: refactor into vo_gpu
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.
2017-09-14 06:04:55 +00:00
'desc': 'OpenGL context support',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'gl-cocoa || gl-x11 || egl-x11 || egl-drm || '
2019-06-29 23:00:17 +00:00
+ 'gl-win32 || gl-wayland || rpi || '
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
+ 'plain-gl',
2016-05-01 18:15:53 +00:00
'func': check_true,
'req': True,
2017-09-22 03:35:26 +00:00
'fmsg': "No OpenGL video output found or enabled. " +
"Aborting. If you really mean to compile without OpenGL " +
"video outputs use --disable-gl.",
2018-11-10 11:53:33 +00:00
}, {
'name': '--libplacebo',
'desc': 'libplacebo support',
2022-01-11 12:28:40 +00:00
'func': check_pkg_config('libplacebo >= 4.157.0'),
2021-04-09 07:14:54 +00:00
}, {
2022-02-03 15:14:27 +00:00
'name': 'libplacebo-next',
2022-04-09 21:58:59 +00:00
'desc': 'libplacebo v4.202+, needed for vo_gpu_next',
2021-04-09 07:14:54 +00:00
'deps': 'libplacebo',
2022-04-09 21:58:59 +00:00
'func': check_preprocessor('libplacebo/config.h', 'PL_API_VER >= 202',
2021-04-09 07:14:54 +00:00
use='libplacebo'),
vo_gpu: vulkan: initial implementation
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. https://github.com/KhronosGroup/Vulkan-Docs/issues/370)
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.
2016-09-14 18:54:18 +00:00
}, {
'name': '--vulkan',
2018-11-10 11:53:33 +00:00
'desc': 'Vulkan context support',
'deps': 'libplacebo',
'func': check_pkg_config('vulkan'),
2018-12-30 22:59:48 +00:00
}, {
2022-02-26 14:13:10 +00:00
'name': 'vaapi-libplacebo',
'desc': 'VAAPI libplacebo',
'deps': 'vaapi && libplacebo',
2018-12-30 22:59:48 +00:00
'func': check_true,
2015-12-19 11:45:07 +00:00
}, {
'name': 'egl-helpers',
'desc': 'EGL helper functions',
2020-03-30 20:31:50 +00:00
'deps': 'egl || rpi || egl-angle-win32 || egl-android',
2015-03-29 13:12:11 +00:00
'func': check_true
2020-11-01 11:13:31 +00:00
}, {
'name': '--sixel',
'desc': 'Sixel',
'func': check_pkg_config('libsixel', '>= 1.5'),
2022-07-31 19:59:15 +00:00
}, {
'name': 'dmabuf-interop-gl',
'desc': 'dmabuf GL Interop',
'deps': 'egl && drm',
'func': check_true,
}, {
'name': 'dmabuf-interop-pl',
'desc': 'dmabuf libplacebo interop',
'deps': 'vaapi-libplacebo',
'func': check_true,
2022-08-11 12:40:15 +00:00
}, {
# This can be removed roughly when Debian 12 is released.
'name': 'drm-is-kms',
'desc': 'drmIsKMS() function',
'deps': 'drm',
'func': check_pkg_config('libdrm', '>= 2.4.105'),
2022-12-26 14:08:07 +00:00
}, {
'name': 'posix-shm',
'desc': "POSIX shared memory API",
'deps': 'posix',
'func': check_statement('sys/mman.h', 'shm_open("",0,0)')
2013-07-16 11:28:28 +00:00
}
]
hwaccel_features = [
{
2017-09-26 17:13:26 +00:00
'name': 'videotoolbox-hwaccel',
2017-10-30 19:55:42 +00:00
'desc': 'libavcodec videotoolbox hwaccel',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'gl-cocoa || ios-gl',
2017-10-30 19:55:42 +00:00
'func': check_true,
2017-05-24 13:07:45 +00:00
}, {
2015-07-11 15:21:39 +00:00
'name': '--videotoolbox-gl',
'desc': 'Videotoolbox with OpenGL',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'gl-cocoa && videotoolbox-hwaccel',
2015-07-11 15:21:39 +00:00
'func': check_true
2014-10-25 17:23:46 +00:00
}, {
2016-05-11 12:37:03 +00:00
'name': '--d3d-hwaccel',
2018-01-24 01:28:22 +00:00
'desc': 'D3D11VA hwaccel',
'deps': 'os-win32',
2017-10-30 19:55:42 +00:00
'func': check_true,
2017-06-30 10:27:15 +00:00
}, {
'name': '--d3d9-hwaccel',
2018-01-24 01:28:22 +00:00
'desc': 'DXVA2 hwaccel',
'deps': 'd3d-hwaccel',
2017-06-30 10:27:15 +00:00
'func': check_true,
}, {
'name': '--gl-dxinterop-d3d9',
'desc': 'OpenGL/DirectX Interop Backend DXVA2 interop',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'gl-dxinterop && d3d9-hwaccel',
2017-06-30 10:27:15 +00:00
'groups': [ 'gl' ],
'func': check_true,
2018-04-15 16:06:34 +00:00
}, {
'name': 'ffnvcodec',
'desc': 'CUDA Headers and dynamic loader',
2018-11-27 02:04:08 +00:00
'func': check_pkg_config('ffnvcodec >= 8.2.15.7'),
hwdec/opengl: Add support for CUDA and cuvid/NvDecode
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.
2016-09-04 22:23:55 +00:00
}, {
2016-09-16 03:15:36 +00:00
'name': '--cuda-hwaccel',
2019-12-28 20:58:39 +00:00
'desc': 'CUDA acceleration',
'deps': 'ffnvcodec',
'func': check_true,
}, {
'name': '--cuda-interop',
'desc': 'CUDA with graphics interop',
'deps': '(gl || vulkan) && cuda-hwaccel',
2018-05-10 19:03:12 +00:00
'func': check_true,
2019-07-14 13:56:10 +00:00
}, {
'name': '--rpi-mmal',
'desc': 'Raspberry Pi MMAL hwaccel',
'deps': 'rpi',
2020-04-18 12:57:43 +00:00
'func': any_check(check_pkg_config('mmal'),
check_pkg_config('/opt/vc/lib/pkgconfig/mmal.pc')),
2013-07-16 11:28:28 +00:00
}
]
2014-04-16 01:08:50 +00:00
standalone_features = [
{
'name': 'win32-executable',
'desc': 'w32 executable',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'os-win32 || !(!(os-cygwin))',
2014-04-16 01:08:50 +00:00
'func': check_ctx_vars('WINDRES')
2017-02-25 20:56:59 +00:00
}, {
'name': '--macos-touchbar',
'desc': 'macOS Touch Bar support',
build: use unified dependency expressions instead of weird fields
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:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
2017-09-18 20:35:37 +00:00
'deps': 'cocoa',
2017-02-25 20:56:59 +00:00
'func': check_cc(
fragment=load_fragment('touchbar.m'),
framework_name=['AppKit'],
compile_filename='test-touchbar.m',
linkflags='-fobjc-arc')
2019-04-14 13:07:56 +00:00
}, {
'name': '--macos-10-11-features',
'desc': 'macOS 10.11 SDK Features',
'deps': 'cocoa',
'func': check_macos_sdk('10.11')
2019-11-30 15:08:32 +00:00
}, {
'name': '--macos-10-12-2-features',
'desc': 'macOS 10.12.2 SDK Features',
'deps': 'cocoa',
'func': check_macos_sdk('10.12.2')
2019-04-14 13:07:56 +00:00
}, {
'name': '--macos-10-14-features',
'desc': 'macOS 10.14 SDK Features',
'deps': 'cocoa',
'func': check_macos_sdk('10.14')
2019-12-22 23:02:23 +00:00
},{
'name': '--macos-media-player',
'desc': 'macOS Media Player support',
'deps': 'macos-10-12-2-features && swift',
'func': check_true
2019-04-14 13:07:56 +00:00
}, {
cocoa-cb: initial implementation via opengl-cb API
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
2018-02-12 11:28:19 +00:00
'name': '--macos-cocoa-cb',
2019-09-29 16:35:12 +00:00
'desc': 'macOS libmpv backend',
2019-07-20 10:16:37 +00:00
'deps': 'cocoa && swift',
2018-07-08 15:05:13 +00:00
'func': check_true
cocoa-cb: initial implementation via opengl-cb API
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
2018-02-12 11:28:19 +00:00
}
2014-04-16 01:08:50 +00:00
]
2013-07-16 11:28:28 +00:00
_INSTALL_DIRS_LIST = [
2018-07-01 19:09:45 +00:00
('confdir', '${SYSCONFDIR}/mpv', 'configuration files'),
2014-10-10 17:58:41 +00:00
('zshdir', '${DATADIR}/zsh/site-functions', 'zsh completion functions'),
2016-01-11 15:35:30 +00:00
('confloaddir', '${CONFDIR}', 'configuration files load directory'),
2020-01-09 03:09:14 +00:00
('bashdir', '${DATADIR}/bash-completion/completions', 'bash completion functions'),
2013-07-16 11:28:28 +00:00
]
def options(opt):
opt.load('compiler_c')
opt.load('waf_customizations')
opt.load('features')
2018-07-01 19:09:45 +00:00
opt.load('gnu_dirs')
2013-07-16 11:28:28 +00:00
2018-07-01 19:09:45 +00:00
#remove unused options from gnu_dirs
opt.parser.remove_option("--sbindir")
opt.parser.remove_option("--libexecdir")
opt.parser.remove_option("--sharedstatedir")
opt.parser.remove_option("--localstatedir")
opt.parser.remove_option("--oldincludedir")
opt.parser.remove_option("--infodir")
opt.parser.remove_option("--localedir")
opt.parser.remove_option("--dvidir")
opt.parser.remove_option("--pdfdir")
opt.parser.remove_option("--psdir")
2018-07-17 23:26:06 +00:00
libdir = opt.parser.get_option('--libdir')
if libdir:
# Replace any mention of lib64 as we keep the default
# for libdir the same as before the waf update.
libdir.help = libdir.help.replace('lib64', 'lib')
2018-07-01 19:09:45 +00:00
group = opt.get_option_group("Installation directories")
2013-07-16 11:28:28 +00:00
for ident, default, desc in _INSTALL_DIRS_LIST:
group.add_option('--{0}'.format(ident),
type = 'string',
dest = ident,
default = default,
help = 'directory for installing {0} [{1}]' \
2018-07-01 19:09:45 +00:00
.format(desc, default.replace('${','').replace('}','')))
2013-07-16 11:28:28 +00:00
2018-07-01 19:09:45 +00:00
group = opt.get_option_group("build and install options")
2014-08-04 08:44:21 +00:00
group.add_option('--variant',
default = '',
help = 'variant name for saving configuration and build results')
2013-07-16 11:28:28 +00:00
opt.parse_features('build and install options', build_options)
2016-06-09 19:05:33 +00:00
optional_features = main_dependencies + libav_dependencies
2014-11-28 14:40:55 +00:00
opt.parse_features('optional features', optional_features)
2013-07-16 11:28:28 +00:00
opt.parse_features('audio outputs', audio_output_features)
opt.parse_features('video outputs', video_output_features)
opt.parse_features('hwaccels', hwaccel_features)
2014-04-16 01:08:50 +00:00
opt.parse_features('standalone app', standalone_features)
2013-07-16 11:28:28 +00:00
2014-11-28 14:40:55 +00:00
group = opt.get_option_group("optional features")
2013-07-16 11:28:28 +00:00
group.add_option('--lua',
type = 'string',
dest = 'LUA_VER',
build: lua 5.1/5.2: use generic version names
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).
2021-09-25 14:51:19 +00:00
help = "select Lua package to autodetect. Choices (x is 1 or 2): luadef5x, lua5x, lua5.x, lua-5.x, luajit (luadef5x is for pkg-config name 'lua', the rest are exact pkg-config names)")
cocoa-cb: initial implementation via opengl-cb API
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
2018-02-12 11:28:19 +00:00
group.add_option('--swift-flags',
type = 'string',
dest = 'SWIFT_FLAGS',
help = "Optional Swift compiler flags")
2013-07-16 11:28:28 +00:00
2014-07-19 16:45:43 +00:00
@conf
def is_optimization(ctx):
return getattr(ctx.options, 'enable_optimize')
2013-07-16 11:28:28 +00:00
@conf
def is_debug_build(ctx):
return getattr(ctx.options, 'enable_debug-build')
def configure(ctx):
2018-07-17 23:26:06 +00:00
from waflib import Options
2014-08-04 08:44:21 +00:00
ctx.resetenv(ctx.options.variant)
2014-12-04 20:55:00 +00:00
ctx.check_waf_version(mini='1.8.4')
2013-07-16 11:28:28 +00:00
target = os.environ.get('TARGET')
2014-10-31 23:20:10 +00:00
(cc, pkg_config, ar, windres) = ('cc', 'pkg-config', 'ar', 'windres')
2013-07-16 11:28:28 +00:00
if target:
cc = '-'.join([target, 'gcc'])
pkg_config = '-'.join([target, pkg_config])
2014-10-31 23:20:10 +00:00
ar = '-'.join([target, ar])
2013-07-16 11:28:28 +00:00
windres = '-'.join([target, windres])
ctx.find_program(cc, var='CC')
ctx.find_program(pkg_config, var='PKG_CONFIG')
2014-10-31 23:20:10 +00:00
ctx.find_program(ar, var='AR')
2015-12-29 19:57:09 +00:00
ctx.find_program('rst2html', var='RST2HTML', mandatory=False)
2013-07-16 11:28:28 +00:00
ctx.find_program('rst2man', var='RST2MAN', mandatory=False)
2014-01-08 15:00:40 +00:00
ctx.find_program('rst2pdf', var='RST2PDF', mandatory=False)
2013-07-16 11:28:28 +00:00
ctx.find_program(windres, var='WINDRES', mandatory=False)
2016-12-17 12:24:05 +00:00
ctx.find_program('perl', var='BIN_PERL', mandatory=False)
2013-07-16 11:28:28 +00:00
2017-01-28 10:31:28 +00:00
ctx.add_os_flags('LIBRARY_PATH')
2023-01-17 00:17:04 +00:00
ctx.load('compiler_c python')
2016-11-16 15:18:11 +00:00
ctx.load('waf_customizations')
ctx.load('dependencies')
cocoa-cb: initial implementation via opengl-cb API
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
2018-02-12 11:28:19 +00:00
ctx.load('detections.compiler_swift')
2016-11-16 15:18:11 +00:00
ctx.load('detections.compiler')
ctx.load('detections.devices')
2018-07-01 19:09:45 +00:00
ctx.load('gnu_dirs')
2016-11-16 15:18:11 +00:00
2018-07-17 23:26:06 +00:00
# if libdir is not set in command line options,
# override the gnu_dirs default in order to
# always have `lib/` as the library directory.
if not getattr(Options.options, 'LIBDIR', None):
ctx.env['LIBDIR'] = Utils.subst_vars(os.path.join('${EXEC_PREFIX}', 'lib'), ctx.env)
2013-07-16 11:28:28 +00:00
for ident, _, _ in _INSTALL_DIRS_LIST:
varname = ident.upper()
ctx.env[varname] = getattr(ctx.options, ident)
# keep substituting vars, until the paths are fully expanded
while re.match('\$\{([^}]+)\}', ctx.env[varname]):
ctx.env[varname] = Utils.subst_vars(ctx.env[varname], ctx.env)
2020-12-10 03:11:33 +00:00
if ctx.options.LUA_VER:
ctx.options.enable_lua = True
2013-07-16 11:28:28 +00:00
ctx.parse_dependencies(build_options)
ctx.parse_dependencies(main_dependencies)
2019-09-21 15:54:42 +00:00
ctx.parse_dependencies(libav_dependencies)
2013-07-16 11:28:28 +00:00
ctx.parse_dependencies(audio_output_features)
ctx.parse_dependencies(video_output_features)
ctx.parse_dependencies(hwaccel_features)
cocoa-cb: initial implementation via opengl-cb API
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
2018-02-12 11:28:19 +00:00
if ctx.options.SWIFT_FLAGS:
2018-10-27 15:27:01 +00:00
ctx.env.SWIFT_FLAGS.extend(split(ctx.options.SWIFT_FLAGS))
cocoa-cb: initial implementation via opengl-cb API
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
2018-02-12 11:28:19 +00:00
2014-04-16 01:08:50 +00:00
ctx.parse_dependencies(standalone_features)
2013-07-16 11:28:28 +00:00
ctx.load('generators.headers')
if not ctx.dependency_satisfied('build-date'):
ctx.env.CFLAGS += ['-DNO_BUILD_TIMESTAMPS']
2015-02-05 20:00:23 +00:00
if ctx.dependency_satisfied('clang-database'):
ctx.load('clang_compilation_database')
2017-01-12 16:37:11 +00:00
if ctx.dependency_satisfied('cplugins'):
# We need to export the libmpv symbols, since the mpv binary itself is
# not linked against libmpv. The C plugin needs to be able to pick
# up the libmpv symbols from the binary. We still restrict the set
# of exported symbols via mpv.def.
2017-03-02 13:40:14 +00:00
ctx.env.LINKFLAGS += ['-rdynamic']
2017-01-12 16:37:11 +00:00
2013-11-24 13:22:45 +00:00
ctx.store_dependencies_lists()
2023-01-13 17:48:21 +00:00
from waflib import Logs
Logs.error("WARNING: Building mpv with waf is deprecated and will be removed the future! It is recommended to switch to meson as soon as possible.")
2013-11-24 13:22:45 +00:00
2015-06-30 13:56:26 +00:00
def __write_version__(ctx):
2015-07-11 17:03:44 +00:00
ctx(
2023-01-17 00:17:04 +00:00
source = 'version.py',
2019-06-21 22:03:31 +00:00
target = 'generated/version.h',
2023-01-17 00:17:04 +00:00
rule = '${PYTHON} ${SRC} ${TGT}',
always = True)
2015-06-30 13:56:26 +00:00
2013-07-16 11:28:28 +00:00
def build(ctx):
2014-08-04 08:44:21 +00:00
if ctx.options.variant not in ctx.all_envs:
from waflib import Errors
raise Errors.WafError(
'The project was not configured: run "waf --variant={0} configure" first!'
.format(ctx.options.variant))
2013-11-24 13:22:45 +00:00
ctx.unpack_dependencies_lists()
2018-01-01 15:56:58 +00:00
ctx.add_group('versionh')
ctx.add_group('sources')
ctx.set_group('versionh')
2015-06-30 13:56:26 +00:00
__write_version__(ctx)
2018-01-01 15:56:58 +00:00
ctx.set_group('sources')
2013-07-16 11:28:28 +00:00
ctx.load('wscript_build')
2014-08-04 08:44:21 +00:00
def init(ctx):
from waflib.Build import BuildContext, CleanContext, InstallContext, UninstallContext
for y in (BuildContext, CleanContext, InstallContext, UninstallContext):
class tmp(y):
variant = ctx.options.variant
# This is needed because waf initializes the ConfigurationContext with
# an arbitrary setenv('') which would rewrite the previous configuration
# cache for the default variant if the configure step finishes.
# Ideally ConfigurationContext should just let us override this at class
# level like the other Context subclasses do with variant
from waflib.Configure import ConfigurationContext
class cctx(ConfigurationContext):
def resetenv(self, name):
self.all_envs = {}
self.setenv(name)