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
|
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')
|
|
|
|
|
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,
|
|
|
|
}, {
|
|
|
|
'name': 'libaf',
|
|
|
|
'desc': 'internal audio filter chain',
|
|
|
|
'deps': 'gpl',
|
|
|
|
'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
|
|
|
|
}, {
|
|
|
|
'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']),
|
2014-06-08 14:00:43 +00:00
|
|
|
}, {
|
|
|
|
'name': '--zsh-comp',
|
|
|
|
'desc': 'zsh completion',
|
2016-12-17 12:24:05 +00:00
|
|
|
'func': check_ctx_vars('BIN_PERL'),
|
2014-06-08 14:00:43 +00:00
|
|
|
'func': check_true,
|
2014-06-09 13:17:03 +00:00
|
|
|
'default': 'disable',
|
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,
|
2014-12-28 08:38:22 +00:00
|
|
|
}, {
|
|
|
|
'name': '--test',
|
|
|
|
'desc': 'test suite (using cmocka)',
|
2015-06-12 17:31:55 +00:00
|
|
|
'func': check_pkg_config('cmocka', '>= 1.0.0'),
|
2015-03-10 17:19:32 +00:00
|
|
|
'default': 'disable',
|
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',
|
|
|
|
# This should be good enough.
|
2014-12-26 16:14:48 +00:00
|
|
|
'func': check_statement(['poll.h', 'unistd.h', 'sys/mman.h'],
|
|
|
|
'struct pollfd pfd; poll(&pfd, 1, 0); fork(); int f[2]; pipe(f); munmap(f,0)'),
|
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
|
|
|
|
}, {
|
|
|
|
'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',
|
|
|
|
'func': check_swift,
|
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.'
|
2016-09-06 18:13:30 +00:00
|
|
|
}, {
|
|
|
|
'name': 'gnuc',
|
|
|
|
'desc': 'GNU C extensions',
|
|
|
|
'func': check_statement([], "__GNUC__"),
|
2014-05-20 23:04:47 +00:00
|
|
|
}, {
|
|
|
|
'name': 'stdatomic',
|
|
|
|
'desc': '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);'
|
wscript: improve stdatomic check
The current stdatomic check verifies the availability of the function by
calling atomic_load(). It also uses this test to check if linking
against libatomic is needed or not.
Unfortunately, on specific architectures (namely SPARC), using
atomic_load() does *not* require linking against libatomic, while other
atomic operations do. Due to this, mpv's wscript concludes that
stdatomic is available, and that linking against libatomic is not
needed, causing the following link failure:
[190/190] Linking build/mpv
audio/out/ao.c.13.o: In function `ao_query_and_reset_events':
/home/peko/autobuild/instance-0/output/build/mpv-0.18.1/build/../audio/out/ao.c:399: undefined reference to `__atomic_fetch_and_4'
In order to fix this, the stdatomic check is adjusted to call
atomic_fetch_add() instead, which does require libatomic. Thanks to
this, the wscript realizes that linking against libatomic is needed, and
the build works fine.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-08 21:34:32 +00:00
|
|
|
'atomic_fetch_add(&test, 1)'))
|
2014-01-01 19:42:13 +00:00
|
|
|
}, {
|
2014-07-05 15:02:06 +00:00
|
|
|
'name': 'atomics',
|
2017-02-13 05:45:40 +00:00
|
|
|
'desc': 'stdatomic.h support or slow emulation',
|
2014-01-01 19:42:13 +00:00
|
|
|
'func': check_true,
|
2016-08-05 15:10:22 +00:00
|
|
|
'req': True,
|
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': 'stdatomic || gnuc',
|
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
|
lua: add an utility function for starting processes
Because 1) Lua is terrible, and 2) popen() is terrible. Unfortunately,
since Unix is also terrible, this turned out more complicated than I
hoped. As a consequence and to avoid that this code has to be maintained
forever, add a disclaimer that any function in Lua's utils module can
disappear any time. The complexity seems a bit ridiculous, especially
for a feature so far removed from actual video playback, so if it turns
out that we don't really need this function, it will be dropped again.
The motivation for this commit is the same as with 8e4fa5fc.
Note that there is an "#ifndef __GLIBC__". The GNU people are very
special people and thought it'd be convenient to actually declare
"environ", even though the POSIX people, which are also very special
people, state that no header declares this and that the user has to
declare this manually. Since the GNU people overtook the Unix world with
their very clever "embrace, extend, extinguish" strategy, but not 100%,
and trying to build without _GNU_SOURCE is hopeless; but since there
might be Unix environments which support _GNU_SOURCE features partially,
this means that in practice "environ" will be randomly declared or not
declared by system headers. Also, gcc was written by very clever people
too, and prints a warning if an external variable is declared twice (I
didn't check, but I suppose redeclaring is legal C, and not even the gcc
people are clever enough to only warn against a definitely not legal C
construct, although sometimes they do this), ...and since we at mpv hate
compiler warnings, we seek to silence them all. Adding a configure test
just for a warning seems too radical, so we special-case this against
__GLIBC__, which is hopefully not defined on other libcs, especially not
libcs which don't implement all aspects of _GNU_SOURCE, and redefine
"environ" on systems even if the headers define it already (because they
support _GNU_SOURCE - as I mentioned before, the clever GNU people wrote
software THAT portable that other libcs just gave up and implemented
parts of _GNU_SOURCE, although probably not all), which means that
compiling mpv will print a warning about "environ" being redefined, but
at least this won't happen on my system, so all is fine. However, should
someone complain about this warning, I will force whoever complained
about this warning to read this ENTIRE commit message, and if possible,
will also force them to eat a printed-out copy of the GNU Manifesto, and
if that is not enough, maybe this person could even be forced to
convince the very clever POSIX people of not doing crap like this:
having the user to manually declare somewhat central symbols - but I
doubt it's possible, because the POSIX people are too far gone and only
care about maintaining compatibility with old versions of AIX and HP-UX.
Oh, also, this code contains some subtle and obvious issues, but writing
about this is not fun.
2014-10-18 23:42:28 +00:00
|
|
|
}, {
|
2017-08-03 20:50:10 +00:00
|
|
|
'name': 'posix-spawn-native',
|
|
|
|
'desc': 'spawnp()/kill() POSIX support',
|
2014-10-19 10:55:29 +00:00
|
|
|
'func': check_statement(['spawn.h', 'signal.h'],
|
2015-03-30 17:46:02 +00:00
|
|
|
'posix_spawnp(0,0,0,0,0,0); kill(0,0)'),
|
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': '!mingw',
|
2017-08-03 20:50:10 +00:00
|
|
|
}, {
|
|
|
|
'name': 'posix-spawn-android',
|
|
|
|
'desc': 'spawnp()/kill() Android replacement',
|
|
|
|
'func': check_true,
|
|
|
|
'deps': 'android && !posix-spawn-native',
|
|
|
|
},{
|
|
|
|
'name': 'posix-spawn',
|
|
|
|
'desc': 'any spawnp()/kill() support',
|
|
|
|
'deps': 'posix-spawn-native || posix-spawn-android',
|
|
|
|
'func': check_true,
|
2015-03-30 17:46:02 +00:00
|
|
|
}, {
|
2017-06-27 11:47:46 +00:00
|
|
|
'name': 'win32-pipes',
|
|
|
|
'desc': 'Windows pipe support',
|
2015-03-30 17:46:02 +00:00
|
|
|
'func': check_true,
|
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 && !posix',
|
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-02-26 20:44:35 +00:00
|
|
|
}, {
|
|
|
|
'name': 'fchmod',
|
|
|
|
'desc': 'fchmod()',
|
|
|
|
'func': check_statement('sys/stat.h', 'fchmod(0, 0)'),
|
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)'),
|
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)',
|
2014-10-21 23:02:55 +00:00
|
|
|
'func': check_statement('pthread.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')
|
2013-07-16 11:28:28 +00:00
|
|
|
}, {
|
|
|
|
'name': '--libsmbclient',
|
2017-05-11 06:12:14 +00:00
|
|
|
'desc': 'Samba support (makes mpv GPLv3)',
|
2017-09-21 11:50:18 +00:00
|
|
|
'deps': 'libdl && gpl',
|
2013-11-30 18:47:09 +00:00
|
|
|
'func': check_pkg_config('smbclient'),
|
2017-05-11 06:12:14 +00:00
|
|
|
'default': 'disable',
|
2013-07-16 11:28:28 +00:00
|
|
|
'module': 'input',
|
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
|
|
|
}, {
|
|
|
|
'name': '--libass',
|
|
|
|
'desc': 'SSA/ASS support',
|
2015-02-18 20:11:53 +00:00
|
|
|
'func': check_pkg_config('libass', '>= 0.12.1'),
|
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 " +
|
|
|
|
"found is too old. Aborting. If you really mean to compile " +
|
|
|
|
"without libass support use --disable-libass."
|
2013-07-16 11:28:28 +00:00
|
|
|
}, {
|
|
|
|
'name': '--libass-osd',
|
|
|
|
'desc': 'libass OSD 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': 'libass',
|
2013-07-16 11:28:28 +00:00
|
|
|
'func': check_true,
|
|
|
|
}, {
|
|
|
|
'name': 'dummy-osd',
|
|
|
|
'desc': 'dummy OSD 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': '!libass-osd',
|
2013-07-16 11:28:28 +00:00
|
|
|
'func': check_true,
|
|
|
|
} , {
|
2017-06-28 13:33:21 +00:00
|
|
|
'name': '--zlib',
|
2013-07-16 11:28:28 +00:00
|
|
|
'desc': 'zlib',
|
|
|
|
'func': check_libs(['z'],
|
|
|
|
check_statement('zlib.h', 'inflate(0, Z_NO_FLUSH)')),
|
|
|
|
'req': True,
|
|
|
|
'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',
|
2017-09-21 11:50:18 +00:00
|
|
|
'deps': 'libaf',
|
2015-02-10 22:50:17 +00:00
|
|
|
'func': check_pkg_config('rubberband', '>= 1.8.0'),
|
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',
|
2014-10-11 23:31:20 +00:00
|
|
|
'desc': 'VapourSynth filter bridge (Python)',
|
2015-09-22 09:46:57 +00:00
|
|
|
'func': check_pkg_config('vapoursynth', '>= 24',
|
|
|
|
'vapoursynth-script', '>= 23'),
|
2014-10-11 23:31:20 +00:00
|
|
|
}, {
|
|
|
|
'name': '--vapoursynth-lazy',
|
|
|
|
'desc': 'VapourSynth filter bridge (Lazy Lua)',
|
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': 'lua',
|
2015-09-22 09:46:57 +00:00
|
|
|
'func': check_pkg_config('vapoursynth', '>= 24'),
|
|
|
|
}, {
|
|
|
|
'name': 'vapoursynth-core',
|
|
|
|
'desc': 'VapourSynth filter bridge (core)',
|
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': 'vapoursynth || vapoursynth-lazy',
|
2014-10-11 23:31:20 +00:00
|
|
|
'func': check_true,
|
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',
|
|
|
|
'func': check_pkg_config('libarchive >= 3.0.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',
|
2013-07-16 11:28:28 +00:00
|
|
|
}
|
|
|
|
]
|
|
|
|
|
2017-01-27 08:57:01 +00:00
|
|
|
ffmpeg_pkg_config_checks = [
|
2019-05-07 04:25:45 +00:00
|
|
|
'libavutil', '>= 56.27.100',
|
2018-03-26 17:48:38 +00:00
|
|
|
'libavcodec', '>= 58.16.100',
|
2018-02-12 18:28:30 +00:00
|
|
|
'libavformat', '>= 58.9.100',
|
2017-10-30 19:55:42 +00:00
|
|
|
'libswscale', '>= 5.0.101',
|
2018-04-03 16:05:47 +00:00
|
|
|
'libavfilter', '>= 7.14.100',
|
2017-10-30 19:55:42 +00:00
|
|
|
'libswresample', '>= 3.0.100',
|
2017-01-27 08:57:01 +00:00
|
|
|
]
|
2013-07-16 11:28:28 +00:00
|
|
|
libav_pkg_config_checks = [
|
2017-10-30 19:55:42 +00:00
|
|
|
'libavutil', '>= 56.6.0',
|
2017-12-19 23:43:42 +00:00
|
|
|
'libavcodec', '>= 58.8.0',
|
2017-10-30 19:55:42 +00:00
|
|
|
'libavformat', '>= 58.1.0',
|
|
|
|
'libswscale', '>= 5.0.0',
|
|
|
|
'libavfilter', '>= 7.0.0',
|
|
|
|
'libavresample', '>= 4.0.0',
|
2013-07-16 11:28:28 +00:00
|
|
|
]
|
2017-01-27 08:57:01 +00:00
|
|
|
|
|
|
|
def check_ffmpeg_or_libav_versions():
|
|
|
|
def fn(ctx, dependency_identifier, **kw):
|
|
|
|
versions = ffmpeg_pkg_config_checks
|
2017-10-30 19:55:42 +00:00
|
|
|
if ctx.dependency_satisfied('libav'):
|
2017-01-27 08:57:01 +00:00
|
|
|
versions = libav_pkg_config_checks
|
|
|
|
return check_pkg_config(*versions)(ctx, dependency_identifier, **kw)
|
|
|
|
return fn
|
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-01-27 08:57:01 +00:00
|
|
|
'name': 'libavcodec',
|
|
|
|
'desc': 'FFmpeg/Libav present',
|
|
|
|
'func': check_pkg_config('libavcodec'),
|
|
|
|
'req': True,
|
|
|
|
'fmsg': "FFmpeg/Libav development files not found.",
|
|
|
|
}, {
|
2017-12-05 08:25:00 +00:00
|
|
|
'name': 'ffmpeg',
|
|
|
|
'desc': 'libav* is FFmpeg',
|
2017-10-30 19:55:42 +00:00
|
|
|
# FFmpeg <=> LIBAVUTIL_VERSION_MICRO>=100
|
2017-10-27 16:04:24 +00:00
|
|
|
'func': check_statement('libavcodec/version.h',
|
2017-10-30 19:55:42 +00:00
|
|
|
'int x[LIBAVCODEC_VERSION_MICRO >= 100 ? 1 : -1]',
|
2017-11-01 15:50:18 +00:00
|
|
|
use='libavcodec'),
|
2017-01-27 08:57:01 +00:00
|
|
|
}, {
|
2017-11-01 15:50:18 +00:00
|
|
|
# This check should always result in the opposite of ffmpeg-*.
|
2017-01-27 08:57:01 +00:00
|
|
|
# Run it to make sure is_ffmpeg didn't fail for some other reason than
|
|
|
|
# the actual version check.
|
2017-10-30 19:55:42 +00:00
|
|
|
'name': 'libav',
|
2017-01-27 08:57:01 +00:00
|
|
|
'desc': 'libav* is Libav',
|
|
|
|
# FFmpeg <=> LIBAVUTIL_VERSION_MICRO>=100
|
|
|
|
'func': check_statement('libavcodec/version.h',
|
|
|
|
'int x[LIBAVCODEC_VERSION_MICRO >= 100 ? -1 : 1]',
|
|
|
|
use='libavcodec')
|
|
|
|
}, {
|
2017-10-30 19:55:42 +00:00
|
|
|
'name': 'libav-any',
|
2017-01-27 08:57:01 +00:00
|
|
|
'desc': 'Libav/FFmpeg library versions',
|
2017-12-05 08:25:00 +00:00
|
|
|
'deps': 'ffmpeg || libav',
|
2017-01-27 08:57:01 +00:00
|
|
|
'func': check_ffmpeg_or_libav_versions(),
|
2013-07-16 11:28:28 +00:00
|
|
|
'req': True,
|
|
|
|
'fmsg': "Unable to find development files for some of the required \
|
2017-12-05 08:25:00 +00:00
|
|
|
FFmpeg/Libav libraries. Git master is recommended."
|
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',
|
2016-12-07 17:17:41 +00:00
|
|
|
'func': check_pkg_config('libavdevice', '>= 57.0.0'),
|
2017-10-30 19:55:42 +00:00
|
|
|
}
|
2013-07-16 11:28:28 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
audio_output_features = [
|
|
|
|
{
|
|
|
|
'name': '--sdl2',
|
|
|
|
'desc': 'SDL2',
|
2013-12-29 13:14:09 +00:00
|
|
|
'func': check_pkg_config('sdl2'),
|
|
|
|
'default': 'disable'
|
2013-07-16 11:28:28 +00:00
|
|
|
}, {
|
|
|
|
'name': '--oss-audio',
|
2017-06-22 08:30:11 +00:00
|
|
|
'desc': 'OSS',
|
|
|
|
'func': check_cc(header_name='sys/soundcard.h'),
|
2017-09-21 11:50:18 +00:00
|
|
|
'deps': 'posix && gpl',
|
2013-07-16 11:28:28 +00:00
|
|
|
}, {
|
|
|
|
'name': '--rsound',
|
|
|
|
'desc': 'RSound audio output',
|
|
|
|
'func': check_statement('rsound.h', 'rsd_init(NULL)', lib='rsound')
|
|
|
|
}, {
|
|
|
|
'name': '--sndio',
|
|
|
|
'desc': 'sndio audio input/output',
|
|
|
|
'func': check_statement('sndio.h',
|
2014-09-26 13:52:29 +00:00
|
|
|
'struct sio_par par; sio_initpar(&par); const char *s = SIO_DEVANY', lib='sndio'),
|
|
|
|
'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',
|
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': 'atomics',
|
2016-10-19 22:08:48 +00:00
|
|
|
'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 = [
|
|
|
|
{
|
|
|
|
'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',
|
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': 'vt.h',
|
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
|
|
|
'func': check_pkg_config('libdrm'),
|
2017-10-23 15:51:49 +00:00
|
|
|
}, {
|
|
|
|
'name': '--drmprime',
|
|
|
|
'desc': 'DRM Prime ffmpeg support',
|
|
|
|
'func': check_statement('libavutil/pixfmt.h',
|
|
|
|
'int i = AV_PIX_FMT_DRM_PRIME')
|
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',
|
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
|
|
|
'func': check_pkg_config('gbm'),
|
2017-10-01 20:16:49 +00:00
|
|
|
} , {
|
|
|
|
'name': '--wayland-scanner',
|
|
|
|
'desc': 'wayland-scanner',
|
|
|
|
'func': check_program('wayland-scanner', 'WAYSCAN')
|
|
|
|
} , {
|
|
|
|
'name': '--wayland-protocols',
|
|
|
|
'desc': 'wayland-protocols',
|
|
|
|
'func': check_wl_protocols
|
2013-07-16 11:28:28 +00:00
|
|
|
} , {
|
|
|
|
'name': '--wayland',
|
|
|
|
'desc': 'Wayland',
|
2017-10-01 20:16:49 +00:00
|
|
|
'deps': 'wayland-protocols && wayland-scanner',
|
2014-09-19 15:40:26 +00:00
|
|
|
'func': check_pkg_config('wayland-client', '>= 1.6.0',
|
|
|
|
'wayland-cursor', '>= 1.6.0',
|
2013-07-16 11:28:28 +00:00
|
|
|
'xkbcommon', '>= 0.3.0'),
|
|
|
|
} , {
|
|
|
|
'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',
|
|
|
|
'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;',
|
|
|
|
framework='IOSurface')
|
2013-07-16 11:28:28 +00:00
|
|
|
} , {
|
|
|
|
'name': '--gl-x11',
|
|
|
|
'desc': 'OpenGL X11 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': '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'),
|
|
|
|
use=['x11', 'libdl', 'pthreads']))
|
2014-11-03 23:12:04 +00:00
|
|
|
} , {
|
|
|
|
'name': '--egl-x11',
|
|
|
|
'desc': 'OpenGL X11 EGL 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': 'x11',
|
2014-11-03 23:12:04 +00:00
|
|
|
'groups': [ 'gl' ],
|
2017-04-26 15:09:16 +00:00
|
|
|
'func': check_pkg_config('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
|
|
|
} , {
|
|
|
|
'name': '--egl-drm',
|
|
|
|
'desc': 'OpenGL DRM EGL 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': 'drm && gbm',
|
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' ],
|
2017-04-26 15:09:16 +00:00
|
|
|
'func': check_pkg_config('egl'),
|
2013-07-16 11:28:28 +00:00
|
|
|
} , {
|
|
|
|
'name': '--gl-wayland',
|
|
|
|
'desc': 'OpenGL Wayland 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': 'wayland',
|
2013-11-28 07:36:41 +00:00
|
|
|
'groups': [ 'gl' ],
|
2013-07-16 11:28:28 +00:00
|
|
|
'func': check_pkg_config('wayland-egl', '>= 9.0.0',
|
|
|
|
'egl', '>= 9.0.0')
|
|
|
|
} , {
|
|
|
|
'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
|
|
|
cflags=['-DGL_APICALL=', '-DEGLAPI=',
|
|
|
|
'-DANGLE_NO_ALIASES', '-DANGLE_EXPORT='],
|
|
|
|
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)',
|
2015-10-17 12:17:49 +00:00
|
|
|
'func': check_pkg_config('libva', '>= 0.36.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',
|
2015-10-17 12:17:49 +00:00
|
|
|
'func': check_pkg_config('libva-x11', '>= 0.36.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',
|
2015-10-17 12:17:49 +00:00
|
|
|
'func': check_pkg_config('libva-wayland', '>= 0.36.0'),
|
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',
|
2016-01-20 18:41:29 +00:00
|
|
|
'func': check_pkg_config('libva-drm', '>= 0.36.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'],
|
|
|
|
'func': check_cc(header_name='shaderc/shaderc.h', lib='shaderc_shared'),
|
|
|
|
}, {
|
|
|
|
'name': 'shaderc-static',
|
|
|
|
'desc': 'libshaderc SPIR-V compiler (static library)',
|
|
|
|
'deps': '!shaderc-shared',
|
|
|
|
'groups': ['shaderc'],
|
|
|
|
'func': check_cc(header_name='shaderc/shaderc.h',
|
2017-12-25 01:51:55 +00:00
|
|
|
lib=['shaderc_combined', 'stdc++']),
|
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',
|
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
|
|
|
'func': check_cc(header_name=['d3d11_1.h', 'dxgi1_2.h']),
|
2017-08-15 16:41:16 +00:00
|
|
|
}, {
|
|
|
|
# We need MMAL/bcm_host/dispmanx APIs. Also, most RPI distros require
|
|
|
|
# every project to hardcode the paths to the include directories. Also,
|
|
|
|
# these headers are so broken that they spam tons of warnings by merely
|
|
|
|
# including them (compensate with -isystem and -fgnu89-inline).
|
2015-08-18 22:12:13 +00:00
|
|
|
'name': '--rpi',
|
2015-03-29 13:12:11 +00:00
|
|
|
'desc': 'Raspberry Pi support',
|
2017-08-15 16:41:16 +00:00
|
|
|
'func': compose_checks(
|
2017-12-20 09:25:37 +00:00
|
|
|
check_cc(cflags=["-isystem/opt/vc/include",
|
|
|
|
"-isystem/opt/vc/include/interface/vcos/pthreads",
|
|
|
|
"-isystem/opt/vc/include/interface/vmcs_host/linux",
|
|
|
|
"-fgnu89-inline"],
|
2017-08-15 16:41:16 +00:00
|
|
|
linkflags="-L/opt/vc/lib",
|
|
|
|
header_name="bcm_host.h",
|
|
|
|
lib=['mmal_core', 'mmal_util', 'mmal_vc_client', 'bcm_host']),
|
2018-01-20 15:10:42 +00:00
|
|
|
# We still need all OpenGL symbols, because the vo_gpu code is
|
2017-08-15 16:41:16 +00:00
|
|
|
# generic and supports anything from GLES2/OpenGL 2.1 to OpenGL 4 core.
|
2017-01-26 20:51:29 +00:00
|
|
|
check_cc(lib="EGL", linkflags="-lGLESv2"),
|
2017-08-15 16:41:16 +00:00
|
|
|
check_cc(lib="GLESv2"),
|
|
|
|
),
|
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',
|
|
|
|
'func': check_pkg_config('libplacebo >= 1.18.0'),
|
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
|
|
|
}, {
|
|
|
|
'name': 'vaapi-vulkan',
|
|
|
|
'desc': 'VAAPI Vulkan',
|
|
|
|
'deps': 'vaapi && vulkan',
|
|
|
|
'func': check_true,
|
2015-12-19 11:45:07 +00:00
|
|
|
}, {
|
|
|
|
'name': 'egl-helpers',
|
|
|
|
'desc': 'EGL helper functions',
|
2019-06-29 23:00:17 +00:00
|
|
|
'deps': 'egl-x11 || rpi || gl-wayland || egl-drm || ' +
|
2018-07-21 08:38:54 +00:00
|
|
|
'egl-angle-win32 || egl-android',
|
2015-03-29 13:12:11 +00:00
|
|
|
'func': check_true
|
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',
|
|
|
|
'desc': 'CUDA hwaccel',
|
vo_gpu: vulkan: hwdec_cuda: Add support for Vulkan interop
Despite their place in the tree, hwdecs can be loaded and used just
fine by the vulkan GPU backend.
In this change we add Vulkan interop support to the cuda/nvdec hwdec.
The overall process is mostly straight forward, so the main observation
here is that I had to implement it using an intermediate Vulkan buffer
because the direct VkImage usage is blocked by a bug in the nvidia
driver. When that gets fixed, I will revist this.
Nevertheless, the intermediate buffer copy is very cheap as it's all
device memory from start to finish. Overall CPU utilisiation is pretty
much the same as with the OpenGL GPU backend.
Note that we cannot use a single intermediate buffer - rather there
is a pool of them. This is done because the cuda memcpys are not
explicitly synchronised with the texture uploads.
In the basic case, this doesn't matter because the hwdec is not
asked to map and copy the next frame until after the previous one
is rendered. In the interpolation case, we need extra future frames
available immediately, so we'll be asked to map/copy those frames
and vulkan will be asked to render them. So far, harmless right? No.
All the vulkan rendering, including the upload steps, are batched
together and end up running very asynchronously from the CUDA copies.
The end result is that all the copies happen one after another, and
only then do the uploads happen, which means all textures are uploaded
the same, final, frame data. Whoops. Unsurprisingly this results in
the jerky motion because every 3/4 frames are identical.
The buffer pool ensures that we do not overwrite a buffer that is
still waiting to be uploaded. The ra_buf_pool implementation
automatically checks if existing buffers are available for use and
only creates a new one if it really has to. It's hard to say for sure
what the maximum number of buffers might be but we believe it won't
be so large as to make this strategy unusable. The highest I've seen
is 12 when using interpolation with tscale=bicubic.
A future optimisation here is to synchronise the CUDA copies with
respect to the vulkan uploads. This can be done with shared semaphores
that would ensure the copy of the second frames only happens after the
upload of the first frame, and so on. This isn't trivial to implement
as I'd have to first adjust the hwdec code to use asynchronous cuda;
without that, there's no way to use the semaphore for synchronisation.
This should result in fewer intermediate buffers being required.
2018-09-30 01:00:19 +00:00
|
|
|
'deps': '(gl || vulkan) && ffnvcodec',
|
2018-05-10 19:03:12 +00:00
|
|
|
'func': check_true,
|
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')
|
2014-10-17 15:07:01 +00:00
|
|
|
}, {
|
|
|
|
'name': '--apple-remote',
|
|
|
|
'desc': 'Apple Remote 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',
|
2014-10-17 15:07:01 +00:00
|
|
|
'func': check_true
|
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')
|
|
|
|
}, {
|
|
|
|
'name': '--macos-10-14-features',
|
|
|
|
'desc': 'macOS 10.14 SDK Features',
|
|
|
|
'deps': 'cocoa',
|
|
|
|
'func': check_macos_sdk('10.14')
|
|
|
|
}, {
|
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',
|
|
|
|
'desc': 'macOS opengl-cb 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'),
|
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',
|
2016-01-21 17:18:55 +00:00
|
|
|
help = "select Lua package which should be autodetected. Choices: 51 51deb 51obsd 51fbsd 52 52deb 52arch 52fbsd luajit")
|
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')
|
|
|
|
|
2016-11-16 15:18:11 +00:00
|
|
|
ctx.load('compiler_c')
|
|
|
|
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)
|
|
|
|
|
|
|
|
ctx.parse_dependencies(build_options)
|
|
|
|
ctx.parse_dependencies(main_dependencies)
|
|
|
|
ctx.parse_dependencies(audio_output_features)
|
|
|
|
ctx.parse_dependencies(video_output_features)
|
2016-06-09 19:05:33 +00:00
|
|
|
ctx.parse_dependencies(libav_dependencies)
|
2013-07-16 11:28:28 +00:00
|
|
|
ctx.parse_dependencies(hwaccel_features)
|
|
|
|
|
|
|
|
if ctx.options.LUA_VER:
|
|
|
|
ctx.options.enable_lua = 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
|
|
|
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()
|
|
|
|
|
2015-06-30 13:56:26 +00:00
|
|
|
def __write_version__(ctx):
|
2015-07-11 17:03:44 +00:00
|
|
|
ctx.env.VERSIONH_ST = '--versionh="%s"'
|
|
|
|
ctx.env.CWD_ST = '--cwd="%s"'
|
|
|
|
ctx.env.VERSIONSH_CWD = [ctx.srcnode.abspath()]
|
|
|
|
|
|
|
|
ctx(
|
|
|
|
source = 'version.sh',
|
|
|
|
target = 'version.h',
|
|
|
|
rule = 'sh ${SRC} ${CWD_ST:VERSIONSH_CWD} ${VERSIONH_ST:TGT}',
|
|
|
|
always = True,
|
|
|
|
update_outputs = 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)
|