mpv/wscript

1149 lines
40 KiB
Plaintext
Raw Normal View History

# vi: ft=python
import sys, os, re
sys.path.insert(0, os.path.join(os.getcwd(), 'waftools'))
sys.path.insert(0, os.getcwd())
from shlex import split
from waflib.Configure import conf
from waflib.Tools import c_preproc
from waflib.Tools.compiler_c import c_compiler
from waflib import Utils
from waftools.checks.generic import *
from waftools.checks.custom import *
c_preproc.go_absolute=True # enable system folders
c_preproc.standard_includes.append('/usr/local/include')
c_compiler['win32'].remove('msvc')
APPNAME = 'mpv'
"""
Dependency identifiers (for win32 vs. Unix):
wscript / C source meaning
--------------------------------------------------------------------------
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
uwp / HAVE_UWP: defined if building for UWP (basic Windows only)
"""
build_options = [
{
build: make LGPL mode final (via --enable-gpl) Rename --enable-preliminary-lgpl2 to --enable-gpl. This concludes the relicensing. Some things are still to do (relicensing some still-GPL optional code), but we consider the code included by --enable-gpl to be fully relicensed. The relicensing was performed by asking every known author for permission for relicensing it to LGPL version 2.1 "or later". If an author could not be contacted or permission could not be obtained, and the contribution was considered relevant for copyright purposes, the affected code was either excluded from LGPL mode (not built), or removed or rewritten. This is the standard in open source relicensing processes. Keep in mind that using LGPL mode is still on the user's own risk. Even though I claim that the relicensing was pretty clean and thorough (measured on the standards of the open source community¹), and I followed the advice of some actual experts, there is still a residual uncertainty due to the fact that I'm not an all-knowing entity (authors could have taken someone else's code and pretend it's their own) nor a lawyer (meaning I might lack associated authority or expertise), and the fact that the judicial system is far from deterministic. The relicensing was performed merely to the best of my knowledge. I reject all responsibility outside of that. This commit also cleans up the "Copyright" file to reflect the finalized relicensing process. ¹ Not to imply that the standards of commercial companies are much higher. Some major tech companies get away with stuff I would not consider clean. See #2033.
2017-10-10 16:21:01 +02:00
'name': '--lgpl',
'desc': 'LGPL (version 2.1 or later) build',
'default': 'disable',
'func': check_true,
}, {
'name': 'gpl',
build: make LGPL mode final (via --enable-gpl) Rename --enable-preliminary-lgpl2 to --enable-gpl. This concludes the relicensing. Some things are still to do (relicensing some still-GPL optional code), but we consider the code included by --enable-gpl to be fully relicensed. The relicensing was performed by asking every known author for permission for relicensing it to LGPL version 2.1 "or later". If an author could not be contacted or permission could not be obtained, and the contribution was considered relevant for copyright purposes, the affected code was either excluded from LGPL mode (not built), or removed or rewritten. This is the standard in open source relicensing processes. Keep in mind that using LGPL mode is still on the user's own risk. Even though I claim that the relicensing was pretty clean and thorough (measured on the standards of the open source community¹), and I followed the advice of some actual experts, there is still a residual uncertainty due to the fact that I'm not an all-knowing entity (authors could have taken someone else's code and pretend it's their own) nor a lawyer (meaning I might lack associated authority or expertise), and the fact that the judicial system is far from deterministic. The relicensing was performed merely to the best of my knowledge. I reject all responsibility outside of that. This commit also cleans up the "Copyright" file to reflect the finalized relicensing process. ¹ Not to imply that the standards of commercial companies are much higher. Some major tech companies get away with stuff I would not consider clean. See #2033.
2017-10-10 16:21:01 +02:00
'desc': 'GPL (version 2 or later) build',
'deps': '!lgpl',
'func': check_true,
}, {
'name': '--cplayer',
'desc': 'mpv CLI player',
'default': 'enable',
'func': check_true
}, {
'name': '--libmpv-shared',
'desc': 'shared library',
'default': 'disable',
'func': check_true
}, {
'name': '--libmpv-static',
'desc': 'static library',
'default': 'disable',
'deps': '!libmpv-shared',
'func': check_true
}, {
'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
}, {
'name': '--optimize',
'desc': 'whether to optimize',
'default': 'enable',
'func': check_true
}, {
'name': '--debug-build',
'desc': 'whether to compile-in debugging information',
'default': 'enable',
'func': check_true
}, {
# Reminder: normally always built, but enabled by MPV_LEAK_REPORT.
# Building it can be disabled only by defining NDEBUG through CFLAGS.
'name': '--ta-leak-report',
'desc': 'enable ta leak report by default (development only)',
'default': 'disable',
'func': check_true
}, {
'name': '--manpage-build',
'desc': 'manpage generation',
'func': check_ctx_vars('RST2MAN')
2015-12-29 20:57:09 +01:00
}, {
'name': '--html-build',
'desc': 'html manual generation',
'func': check_ctx_vars('RST2HTML'),
'default': 'disable',
}, {
'name': '--pdf-build',
'desc': 'pdf manual generation',
'func': check_ctx_vars('RST2PDF'),
'default': 'disable',
}, {
'name': 'libdl',
'desc': 'dynamic loader',
'func': check_libs(['dl'], check_statement('dlfcn.h', 'dlopen("", 0)'))
}, {
'name': '--cplugins',
'desc': 'C plugins',
'deps': 'libdl && !os-win32',
'func': check_cc(linkflags=['-rdynamic']),
}, {
# does nothing - left for backward and forward compatibility
'name': '--asm',
'desc': 'inline assembly (currently without effect)',
'default': 'enable',
'func': check_true,
}, {
'name': '--vector',
'desc': 'GCC vector instructions',
'func': check_statement([], 'float v __attribute__((vector_size(32)))'),
}, {
'name': '--clang-database',
'desc': 'generate a clang compilation database',
'func': check_true,
'default': 'disable',
} , {
'name': '--swift-static',
'desc': 'static Swift linking',
'deps': 'os-darwin',
'func': check_ctx_vars('SWIFT_LIB_STATIC'),
'default': 'disable'
}
]
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')
}, {
'name': 'mingw',
'desc': 'MinGW',
'deps': 'os-win32',
'func': check_statement('stdlib.h', 'int x = __MINGW32__;'
'int y = __MINGW64_VERSION_MAJOR'),
}, {
'name': 'posix',
'desc': 'POSIX environment',
'func': check_statement(['unistd.h'], 'long x = _POSIX_VERSION'),
}, {
'name': 'darwin',
'desc': 'Darwin environment',
'deps': 'os-darwin',
'func': check_true,
}, {
'name': '--android',
'desc': 'Android environment',
'func': check_statement('android/api-level.h', '(void)__ANDROID__'), # arbitrary android-specific header
}, {
'name': '--android-media-ndk',
'desc': 'Android Media APIs',
'deps': 'android',
# header only, library is dynamically loaded
'func': check_statement('media/NdkImageReader.h', 'int x = AIMAGE_FORMAT_PRIVATE'),
}, {
'name': '--tvos',
'desc': 'tvOS environment',
'func': check_statement(
['TargetConditionals.h', 'assert.h'],
'static_assert(TARGET_OS_TV, "TARGET_OS_TV defined to zero!")'
),
}, {
'name': '--egl-android',
'desc': 'Android EGL support',
'deps': 'android',
'groups': [ 'gl' ],
'func': check_cc(lib=['android', 'EGL']),
}, {
'name': 'posix-or-mingw',
'desc': 'development environment',
'deps': 'posix || mingw',
'func': check_true,
'req': True,
'fmsg': 'Unable to find either POSIX or MinGW-w64 environment, ' \
'or compiler does not work.',
}, {
'name': '--swift',
'desc': 'macOS Swift build tools',
'deps': 'os-darwin',
'func': compose_checks(check_swift('4.1'), check_macos_sdk('10.10')),
}, {
'name': '--uwp',
'desc': 'Universal Windows Platform',
'default': 'disable',
'deps': 'os-win32 && mingw && !cplayer',
'func': check_cc(lib=['windowsapp']),
}, {
'name': 'win32-desktop',
'desc': 'win32 desktop APIs',
'deps': '(os-win32 || os-cygwin) && !uwp',
'func': check_cc(lib=['avrt',
'dwmapi',
'gdi32',
'ole32',
'uuid',
'uxtheme',
'version',
'winmm']),
}, {
'name': '--win32-internal-pthreads',
'desc': 'internal pthread wrapper for win32 (Vista+)',
'deps': 'os-win32 && !posix',
'func': check_true,
}, {
'name': 'pthreads',
'desc': 'POSIX threads',
'func': check_pthreads,
'req': True,
'fmsg': 'Unable to find pthreads support.'
}, {
# NB: this works only if a source file includes osdep/threads.h
# also, technically, triggers undefined behavior (reserved names)
'name': '--pthread-debug',
'desc': 'pthread runtime debugging wrappers',
'default': 'disable',
'func': check_cc(cflags='-DMP_PTHREAD_DEBUG'),
# The win32 wrapper defines pthreads symbols as macros only.
'deps_neg': 'win32-internal-pthreads',
}, {
'name': '--stdatomic',
'desc': 'C11 stdatomic.h',
'func': check_libs(['atomic'],
check_statement('stdatomic.h',
'atomic_int_least64_t test = ATOMIC_VAR_INIT(123);'
'atomic_fetch_add(&test, 1)')),
'req': True,
'fmsg': 'C11 atomics are required; you may need a newer compiler',
}, {
'name': 'librt',
'desc': 'linking with -lrt',
'deps': 'pthreads',
'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',
'deps': 'os-win32 || os-cygwin',
'func': check_true
}, {
'name': 'glob-posix',
'desc': 'glob() POSIX support',
'deps': '!(os-win32 || os-cygwin)',
'func': check_statement('glob.h', 'glob("filename", 0, 0, 0)'),
}, {
'name': 'glob-win32',
'desc': 'glob() win32 replacement',
'deps': '!posix && (os-win32 || os-cygwin)',
'func': check_true
}, {
'name': 'glob',
'desc': 'any glob() support',
'deps': 'glob-posix || glob-win32',
'func': check_true,
}, {
'name': 'vt.h',
'desc': 'vt.h',
'func': check_statement(['sys/vt.h', 'sys/ioctl.h'],
'int m; ioctl(0, VT_GETMODE, &m)'),
}, {
'name': 'consio.h',
'desc': 'consio.h',
'deps': '!vt.h',
'func': check_statement(['sys/consio.h', 'sys/ioctl.h'],
'int m; ioctl(0, VT_GETMODE, &m)'),
vo_opengl: add DRM EGL backend Notes: - Unfortunately the only way to talk to EGL from within DRM I could find involves linking with GBM (generic buffer management for Mesa.) Because of this, I'm pretty sure it won't work with proprietary NVidia drivers, but then again, last time I checked NVidia didn't offer proper screen resolution for VT. - VT switching doesn't seem to work at all. It's worth mentioning that using vo_drm before introduction of VT switcher had an anomaly where user could switch to another VT and input text to it, while video played on top of that VT. However, that isn't the case with drm_egl: I can't switch to other VT during playback like this. This makes me think that it's either a limitation coming from my firmware or from EGL/KMS itself rather than a bug with my code. Nonetheless, I still left (untestable) VT switching code in place, in case it's useful to someone else. - The mode_id, connector_id and device_path should be configurable for power users and people who wish to watch videos on nonprimary screen. Unfortunately I didn't see anything that would allow OpenGL backends to register their own set of options. At the same time, adding them to global namespace is pointless. - A few dozens of lines could be shared with vo_drm (setting up VT switching, most of code behind page flipping). I don't have any strong opinion on this. - Sometimes I get minor visual glitches. I'm not sure if there's a race condition of some sort, unitialized variable (doubtful), or if it's buggy driver. (I'm using integrated Intel HD Graphics 4400 with Mesa) - .config and .control are very minimal. Signed-off-by: wm4 <wm4@nowhere>
2015-11-07 19:06:57 +01:00
}, {
'name': 'gbm.h',
'desc': 'gbm.h',
'func': check_cc(header_name=['stdio.h', 'gbm.h']),
}, {
'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',
'deps': '!glibc-thread-name',
'func': check_statement('pthread.h',
'pthread_setname_np("ducks")', use=['pthreads']),
}, {
'name': 'bsd-thread-name',
'desc': 'BSD API for setting thread name',
'deps': '!(glibc-thread-name || osx-thread-name)',
'func': check_statement(['pthread.h', 'pthread_np.h'],
'pthread_set_name_np(pthread_self(), "ducks")',
use=['pthreads']),
}, {
'name': 'bsd-fstatfs',
'desc': "BSD's fstatfs()",
'func': check_statement(['sys/param.h', 'sys/mount.h'],
'struct statfs fs; fstatfs(0, &fs); fs.f_fstypename')
}, {
'name': 'linux-fstatfs',
'desc': "Linux's fstatfs()",
'deps': 'os-linux',
'func': check_statement('sys/vfs.h',
'struct statfs fs; fstatfs(0, &fs); fs.f_namelen')
}, {
'name': 'linux-input-event-codes',
'desc': "Linux's input-event-codes.h",
'func': check_cc(header_name=['linux/input-event-codes.h']),
}, {
'name' : '--lua',
'desc' : 'Lua',
'func': check_lua,
}, {
'name' : '--javascript',
'desc' : 'Javascript (MuJS backend)',
'func': check_pkg_config('mujs', '>= 1.0.0'),
}, {
'name': 'libass',
'desc': 'SSA/ASS support',
'func': check_pkg_config('libass', '>= 0.12.2'),
'req': True,
'fmsg': "Unable to find development files for libass, or the version " +
"found is too old. Aborting."
}, {
'name': '--zlib',
'desc': 'zlib',
'func': any_check(check_pkg_config('zlib'),
check_libs(['z'], check_statement('zlib.h', 'inflate(0, Z_NO_FLUSH)'))),
'req': True,
'fmsg': 'Unable to find development files for zlib.'
}, {
'name': '--libbluray',
'desc': 'Bluray support',
'func': check_pkg_config('libbluray', '>= 0.3.0'),
#'default': 'disable',
}, {
'name': '--dvdnav',
'desc': 'dvdnav support',
'deps': 'gpl',
'func': check_pkg_config('dvdnav', '>= 4.2.0',
'dvdread', '>= 4.1.0'),
'default': 'disable',
}, {
'name': '--cdda',
'desc': 'cdda support (libcdio)',
'deps': 'gpl',
'func': check_pkg_config('libcdio_paranoia'),
'default': 'disable',
}, {
'name': '--uchardet',
'desc': 'uchardet support',
'deps': 'iconv',
'func': check_pkg_config('uchardet'),
}, {
'name': '--rubberband',
'desc': 'librubberband support',
'func': check_pkg_config('rubberband', '>= 1.8.0'),
}, {
'name': '--zimg',
'desc': 'libzimg support (high quality software scaler)',
'func': check_pkg_config('zimg', '>= 2.9'),
}, {
'name': '--lcms2',
'desc': 'LCMS2 support',
'func': check_pkg_config('lcms2', '>= 2.6'),
}, {
'name': '--vapoursynth',
'desc': 'VapourSynth filter bridge',
'func': check_pkg_config('vapoursynth', '>= 24',
'vapoursynth-script', '>= 23'),
}, {
'name': '--libarchive',
'desc': 'libarchive wrapper for reading zip files and more',
'func': check_pkg_config('libarchive >= 3.4.0'),
}, {
'name': '--dvbin',
'desc': 'DVB input module',
'deps': 'gpl',
'func': check_true,
'default': 'disable',
}, {
'name': '--sdl2',
'desc': 'SDL2',
'func': check_pkg_config('sdl2'),
'default': 'disable',
}, {
'name': '--sdl2-gamepad',
'desc': 'SDL2 gamepad input',
'deps': 'sdl2',
'func': check_true,
}, {
'name': 'jpegxl',
'desc': 'JPEG XL support via libavcodec',
'func': check_pkg_config('libavcodec >= 59.27.100'),
}, {
'name': 'rubberband-3',
'desc': 'new engine support for librubberband',
'func': check_pkg_config('rubberband >= 3.0.0'),
2023-01-24 10:26:25 +01:00
}, {
'name': 'zimg-st428',
2023-03-27 22:42:17 +02:00
'desc': 'ZIMG support for ZIMG_TRANSFER_ST428',
2023-01-24 10:26:25 +01:00
'func': check_pkg_config('zimg', '>= 3.0.5'),
}
]
libav_dependencies = [
{
2017-12-05 09:25:00 +01:00
'name': 'ffmpeg',
Remove remains of Libav compatibility Libav seems rather dead: no release for 2 years, no new git commits in master for almost a year (with one exception ~6 months ago). From what I can tell, some developers resigned themselves to the horrifying idea to post patches to ffmpeg-devel instead, while the rest of the developers went on to greener pastures. Libav was a better project than FFmpeg. Unfortunately, FFmpeg won, because it managed to keep the name and website. Libav was pushed more and more into obscurity: while there was initially a big push for Libav, FFmpeg just remained "in place" and visible for most people. FFmpeg was slowly draining all manpower and energy from Libav. A big part of this was that FFmpeg stole code from Libav (regular merges of the entire Libav git tree), making it some sort of Frankenstein mirror of Libav, think decaying zombie with additional legs ("features") nailed to it. "Stealing" surely is the wrong word; I'm just aping the language that some of the FFmpeg members used to use. All that is in the past now, I'm probably the only person left who is annoyed by this, and with this commit I'm putting this decade long problem finally to an end. I just thought I'd express my annoyance about this fucking shitshow one last time. The most intrusive change in this commit is the resample filter, which originally used libavresample. Since the FFmpeg developer refused to enable libavresample by default for drama reasons, and the API was slightly different, so the filter used some big preprocessor mess to make it compatible to libswresample. All that falls away now. The simplification to the build system is also significant.
2020-02-16 15:14:55 +01:00
'desc': 'FFmpeg library',
'func': check_pkg_config('libavutil', '>= 56.70.100',
'libavcodec', '>= 58.134.100',
'libavformat', '>= 58.76.100',
'libswscale', '>= 5.9.100',
'libavfilter', '>= 7.110.100',
'libswresample', '>= 3.9.100'),
'req': True,
'fmsg': "Unable to find development files for some of the required \
Remove remains of Libav compatibility Libav seems rather dead: no release for 2 years, no new git commits in master for almost a year (with one exception ~6 months ago). From what I can tell, some developers resigned themselves to the horrifying idea to post patches to ffmpeg-devel instead, while the rest of the developers went on to greener pastures. Libav was a better project than FFmpeg. Unfortunately, FFmpeg won, because it managed to keep the name and website. Libav was pushed more and more into obscurity: while there was initially a big push for Libav, FFmpeg just remained "in place" and visible for most people. FFmpeg was slowly draining all manpower and energy from Libav. A big part of this was that FFmpeg stole code from Libav (regular merges of the entire Libav git tree), making it some sort of Frankenstein mirror of Libav, think decaying zombie with additional legs ("features") nailed to it. "Stealing" surely is the wrong word; I'm just aping the language that some of the FFmpeg members used to use. All that is in the past now, I'm probably the only person left who is annoyed by this, and with this commit I'm putting this decade long problem finally to an end. I just thought I'd express my annoyance about this fucking shitshow one last time. The most intrusive change in this commit is the resample filter, which originally used libavresample. Since the FFmpeg developer refused to enable libavresample by default for drama reasons, and the API was slightly different, so the filter used some big preprocessor mess to make it compatible to libswresample. All that falls away now. The simplification to the build system is also significant.
2020-02-16 15:14:55 +01:00
FFmpeg libraries. Git master is recommended."
}, {
'name': 'av-channel-layout',
'desc': 'FFmpeg AVChannelLayout API',
'func': check_pkg_config('libavutil', '>= 57.24.100'),
}, {
'name': '--libavdevice',
'desc': 'libavdevice',
'func': check_pkg_config('libavdevice', '>= 58.13.100'),
}
]
audio_output_features = [
{
'name': '--sdl2-audio',
'desc': 'SDL2 audio output',
'deps': 'sdl2',
'func': check_true,
}, {
'name': '--oss-audio',
'desc': 'OSSv4 audio output',
'func': check_statement(['sys/soundcard.h'], 'int x = SNDCTL_DSP_SETPLAYVOL'),
'deps': 'posix && gpl',
}, {
'name': '--pipewire',
'desc': 'PipeWire audio output',
'func': check_pkg_config('libpipewire-0.3', '>= 0.3.19')
}, {
'name': '--sndio',
'desc': 'sndio audio input/output',
'func': check_pkg_config('sndio'),
'default': 'disable'
}, {
'name': '--pulse',
'desc': 'PulseAudio audio output',
'func': check_pkg_config('libpulse', '>= 1.0')
}, {
'name': '--jack',
'desc': 'JACK audio output',
'deps': 'gpl',
'func': check_pkg_config('jack'),
}, {
'name': '--openal',
'desc': 'OpenAL audio output',
'func': check_pkg_config('openal', '>= 1.13'),
'default': 'disable'
}, {
'name': '--opensles',
'desc': 'OpenSL ES audio output',
'func': check_statement('SLES/OpenSLES.h', 'slCreateEngine', lib="OpenSLES"),
}, {
'name': '--alsa',
'desc': 'ALSA audio output',
'func': check_pkg_config('alsa', '>= 1.0.18'),
}, {
'name': '--coreaudio',
'desc': 'CoreAudio audio output',
'func': check_cc(
fragment=load_fragment('coreaudio.c'),
framework_name=['CoreFoundation', 'CoreAudio', 'AudioUnit', 'AudioToolbox'])
}, {
'name': '--audiounit',
'desc': 'AudioUnit output for iOS',
'func': check_cc(
fragment=load_fragment('audiounit.c'),
framework_name=['Foundation', 'AudioToolbox'])
}, {
'name': '--wasapi',
'desc': 'WASAPI audio output',
'deps': 'os-win32 || os-cygwin',
'func': check_cc(fragment=load_fragment('wasapi.c')),
}
]
video_output_features = [
{
'name': '--sdl2-video',
'desc': 'SDL2 video output',
'deps': 'sdl2',
'deps_neg': 'cocoa',
'func': check_true,
}, {
'name': '--cocoa',
'desc': 'Cocoa',
'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 19:06:57 +01:00
}, {
'name': '--drm',
'desc': 'DRM',
'deps': 'vt.h || consio.h',
'func': check_pkg_config('libdrm', '>= 2.4.75'),
vo_opengl: add DRM EGL backend Notes: - Unfortunately the only way to talk to EGL from within DRM I could find involves linking with GBM (generic buffer management for Mesa.) Because of this, I'm pretty sure it won't work with proprietary NVidia drivers, but then again, last time I checked NVidia didn't offer proper screen resolution for VT. - VT switching doesn't seem to work at all. It's worth mentioning that using vo_drm before introduction of VT switcher had an anomaly where user could switch to another VT and input text to it, while video played on top of that VT. However, that isn't the case with drm_egl: I can't switch to other VT during playback like this. This makes me think that it's either a limitation coming from my firmware or from EGL/KMS itself rather than a bug with my code. Nonetheless, I still left (untestable) VT switching code in place, in case it's useful to someone else. - The mode_id, connector_id and device_path should be configurable for power users and people who wish to watch videos on nonprimary screen. Unfortunately I didn't see anything that would allow OpenGL backends to register their own set of options. At the same time, adding them to global namespace is pointless. - A few dozens of lines could be shared with vo_drm (setting up VT switching, most of code behind page flipping). I don't have any strong opinion on this. - Sometimes I get minor visual glitches. I'm not sure if there's a race condition of some sort, unitialized variable (doubtful), or if it's buggy driver. (I'm using integrated Intel HD Graphics 4400 with Mesa) - .config and .control are very minimal. Signed-off-by: wm4 <wm4@nowhere>
2015-11-07 19:06:57 +01:00
}, {
'name': '--gbm',
'desc': 'GBM',
'deps': 'gbm.h',
'func': check_pkg_config('gbm', '>= 17.1.0'),
} , {
'name': 'wayland-scanner',
'desc': 'wayland-scanner',
'func': check_program('wayland-scanner', 'WAYSCAN')
} , {
'name': 'wayland-protocols',
'desc': 'wayland-protocols',
'func': check_wl_protocols
} , {
'name': '--wayland',
'desc': 'Wayland',
'deps': 'wayland-protocols && wayland-scanner && linux-input-event-codes',
'func': check_pkg_config('wayland-client', '>= 1.15.0',
'wayland-cursor', '>= 1.15.0',
'xkbcommon', '>= 0.3.0'),
} , {
'name': 'wayland-protocols-1-24',
'desc': 'wayland-protocols version 1.24+',
'deps': 'wayland',
'func': check_pkg_config('wayland-protocols >= 1.24'),
} , {
'name': 'wayland-protocols-1-27',
'desc': 'wayland-protocols version 1.27+',
'deps': 'wayland',
'func': check_pkg_config('wayland-protocols >= 1.27'),
} , {
'name': 'wayland-protocols-1-31',
'desc': 'wayland-protocols version 1.31+',
'deps': 'wayland',
'func': check_pkg_config('wayland-protocols >= 1.31'),
} , {
'name': 'memfd_create',
'desc': "Linux's memfd_create()",
'deps': 'wayland',
'func': check_statement('sys/mman.h',
'memfd_create("mpv", MFD_CLOEXEC | MFD_ALLOW_SEALING)')
} , {
'name': '--x11',
'desc': 'X11',
'deps': 'gpl',
'func': check_pkg_config('x11', '>= 1.0.0',
'xscrnsaver', '>= 1.0.0',
'xext', '>= 1.0.0',
'xinerama', '>= 1.0.0',
x11: support xorg present extension This builds off of present_sync which was introduced in a previous commit to support xorg's present extension in all of the X11 backends (sans vdpau) in mpv. It turns out there is an Xpresent library that integrates the xorg present extention with Xlib (which barely anyone seems to use), so this can be added without too much trouble. The workflow is to first setup the event by telling Xorg we would like to receive PresentCompleteNotify (there are others in the extension but this is the only one we really care about). After that, just call XPresentNotifyMSC after every buffer swap with a target_msc of 0. Xorg then returns the last presentation through its usual event loop and we go ahead and use that information to update mpv's values for vsync timing purposes. One theoretical weakness of this approach is that the present event is put on the same queue as the rest of the XEvents. It would be nicer for it be placed somewhere else so we could just wait on that queue without having to deal with other possible events in there. In theory, xcb could do that with special events, but it doesn't really matter in practice. Unsurprisingly, this doesn't work on NVIDIA. Well NVIDIA does actually receive presentation events, but for whatever the calculations used make timings worse which defeats the purpose. This works perfectly fine on Mesa however. Utilizing the previous commit that detects Xrandr providers, we can enable this mechanism for users that have both Mesa and not NVIDIA (to avoid messing up anyone that has a switchable graphics system or such). Patches welcome if anyone figures out how to fix this on NVIDIA. Unlike the EGL/GLX sync extensions, the present extension works with any graphics API (good for vulkan since its timing extension has been in development hell). NVIDIA also happens to have zero support for the EGL/GLX sync extensions, so we can just remove it with no loss. Only Xorg ever used it and other backends already have their own present methods. vo_vdpau VO is a special case that has its own fancying timing code in its flip_page. This presumably works well, and I have no way of testing it so just leave it as it is.
2022-06-10 18:49:38 +02:00
'xpresent', '>= 1.0.0',
'xrandr', '>= 1.2.0'),
} , {
'name': '--xv',
'desc': 'Xv video output',
'deps': 'x11',
'func': check_pkg_config('xv'),
} , {
'name': '--gl-cocoa',
'desc': 'OpenGL Cocoa Backend',
'deps': 'cocoa',
'groups': [ 'gl' ],
'func': check_statement('IOSurface/IOSurface.h',
'IOSurfaceRef surface;',
framework='IOSurface',
cflags=['-DGL_SILENCE_DEPRECATION'])
} , {
'name': '--gl-x11',
'desc': 'OpenGL X11/GLX (deprecated/legacy)',
'deps': 'x11',
'groups': [ 'gl' ],
'func': check_libs(['GL', 'GL Xdamage'],
check_cc(fragment=load_fragment('gl_x11.c'),
use=['x11', 'libdl', 'pthreads'])),
'default': 'disable',
}, {
'name': '--rpi',
'desc': 'Raspberry Pi support',
'func': check_egl_provider(name='brcmegl', check=any_check(
check_pkg_config('brcmegl'),
check_pkg_config('/opt/vc/lib/pkgconfig/brcmegl.pc')
)),
'default': 'disable',
x11: require EGL 1.5 and use eglGetPlatformDisplay() eglGetPlatform() is a broken API, since it takes a windowing specific argument, yet is supposed to work for multiple APIs at the same time. On Linux, it can take both a X11 "Display" and a "wl_display". Obviously there is no way to specify what kind of display the argument is (it's just a void*). Mesa has _eglNativePlatformDetectNativeDisplay, which does funny stuff to try to guess the display type, including trying to call mincore() to determine whether the pointer can be accessed at all. I guess this recently accidentally broke (as a bug), but on the other hand, maybe it's time to do this properly. The fix is using eglGetPlaformDisplay(). This requires EGL 1.5, plus Mesa needs to support the associated platform extension (EGL_KHR_platform_x11). Since I see no reasonable way to do this in a compatible way, just require that EGL 1.5 is available. The problem is that EGL 1.4 seems to require you to create a display to query EGL version and extension, and you have a chicken-and-egg problem. It's very stupid. Maybe you could jump through some more hoops to get something compatible, but fuck that. Users on "too old" Mesa will fall back to GLX (which we keep around for a regrettable company known by the name of Nvidia). I think Wayland and GBM should do the same. They're sufficiently bleeding-edge that you can expect them to have EGL 1.5. On the other hand, the cursed RPI code will have to stay with a eglGetDisplay(). Speculative fix for #7154. (Rant about EGL follows. Actually I deleted it.)
2019-11-16 20:54:42 +01:00
} , {
'name': '--egl',
'desc': 'EGL 1.4',
x11: require EGL 1.5 and use eglGetPlatformDisplay() eglGetPlatform() is a broken API, since it takes a windowing specific argument, yet is supposed to work for multiple APIs at the same time. On Linux, it can take both a X11 "Display" and a "wl_display". Obviously there is no way to specify what kind of display the argument is (it's just a void*). Mesa has _eglNativePlatformDetectNativeDisplay, which does funny stuff to try to guess the display type, including trying to call mincore() to determine whether the pointer can be accessed at all. I guess this recently accidentally broke (as a bug), but on the other hand, maybe it's time to do this properly. The fix is using eglGetPlaformDisplay(). This requires EGL 1.5, plus Mesa needs to support the associated platform extension (EGL_KHR_platform_x11). Since I see no reasonable way to do this in a compatible way, just require that EGL 1.5 is available. The problem is that EGL 1.4 seems to require you to create a display to query EGL version and extension, and you have a chicken-and-egg problem. It's very stupid. Maybe you could jump through some more hoops to get something compatible, but fuck that. Users on "too old" Mesa will fall back to GLX (which we keep around for a regrettable company known by the name of Nvidia). I think Wayland and GBM should do the same. They're sufficiently bleeding-edge that you can expect them to have EGL 1.5. On the other hand, the cursed RPI code will have to stay with a eglGetDisplay(). Speculative fix for #7154. (Rant about EGL follows. Actually I deleted it.)
2019-11-16 20:54:42 +01:00
'groups': [ 'gl' ],
'func': check_egl_provider('1.4')
} , {
'name': '--egl-x11',
'desc': 'OpenGL X11 EGL Backend',
'deps': 'x11 && egl',
'groups': [ 'gl' ],
x11: require EGL 1.5 and use eglGetPlatformDisplay() eglGetPlatform() is a broken API, since it takes a windowing specific argument, yet is supposed to work for multiple APIs at the same time. On Linux, it can take both a X11 "Display" and a "wl_display". Obviously there is no way to specify what kind of display the argument is (it's just a void*). Mesa has _eglNativePlatformDetectNativeDisplay, which does funny stuff to try to guess the display type, including trying to call mincore() to determine whether the pointer can be accessed at all. I guess this recently accidentally broke (as a bug), but on the other hand, maybe it's time to do this properly. The fix is using eglGetPlaformDisplay(). This requires EGL 1.5, plus Mesa needs to support the associated platform extension (EGL_KHR_platform_x11). Since I see no reasonable way to do this in a compatible way, just require that EGL 1.5 is available. The problem is that EGL 1.4 seems to require you to create a display to query EGL version and extension, and you have a chicken-and-egg problem. It's very stupid. Maybe you could jump through some more hoops to get something compatible, but fuck that. Users on "too old" Mesa will fall back to GLX (which we keep around for a regrettable company known by the name of Nvidia). I think Wayland and GBM should do the same. They're sufficiently bleeding-edge that you can expect them to have EGL 1.5. On the other hand, the cursed RPI code will have to stay with a eglGetDisplay(). Speculative fix for #7154. (Rant about EGL follows. Actually I deleted it.)
2019-11-16 20:54:42 +01:00
'func': check_true,
vo_opengl: add DRM EGL backend Notes: - Unfortunately the only way to talk to EGL from within DRM I could find involves linking with GBM (generic buffer management for Mesa.) Because of this, I'm pretty sure it won't work with proprietary NVidia drivers, but then again, last time I checked NVidia didn't offer proper screen resolution for VT. - VT switching doesn't seem to work at all. It's worth mentioning that using vo_drm before introduction of VT switcher had an anomaly where user could switch to another VT and input text to it, while video played on top of that VT. However, that isn't the case with drm_egl: I can't switch to other VT during playback like this. This makes me think that it's either a limitation coming from my firmware or from EGL/KMS itself rather than a bug with my code. Nonetheless, I still left (untestable) VT switching code in place, in case it's useful to someone else. - The mode_id, connector_id and device_path should be configurable for power users and people who wish to watch videos on nonprimary screen. Unfortunately I didn't see anything that would allow OpenGL backends to register their own set of options. At the same time, adding them to global namespace is pointless. - A few dozens of lines could be shared with vo_drm (setting up VT switching, most of code behind page flipping). I don't have any strong opinion on this. - Sometimes I get minor visual glitches. I'm not sure if there's a race condition of some sort, unitialized variable (doubtful), or if it's buggy driver. (I'm using integrated Intel HD Graphics 4400 with Mesa) - .config and .control are very minimal. Signed-off-by: wm4 <wm4@nowhere>
2015-11-07 19:06:57 +01:00
} , {
'name': '--egl-drm',
'desc': 'OpenGL DRM EGL Backend',
'deps': 'drm && gbm && egl',
vo_opengl: add DRM EGL backend Notes: - Unfortunately the only way to talk to EGL from within DRM I could find involves linking with GBM (generic buffer management for Mesa.) Because of this, I'm pretty sure it won't work with proprietary NVidia drivers, but then again, last time I checked NVidia didn't offer proper screen resolution for VT. - VT switching doesn't seem to work at all. It's worth mentioning that using vo_drm before introduction of VT switcher had an anomaly where user could switch to another VT and input text to it, while video played on top of that VT. However, that isn't the case with drm_egl: I can't switch to other VT during playback like this. This makes me think that it's either a limitation coming from my firmware or from EGL/KMS itself rather than a bug with my code. Nonetheless, I still left (untestable) VT switching code in place, in case it's useful to someone else. - The mode_id, connector_id and device_path should be configurable for power users and people who wish to watch videos on nonprimary screen. Unfortunately I didn't see anything that would allow OpenGL backends to register their own set of options. At the same time, adding them to global namespace is pointless. - A few dozens of lines could be shared with vo_drm (setting up VT switching, most of code behind page flipping). I don't have any strong opinion on this. - Sometimes I get minor visual glitches. I'm not sure if there's a race condition of some sort, unitialized variable (doubtful), or if it's buggy driver. (I'm using integrated Intel HD Graphics 4400 with Mesa) - .config and .control are very minimal. Signed-off-by: wm4 <wm4@nowhere>
2015-11-07 19:06:57 +01:00
'groups': [ 'gl' ],
'func': check_true,
} , {
'name': '--gl-wayland',
'desc': 'OpenGL Wayland Backend',
'deps': 'wayland && egl',
'groups': [ 'gl' ],
'func': check_pkg_config('wayland-egl', '>= 9.0.0')
} , {
'name': '--gl-win32',
'desc': 'OpenGL Win32 Backend',
'deps': 'win32-desktop',
'groups': [ 'gl' ],
'func': check_statement('windows.h', 'wglCreateContext(0)',
lib='opengl32')
} , {
'name': '--gl-dxinterop',
'desc': 'OpenGL/DirectX Interop Backend',
'deps': 'gl-win32',
'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'))
} , {
'name': '--egl-angle',
'desc': 'OpenGL ANGLE headers',
'deps': 'os-win32 || os-cygwin',
'groups': [ 'gl' ],
'func': check_statement(['EGL/egl.h', 'EGL/eglext.h', 'EGL/eglext_angle.h'],
'int x = EGL_D3D_TEXTURE_2D_SHARE_HANDLE_ANGLE; '
'PFNEGLCREATEDEVICEANGLEPROC y = NULL')
2016-11-22 23:26:43 +01:00
} , {
'name': '--egl-angle-lib',
'desc': 'OpenGL Win32 ANGLE Library',
'deps': 'egl-angle',
2016-11-22 23:26:43 +01:00
'groups': [ 'gl' ],
'func': check_statement(['EGL/egl.h'],
'eglCreateWindowSurface(0, 0, 0, 0)',
lib=['EGL', 'GLESv2', 'dxguid', 'd3d9',
'gdi32', 'stdc++'])
}, {
'name': '--egl-angle-win32',
'desc': 'OpenGL Win32 ANGLE Backend',
'deps': 'egl-angle && win32-desktop',
'groups': [ 'gl' ],
'func': check_true,
} , {
'name': '--vdpau',
'desc': 'VDPAU acceleration',
'deps': 'x11',
'func': check_pkg_config('vdpau', '>= 0.2'),
} , {
'name': '--vdpau-gl-x11',
'desc': 'VDPAU with OpenGL/X11',
'deps': 'vdpau && gl-x11',
'func': check_true,
}, {
'name': '--vaapi',
'desc': 'VAAPI acceleration',
'deps': 'libdl && (x11 || wayland || egl-drm)',
'func': check_pkg_config('libva', '>= 1.1.0'),
}, {
'name': '--vaapi-x11',
'desc': 'VAAPI (X11 support)',
'deps': 'vaapi && x11',
'func': check_pkg_config('libva-x11', '>= 1.1.0'),
}, {
'name': '--vaapi-wayland',
'desc': 'VAAPI (Wayland support)',
'deps': 'vaapi && gl-wayland',
'func': check_pkg_config('libva-wayland', '>= 1.1.0'),
}, {
'name': 'dmabuf-wayland',
'desc': 'Wayland dmabuf support',
'deps': 'wayland && memfd_create && (vaapi-wayland || drm)',
'func': check_true,
}, {
'name': '--vaapi-drm',
'desc': 'VAAPI (DRM/EGL support)',
'deps': 'vaapi && egl-drm',
'func': check_pkg_config('libva-drm', '>= 1.1.0'),
}, {
'name': '--vaapi-x-egl',
'desc': 'VAAPI EGL on X11',
'deps': 'vaapi-x11 && egl-x11',
'func': check_true,
}, {
'name': 'vaapi-egl',
'desc': 'VAAPI EGL',
'deps': 'vaapi-x-egl || vaapi-wayland || vaapi-drm',
'func': check_true,
}, {
'name': '--caca',
'desc': 'CACA',
'deps': 'gpl',
'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',
'deps': 'win32-desktop && gpl',
'func': check_cc(header_name='d3d9.h'),
}, {
'name': 'shaderc-shared',
'desc': 'libshaderc SPIR-V compiler (shared library)',
'deps': '!static-build',
'groups': ['shaderc'],
'func': check_pkg_config('shaderc'),
}, {
'name': 'shaderc-static',
'desc': 'libshaderc SPIR-V compiler (static library)',
'deps': '!shaderc-shared',
'groups': ['shaderc'],
'func': any_check(check_pkg_config('shaderc_combined'),
check_pkg_config('shaderc_static')),
vo_gpu: d3d11: initial implementation This is a new RA/vo_gpu backend that uses Direct3D 11. The GLSL generated by vo_gpu is cross-compiled to HLSL with SPIRV-Cross. What works: - All of mpv's internal shaders should work, including compute shaders. - Some external shaders have been tested and work, including RAVU and adaptive-sharpen. - Non-dumb mode works, even on very old hardware. Most features work at feature level 9_3 and all features work at feature level 10_0. Some features also work at feature level 9_1 and 9_2, but without high-bit- depth FBOs, it's not very useful. (Hardware this old is probably not fast enough for advanced features anyway.) Note: This is more compatible than ANGLE, which requires 9_3 to work at all (GLES 2.0,) and 10_1 for non-dumb-mode (GLES 3.0.) - Hardware decoding with D3D11VA, including decoding of 10-bit formats without truncation to 8-bit. What doesn't work / can be improved: - PBO upload and direct rendering does not work yet. Direct rendering requires persistent-mapped PBOs because the decoder needs to be able to read data from images that have already been decoded and uploaded. Unfortunately, it seems like persistent-mapped PBOs are fundamentally incompatible with D3D11, which requires all resources to use driver- managed memory and requires memory to be unmapped (and hence pointers to be invalidated) when a resource is used in a draw or copy operation. However it might be possible to use D3D11's limited multithreading capabilities to emulate some features of PBOs, like asynchronous texture uploading. - The blit() and clear() operations don't have equivalents in the D3D11 API that handle all cases, so in most cases, they have to be emulated with a shader. This is currently done inside ra_d3d11, but ideally it would be done in generic code, so it can take advantage of mpv's shader generation utilities. - SPIRV-Cross is used through a NIH C-compatible wrapper library, since it does not expose a C interface itself. The library is available here: https://github.com/rossy/crossc - The D3D11 context could be made to support more modern DXGI features in future. For example, it should be possible to add support for high-bit-depth and HDR output with DXGI 1.5/1.6.
2017-09-07 12:18:06 +02:00
}, {
'name': '--shaderc',
'desc': 'libshaderc SPIR-V compiler',
'deps': 'shaderc-shared || shaderc-static',
'func': check_true,
}, {
'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 12:18:06 +02:00
}, {
'name': '--spirv-cross',
'desc': 'SPIRV-Cross SPIR-V shader converter',
'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 12:18:06 +02:00
}, {
'name': '--d3d11',
'desc': 'Direct3D 11 video output',
'deps': 'win32-desktop && shaderc && spirv-cross',
'func': check_cc(header_name=['d3d11_1.h', 'dxgi1_6.h']),
} , {
'name': '--ios-gl',
vo_opengl: add our own copy of OpenGL headers gl_headers.h is basically header_fixes.h done consequently. It contains all OpenGL defines (and some typedefs) we need. We don't include GL headers provided by the system anymore. Some care has to be taken by certain windowing APIs including all of gl.h anyway. Then the definitions could clash. Fortunately, redefining preprocessor symbols to the same content is allowed and ignored. Also, redefining typedefs to the same thing is allowed in C11. Apparently the latter is not allowed in C99, so there is an imperfect attempt to avoid the typedefs if required API symbols are apparently present already. The nost risky part about this are the standard typedefs and GLAPIENTRY. The latter is different only on win32 (and at least consistently so). The typedefs are mostly based on stdint.h typedefs, which khrplatform.h clumsily emulates on platforms which don't have it. The biggest difference is that we define GLsizeiptr directly to ptrdiff_t, instead of checking for the _WIN64 symbol and defining it to long or long long. This also typedefs GLsync to __GLsync, just like the khronos headers. Although symbols prefixed with __ are implementation reserved, khronos also violates this rule, and having the same definition as khronos will avoid problems on duplicate definitions. We can simplify the build scripts too. The ios-gl check seems a bit wrong now (what we really want to test for is EAGLContext), but I can't test and thus can't improve it. cuda_dynamic.h redefined two GL symbols; just include the new headers directly instead.
2017-04-07 14:30:51 +02:00
'desc': 'iOS OpenGL ES hardware decoding interop support',
'func': check_statement('OpenGLES/ES3/glext.h', '(void)GL_RGB32F'), # arbitrary OpenGL ES 3.0 symbol
} , {
'name': '--plain-gl',
'desc': 'OpenGL without platform-specific code (e.g. for libmpv)',
'deps': 'libmpv-shared || libmpv-static',
'func': check_true,
}, {
RPI support This requires FFmpeg git master for accelerated hardware decoding. Keep in mind that FFmpeg must be compiled with --enable-mmal. Libav will also work. Most things work. Screenshots don't work with accelerated/opaque decoding (except using full window screenshot mode). Subtitles are very slow - even simple but huge overlays can cause frame drops. This always uses fullscreen mode. It uses dispmanx and mmal directly, and there are no window managers or anything on this level. vo_opengl also kind of works, but is pretty useless and slow. It can't use opaque hardware decoding (copy back can be used by forcing the option --vd=lavc:h264_mmal). Keep in mind that the dispmanx backend is preferred over the X11 ones in case you're trying on X11; but X11 is even more useless on RPI. This doesn't correctly reject extended h264 profiles and thus doesn't fallback to software decoding. The hw supports only up to the high profile, and will e.g. return garbage for Hi10P video. This sets a precedent of enabling hw decoding by default, but only if RPI support is compiled (which most hopefully it will be disabled on desktop Linux platforms). While it's more or less required to use hw decoding on the weak RPI, it causes more problems than it solves on real platforms (Linux has the Intel GPU problem, OSX still has some cases with broken decoding.) So I can live with this compromise of having different defaults depending on the platform. Raspberry Pi 2 is required. This wasn't tested on the original RPI, though at least decoding itself seems to work (but full playback was not tested).
2015-03-29 15:12:11 +02: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 08:04:55 +02:00
'desc': 'OpenGL context support',
'deps': 'gl-cocoa || gl-x11 || egl-x11 || egl-drm || '
+ 'gl-win32 || gl-wayland || rpi || '
+ 'plain-gl',
'func': check_true,
'req': True,
'fmsg': "No OpenGL video output found or enabled. " +
"Aborting. If you really mean to compile without OpenGL " +
"video outputs use --disable-gl.",
}, {
'name': '--libplacebo',
'desc': 'libplacebo support',
'func': check_pkg_config('libplacebo >= 4.157.0'),
}, {
'name': '--libplacebo-next',
'desc': 'libplacebo v5.264.0+, needed for vo_gpu_next',
'deps': 'libplacebo',
'func': check_preprocessor('libplacebo/config.h', 'PL_API_VER >= 264',
use='libplacebo'),
hwdec_vulkan: add Vulkan HW Interop Vulkan Video Decoding has finally become a reality, as it's now showing up in shipping drivers, and the ffmpeg support has been merged. With that in mind, this change introduces HW interop support for ffmpeg Vulkan frames. The implementation is functionally complete - it can display frames produced by hardware decoding, and it can work with ffmpeg vulkan filters. There are still various caveats due to gaps and bugs in drivers, so YMMV, as always. Primary testing has been done on Intel, AMD, and nvidia hardware on Linux with basic Windows testing on nvidia. Notable caveats: * Due to driver bugs, video decoding on nvidia does not work right now, unless you use the Vulkan Beta driver. It can be worked around, but requires ffmpeg changes that are not considered acceptable to merge. * Even if those work-arounds are applied, Vulkan filters will not work on video that was decoded by Vulkan, due to additional bugs in the nvidia drivers. The filters do work correctly on content decoded some other way, and then uploaded to Vulkan (eg: Decode with nvdec, upload with --vf=format=vulkan) * Vulkan filters can only be used with drivers that support VK_EXT_descriptor_buffer which doesn't include Intel ANV as yet. There is an MR outstanding for this. * When dealing with 1080p content, there may be some visual distortion in the bottom lines of frames due to chroma scaling incorporating the extra hidden lines at the bottom of the frame (1080p content is actually stored as 1088 lines), depending on the hardware/driver combination and the scaling algorithm. This cannot be easily addressed as the mechanical fix for it violates the Vulkan spec, and probably requires a spec change to resolve properly. All of these caveats will be fixed in either drivers or ffmpeg, and so will not require mpv changes (unless something unexpected happens) If you want to run on nvidia with the non-beta drivers, you can this ffmpeg tree with the work-around patches: * https://github.com/philipl/FFmpeg/tree/vulkan-nvidia-workarounds
2022-03-12 20:21:29 +01:00
}, {
'name': 'libplacebo-decode',
'desc': 'libplacebo v6.278.0+, needed for Vulkan video decode',
hwdec_vulkan: add Vulkan HW Interop Vulkan Video Decoding has finally become a reality, as it's now showing up in shipping drivers, and the ffmpeg support has been merged. With that in mind, this change introduces HW interop support for ffmpeg Vulkan frames. The implementation is functionally complete - it can display frames produced by hardware decoding, and it can work with ffmpeg vulkan filters. There are still various caveats due to gaps and bugs in drivers, so YMMV, as always. Primary testing has been done on Intel, AMD, and nvidia hardware on Linux with basic Windows testing on nvidia. Notable caveats: * Due to driver bugs, video decoding on nvidia does not work right now, unless you use the Vulkan Beta driver. It can be worked around, but requires ffmpeg changes that are not considered acceptable to merge. * Even if those work-arounds are applied, Vulkan filters will not work on video that was decoded by Vulkan, due to additional bugs in the nvidia drivers. The filters do work correctly on content decoded some other way, and then uploaded to Vulkan (eg: Decode with nvdec, upload with --vf=format=vulkan) * Vulkan filters can only be used with drivers that support VK_EXT_descriptor_buffer which doesn't include Intel ANV as yet. There is an MR outstanding for this. * When dealing with 1080p content, there may be some visual distortion in the bottom lines of frames due to chroma scaling incorporating the extra hidden lines at the bottom of the frame (1080p content is actually stored as 1088 lines), depending on the hardware/driver combination and the scaling algorithm. This cannot be easily addressed as the mechanical fix for it violates the Vulkan spec, and probably requires a spec change to resolve properly. All of these caveats will be fixed in either drivers or ffmpeg, and so will not require mpv changes (unless something unexpected happens) If you want to run on nvidia with the non-beta drivers, you can this ffmpeg tree with the work-around patches: * https://github.com/philipl/FFmpeg/tree/vulkan-nvidia-workarounds
2022-03-12 20:21:29 +01:00
'deps': 'libplacebo',
'func': check_preprocessor('libplacebo/config.h', 'PL_API_VER >= 278',
hwdec_vulkan: add Vulkan HW Interop Vulkan Video Decoding has finally become a reality, as it's now showing up in shipping drivers, and the ffmpeg support has been merged. With that in mind, this change introduces HW interop support for ffmpeg Vulkan frames. The implementation is functionally complete - it can display frames produced by hardware decoding, and it can work with ffmpeg vulkan filters. There are still various caveats due to gaps and bugs in drivers, so YMMV, as always. Primary testing has been done on Intel, AMD, and nvidia hardware on Linux with basic Windows testing on nvidia. Notable caveats: * Due to driver bugs, video decoding on nvidia does not work right now, unless you use the Vulkan Beta driver. It can be worked around, but requires ffmpeg changes that are not considered acceptable to merge. * Even if those work-arounds are applied, Vulkan filters will not work on video that was decoded by Vulkan, due to additional bugs in the nvidia drivers. The filters do work correctly on content decoded some other way, and then uploaded to Vulkan (eg: Decode with nvdec, upload with --vf=format=vulkan) * Vulkan filters can only be used with drivers that support VK_EXT_descriptor_buffer which doesn't include Intel ANV as yet. There is an MR outstanding for this. * When dealing with 1080p content, there may be some visual distortion in the bottom lines of frames due to chroma scaling incorporating the extra hidden lines at the bottom of the frame (1080p content is actually stored as 1088 lines), depending on the hardware/driver combination and the scaling algorithm. This cannot be easily addressed as the mechanical fix for it violates the Vulkan spec, and probably requires a spec change to resolve properly. All of these caveats will be fixed in either drivers or ffmpeg, and so will not require mpv changes (unless something unexpected happens) If you want to run on nvidia with the non-beta drivers, you can this ffmpeg tree with the work-around patches: * https://github.com/philipl/FFmpeg/tree/vulkan-nvidia-workarounds
2022-03-12 20:21:29 +01:00
use='libplacebo'),
vo_gpu: vulkan: initial implementation This time based on ra/vo_gpu. 2017 is the year of the vulkan desktop! Current problems / limitations / improvement opportunities: 1. The swapchain/flipping code violates the vulkan spec, by assuming that the presentation queue will be bounded (in cases where rendering is significantly faster than vsync). But apparently, there's simply no better way to do this right now, to the point where even the stupid cube.c examples from LunarG etc. do it wrong. (cf. https://github.com/KhronosGroup/Vulkan-Docs/issues/370) 2. The memory allocator could be improved. (This is a universal constant) 3. Could explore using push descriptors instead of descriptor sets, especially since we expect to switch descriptors semi-often for some passes (like interpolation). Probably won't make a difference, but the synchronization overhead might be a factor. Who knows. 4. Parallelism across frames / async transfer is not well-defined, we either need to use a better semaphore / command buffer strategy or a resource pooling layer to safely handle cross-frame parallelism. (That said, I gave resource pooling a try and was not happy with the result at all - so I'm still exploring the semaphore strategy) 5. We aggressively use pipeline barriers where events would offer a much more fine-grained synchronization mechanism. As a result of this, we might be suffering from GPU bubbles due to too-short dependencies on objects. (That said, I'm also exploring the use of semaphores as a an ordering tactic which would allow cross-frame time slicing in theory) Some minor changes to the vo_gpu and infrastructure, but nothing consequential. NOTE: For safety, all use of asynchronous commands / multiple command pools is currently disabled completely. There are some left-over relics of this in the code (e.g. the distinction between dev_poll and pool_poll), but that is kept in place mostly because this will be re-extended in the future (vulkan rev 2). The queue count is also currently capped to 1, because of the lack of cross-frame semaphores means we need the implicit synchronization from the same-queue semantics to guarantee a correct result.
2016-09-14 20:54:18 +02:00
}, {
'name': '--vulkan',
'desc': 'Vulkan context support',
'deps': 'libplacebo',
'func': check_pkg_config('vulkan'),
}, {
'name': 'vk-khr-display',
'desc': "VK_KHR_display extension",
'deps': 'vulkan',
'func': check_statement('vulkan/vulkan_core.h', 'vkCreateDisplayPlaneSurfaceKHR(0, 0, 0, 0)',
use='vulkan')
}, {
'name': 'vulkan-decode-headers',
'desc': 'Vulkan headers with decode support',
'deps': 'vulkan',
'func': check_pkg_config('vulkan', '>= 1.3.238'),
hwdec_vulkan: add Vulkan HW Interop Vulkan Video Decoding has finally become a reality, as it's now showing up in shipping drivers, and the ffmpeg support has been merged. With that in mind, this change introduces HW interop support for ffmpeg Vulkan frames. The implementation is functionally complete - it can display frames produced by hardware decoding, and it can work with ffmpeg vulkan filters. There are still various caveats due to gaps and bugs in drivers, so YMMV, as always. Primary testing has been done on Intel, AMD, and nvidia hardware on Linux with basic Windows testing on nvidia. Notable caveats: * Due to driver bugs, video decoding on nvidia does not work right now, unless you use the Vulkan Beta driver. It can be worked around, but requires ffmpeg changes that are not considered acceptable to merge. * Even if those work-arounds are applied, Vulkan filters will not work on video that was decoded by Vulkan, due to additional bugs in the nvidia drivers. The filters do work correctly on content decoded some other way, and then uploaded to Vulkan (eg: Decode with nvdec, upload with --vf=format=vulkan) * Vulkan filters can only be used with drivers that support VK_EXT_descriptor_buffer which doesn't include Intel ANV as yet. There is an MR outstanding for this. * When dealing with 1080p content, there may be some visual distortion in the bottom lines of frames due to chroma scaling incorporating the extra hidden lines at the bottom of the frame (1080p content is actually stored as 1088 lines), depending on the hardware/driver combination and the scaling algorithm. This cannot be easily addressed as the mechanical fix for it violates the Vulkan spec, and probably requires a spec change to resolve properly. All of these caveats will be fixed in either drivers or ffmpeg, and so will not require mpv changes (unless something unexpected happens) If you want to run on nvidia with the non-beta drivers, you can this ffmpeg tree with the work-around patches: * https://github.com/philipl/FFmpeg/tree/vulkan-nvidia-workarounds
2022-03-12 20:21:29 +01:00
}, {
'name': '--vulkan-interop',
'desc': 'Vulkan graphics interop',
'deps': 'vulkan-decode-headers && libplacebo-decode',
hwdec_vulkan: add Vulkan HW Interop Vulkan Video Decoding has finally become a reality, as it's now showing up in shipping drivers, and the ffmpeg support has been merged. With that in mind, this change introduces HW interop support for ffmpeg Vulkan frames. The implementation is functionally complete - it can display frames produced by hardware decoding, and it can work with ffmpeg vulkan filters. There are still various caveats due to gaps and bugs in drivers, so YMMV, as always. Primary testing has been done on Intel, AMD, and nvidia hardware on Linux with basic Windows testing on nvidia. Notable caveats: * Due to driver bugs, video decoding on nvidia does not work right now, unless you use the Vulkan Beta driver. It can be worked around, but requires ffmpeg changes that are not considered acceptable to merge. * Even if those work-arounds are applied, Vulkan filters will not work on video that was decoded by Vulkan, due to additional bugs in the nvidia drivers. The filters do work correctly on content decoded some other way, and then uploaded to Vulkan (eg: Decode with nvdec, upload with --vf=format=vulkan) * Vulkan filters can only be used with drivers that support VK_EXT_descriptor_buffer which doesn't include Intel ANV as yet. There is an MR outstanding for this. * When dealing with 1080p content, there may be some visual distortion in the bottom lines of frames due to chroma scaling incorporating the extra hidden lines at the bottom of the frame (1080p content is actually stored as 1088 lines), depending on the hardware/driver combination and the scaling algorithm. This cannot be easily addressed as the mechanical fix for it violates the Vulkan spec, and probably requires a spec change to resolve properly. All of these caveats will be fixed in either drivers or ffmpeg, and so will not require mpv changes (unless something unexpected happens) If you want to run on nvidia with the non-beta drivers, you can this ffmpeg tree with the work-around patches: * https://github.com/philipl/FFmpeg/tree/vulkan-nvidia-workarounds
2022-03-12 20:21:29 +01:00
'func': check_pkg_config('libavutil', '>= 58.11.100'),
}, {
'name': 'vaapi-libplacebo',
'desc': 'VAAPI libplacebo',
'deps': 'vaapi && libplacebo',
'func': check_true,
}, {
'name': 'egl-helpers',
'desc': 'EGL helper functions',
'deps': 'egl || rpi || egl-angle-win32 || egl-android',
RPI support This requires FFmpeg git master for accelerated hardware decoding. Keep in mind that FFmpeg must be compiled with --enable-mmal. Libav will also work. Most things work. Screenshots don't work with accelerated/opaque decoding (except using full window screenshot mode). Subtitles are very slow - even simple but huge overlays can cause frame drops. This always uses fullscreen mode. It uses dispmanx and mmal directly, and there are no window managers or anything on this level. vo_opengl also kind of works, but is pretty useless and slow. It can't use opaque hardware decoding (copy back can be used by forcing the option --vd=lavc:h264_mmal). Keep in mind that the dispmanx backend is preferred over the X11 ones in case you're trying on X11; but X11 is even more useless on RPI. This doesn't correctly reject extended h264 profiles and thus doesn't fallback to software decoding. The hw supports only up to the high profile, and will e.g. return garbage for Hi10P video. This sets a precedent of enabling hw decoding by default, but only if RPI support is compiled (which most hopefully it will be disabled on desktop Linux platforms). While it's more or less required to use hw decoding on the weak RPI, it causes more problems than it solves on real platforms (Linux has the Intel GPU problem, OSX still has some cases with broken decoding.) So I can live with this compromise of having different defaults depending on the platform. Raspberry Pi 2 is required. This wasn't tested on the original RPI, though at least decoding itself seems to work (but full playback was not tested).
2015-03-29 15:12:11 +02:00
'func': check_true
}, {
'name': '--sixel',
'desc': 'Sixel',
'func': check_pkg_config('libsixel', '>= 1.5'),
}, {
'name': 'dmabuf-interop-gl',
'desc': 'dmabuf GL Interop',
'deps': 'egl && drm',
'func': check_true,
}, {
'name': 'dmabuf-interop-pl',
'desc': 'dmabuf libplacebo interop',
'deps': 'vaapi-libplacebo',
'func': check_true,
}, {
# This can be removed roughly when Debian 12 is released.
'name': 'drm-is-kms',
'desc': 'drmIsKMS() function',
'deps': 'drm',
'func': check_pkg_config('libdrm', '>= 2.4.105'),
}, {
'name': 'posix-shm',
'desc': "POSIX shared memory API",
'deps': 'posix',
'func': check_statement('sys/mman.h', 'shm_open("",0,0)')
}
]
hwaccel_features = [
{
'name': 'videotoolbox-hwaccel',
'desc': 'libavcodec videotoolbox hwaccel',
'deps': 'gl-cocoa || ios-gl',
'func': check_true,
}, {
'name': '--videotoolbox-gl',
'desc': 'Videotoolbox with OpenGL',
'deps': 'gl-cocoa && videotoolbox-hwaccel',
'func': check_true
}, {
'name': '--d3d-hwaccel',
'desc': 'D3D11VA hwaccel',
'deps': 'os-win32',
'func': check_true,
}, {
'name': '--d3d9-hwaccel',
'desc': 'DXVA2 hwaccel',
'deps': 'd3d-hwaccel',
'func': check_true,
}, {
'name': '--gl-dxinterop-d3d9',
'desc': 'OpenGL/DirectX Interop Backend DXVA2 interop',
'deps': 'gl-dxinterop && d3d9-hwaccel',
'groups': [ 'gl' ],
'func': check_true,
}, {
'name': 'ffnvcodec',
'desc': 'CUDA Headers and dynamic loader',
'func': check_pkg_config('ffnvcodec >= 11.1.5.1'),
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-05 00:23:55 +02:00
}, {
'name': '--cuda-hwaccel',
'desc': 'CUDA acceleration',
'deps': 'ffnvcodec',
'func': check_true,
}, {
'name': '--cuda-interop',
'desc': 'CUDA with graphics interop',
'deps': '(gl || vulkan) && cuda-hwaccel',
'func': check_true,
2019-07-14 15:56:10 +02:00
}, {
'name': '--rpi-mmal',
'desc': 'Raspberry Pi MMAL hwaccel',
'deps': 'rpi',
'func': any_check(check_pkg_config('mmal'),
check_pkg_config('/opt/vc/lib/pkgconfig/mmal.pc')),
}
]
standalone_features = [
{
'name': 'win32-executable',
'desc': 'w32 executable',
'deps': 'os-win32 || !(!(os-cygwin))',
'func': check_ctx_vars('WINDRES')
2017-02-25 21:56:59 +01:00
}, {
'name': '--macos-touchbar',
'desc': 'macOS Touch Bar support',
'deps': 'cocoa',
2017-02-25 21:56:59 +01:00
'func': check_cc(
fragment=load_fragment('touchbar.m'),
framework_name=['AppKit'],
compile_filename='test-touchbar.m',
linkflags='-fobjc-arc')
}, {
'name': '--macos-10-11-features',
'desc': 'macOS 10.11 SDK Features',
'deps': 'cocoa',
'func': check_macos_sdk('10.11')
}, {
'name': '--macos-10-12-2-features',
'desc': 'macOS 10.12.2 SDK Features',
'deps': 'cocoa',
'func': check_macos_sdk('10.12.2')
}, {
'name': '--macos-10-14-features',
'desc': 'macOS 10.14 SDK Features',
'deps': 'cocoa',
'func': check_macos_sdk('10.14')
},{
'name': '--macos-media-player',
'desc': 'macOS Media Player support',
'deps': 'macos-10-12-2-features && swift',
'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 12:28:19 +01:00
'name': '--macos-cocoa-cb',
'desc': 'macOS libmpv backend',
'deps': 'cocoa && swift',
'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 12:28:19 +01:00
}
]
_INSTALL_DIRS_LIST = [
('confdir', '${SYSCONFDIR}/mpv', 'configuration files'),
('zshdir', '${DATADIR}/zsh/site-functions', 'zsh completion functions'),
('confloaddir', '${CONFDIR}', 'configuration files load directory'),
('bashdir', '${DATADIR}/bash-completion/completions', 'bash completion functions'),
]
def options(opt):
opt.load('compiler_c')
opt.load('waf_customizations')
opt.load('features')
opt.load('gnu_dirs')
#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")
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')
group = opt.get_option_group("Installation directories")
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}]' \
.format(desc, default.replace('${','').replace('}','')))
group = opt.get_option_group("build and install options")
group.add_option('--variant',
default = '',
help = 'variant name for saving configuration and build results')
opt.parse_features('build and install options', build_options)
optional_features = main_dependencies + libav_dependencies
2014-11-28 15:40:55 +01:00
opt.parse_features('optional features', optional_features)
opt.parse_features('audio outputs', audio_output_features)
opt.parse_features('video outputs', video_output_features)
opt.parse_features('hwaccels', hwaccel_features)
opt.parse_features('standalone app', standalone_features)
2014-11-28 15:40:55 +01:00
group = opt.get_option_group("optional features")
group.add_option('--lua',
type = 'string',
dest = 'LUA_VER',
build: lua 5.1/5.2: use generic version names TL;DR: use --lua=XXX for pkg-config name XXX, e.g. --lua=lua-5.1 . For unversioned 'lua.pc', use the name luadef51/luadef52 . Autodetection remains the same (5.2 names, luajit, 5.1 names). The old names are still supported, but not auto-detected. Before this patch, if one wanted to choose a specific lua version when more than one is installed, then the names were a mess, e.g. 51obsd is also the name detected on Arch linux, and other (distro) names are also not unique to a specific distro/platform. So to ask mpv to choose the package name (specifically, the pkg-config file name), one needs to look at the mpv sources and find the (arbitrary) distro name which has the same lua version naming as they do on their own system, e.g. --lua=51obsd on Arch. This is a pain. Now we add generic names: - luadef51/luadef52 - generic pkg-config lua.pc (version is inside). - lua* - exactly the pkg-config name, e.g. --lua=lua-51 for lua-51.pc (the names are curated, e.g. --lua=foo won't detect foo.pc). - The legacy names (e.g. 51deb) are still supported, but undocumented, and the new generic names take precedence during auto-detection. The fact that the generic names all start with "lua" has an additional benefit that it shows right after "lua" at the output of mpv -v, while the old names start with numbers, so they're first at the list, making it hard to understand that e.g. "51obsd" is the lua version. None of these names are actually used at the mpv code. The C code checks the version using the lua headers (LUA_VERSION_NUM).
2021-09-25 16:51:19 +02:00
help = "select Lua package to autodetect. Choices (x is 1 or 2): luadef5x, lua5x, lua5.x, lua-5.x, luajit (luadef5x is for pkg-config name 'lua', the rest are exact pkg-config names)")
cocoa-cb: initial implementation via opengl-cb API this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739, #2392, #2217
2018-02-12 12:28:19 +01:00
group.add_option('--swift-flags',
type = 'string',
dest = 'SWIFT_FLAGS',
help = "Optional Swift compiler flags")
@conf
def is_optimization(ctx):
return getattr(ctx.options, 'enable_optimize')
@conf
def is_debug_build(ctx):
return getattr(ctx.options, 'enable_debug-build')
def configure(ctx):
from waflib import Options
ctx.resetenv(ctx.options.variant)
2014-12-04 21:55:00 +01:00
ctx.check_waf_version(mini='1.8.4')
target = os.environ.get('TARGET')
(cc, pkg_config, ar, windres) = ('cc', 'pkg-config', 'ar', 'windres')
if target:
cc = '-'.join([target, 'gcc'])
pkg_config = '-'.join([target, pkg_config])
ar = '-'.join([target, ar])
windres = '-'.join([target, windres])
ctx.find_program(cc, var='CC')
ctx.find_program(pkg_config, var='PKG_CONFIG')
ctx.find_program(ar, var='AR')
2015-12-29 20:57:09 +01:00
ctx.find_program('rst2html', var='RST2HTML', mandatory=False)
ctx.find_program('rst2man', var='RST2MAN', mandatory=False)
ctx.find_program('rst2pdf', var='RST2PDF', mandatory=False)
ctx.find_program(windres, var='WINDRES', mandatory=False)
ctx.find_program('perl', var='BIN_PERL', mandatory=False)
ctx.add_os_flags('LIBRARY_PATH')
ctx.load('compiler_c python')
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 12:28:19 +01:00
ctx.load('detections.compiler_swift')
ctx.load('detections.compiler')
ctx.load('detections.devices')
ctx.load('gnu_dirs')
# 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)
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)
if ctx.options.LUA_VER:
ctx.options.enable_lua = True
ctx.parse_dependencies(build_options)
ctx.parse_dependencies(main_dependencies)
ctx.parse_dependencies(libav_dependencies)
ctx.parse_dependencies(audio_output_features)
ctx.parse_dependencies(video_output_features)
ctx.parse_dependencies(hwaccel_features)
ctx.define('PLATFORM', check_platform(ctx))
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 12:28:19 +01:00
if ctx.options.SWIFT_FLAGS:
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 12:28:19 +01:00
ctx.parse_dependencies(standalone_features)
ctx.load('generators.headers')
if not ctx.dependency_satisfied('build-date'):
ctx.env.CFLAGS += ['-DNO_BUILD_TIMESTAMPS']
if ctx.dependency_satisfied('clang-database'):
ctx.load('clang_compilation_database')
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.
ctx.env.LINKFLAGS += ['-rdynamic']
ctx.store_dependencies_lists()
from waflib import Logs
Logs.error("WARNING: Building mpv with waf is deprecated and will be removed the future! It is recommended to switch to meson as soon as possible.")
def __write_version__(ctx):
ctx(
source = 'version.py',
target = 'generated/version.h',
rule = '${PYTHON} ${SRC} ${TGT}',
always = True)
def build(ctx):
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))
ctx.unpack_dependencies_lists()
ctx.add_group('versionh')
ctx.add_group('sources')
ctx.set_group('versionh')
__write_version__(ctx)
ctx.set_group('sources')
ctx.load('wscript_build')
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)