mpv/wscript_build.py

776 lines
31 KiB
Python
Raw Normal View History

import re
2014-11-19 17:51:53 +00:00
import os
def _add_rst_manual_dependencies(ctx):
manpage_sources_basenames = """
options.rst ao.rst vo.rst af.rst vf.rst encode.rst
input.rst osc.rst stats.rst lua.rst ipc.rst changes.rst""".split()
manpage_sources = ['DOCS/man/'+x for x in manpage_sources_basenames]
for manpage_source in manpage_sources:
ctx.add_manual_dependency(
ctx.path.find_node('DOCS/man/mpv.rst'),
ctx.path.find_node(manpage_source))
2015-12-29 19:57:09 +00:00
def _build_html(ctx):
ctx(
name = 'rst2html',
target = 'DOCS/man/mpv.html',
source = 'DOCS/man/mpv.rst',
rule = '${RST2HTML} ${SRC} ${TGT}',
install_path = ctx.env.HTMLDIR)
2015-12-29 19:57:09 +00:00
_add_rst_manual_dependencies(ctx)
def _build_man(ctx):
ctx(
name = 'rst2man',
target = 'DOCS/man/mpv.1',
source = 'DOCS/man/mpv.rst',
rule = '${RST2MAN} --strip-elements-with-class=contents ${SRC} ${TGT}',
install_path = ctx.env.MANDIR + '/man1')
_add_rst_manual_dependencies(ctx)
def _build_pdf(ctx):
ctx(
name = 'rst2pdf',
target = 'DOCS/man/mpv.pdf',
source = 'DOCS/man/mpv.rst',
rule = '${RST2PDF} -c -b 1 --repeat-table-rows ${SRC} -o ${TGT}',
install_path = ctx.env.DOCDIR)
_add_rst_manual_dependencies(ctx)
def _all_includes(ctx):
return [ctx.bldnode.abspath(), ctx.srcnode.abspath()] + \
ctx.dependencies_includes()
def build(ctx):
ctx.load('waf_customizations')
ctx.load('generators.sources')
ctx(
features = "file2string",
source = "TOOLS/osxbundle/mpv.app/Contents/Resources/icon.icns",
target = "generated/TOOLS/osxbundle/mpv.app/Contents/Resources/icon.icns.inc",
)
icons = [16, 32, 64, 128]
for size in icons:
name = "etc/mpv-icon-8bit-%dx%d.png" % (size, size)
ctx(
features = "file2string",
source = name,
target = "generated/%s.inc" % name,
)
2017-07-02 03:04:20 +00:00
ctx(
features = "file2string",
source = "etc/input.conf",
target = "generated/etc/input.conf.inc",
)
ctx(
features = "file2string",
source = "etc/builtin.conf",
target = "generated/etc/builtin.conf.inc",
)
ctx(
features = "file2string",
source = "sub/osd_font.otf",
target = "generated/sub/osd_font.otf.inc",
)
2014-11-19 17:51:53 +00:00
lua_files = ["defaults.lua", "assdraw.lua", "options.lua", "osc.lua",
"ytdl_hook.lua", "stats.lua", "console.lua",
"auto_profiles.lua"]
2014-11-19 17:51:53 +00:00
for fn in lua_files:
fn = "player/lua/" + fn
ctx(
features = "file2string",
source = fn,
target = "generated/%s.inc" % fn,
)
ctx(
features = "file2string",
source = "player/javascript/defaults.js",
target = "generated/player/javascript/defaults.js.inc",
)
if ctx.dependency_satisfied('wayland'):
ctx.wayland_protocol_code(proto_dir = ctx.env.WL_PROTO_DIR,
protocol = "stable/xdg-shell/xdg-shell",
target = "generated/wayland/xdg-shell.c")
ctx.wayland_protocol_header(proto_dir = ctx.env.WL_PROTO_DIR,
protocol = "stable/xdg-shell/xdg-shell",
target = "generated/wayland/xdg-shell.h")
ctx.wayland_protocol_code(proto_dir = ctx.env.WL_PROTO_DIR,
protocol = "unstable/idle-inhibit/idle-inhibit-unstable-v1",
target = "generated/wayland/idle-inhibit-unstable-v1.c")
ctx.wayland_protocol_header(proto_dir = ctx.env.WL_PROTO_DIR,
protocol = "unstable/idle-inhibit/idle-inhibit-unstable-v1",
target = "generated/wayland/idle-inhibit-unstable-v1.h")
ctx.wayland_protocol_code(proto_dir = ctx.env.WL_PROTO_DIR,
protocol = "stable/presentation-time/presentation-time",
target = "generated/wayland/presentation-time.c")
ctx.wayland_protocol_header(proto_dir = ctx.env.WL_PROTO_DIR,
protocol = "stable/presentation-time/presentation-time",
target = "generated/wayland/presentation-time.h")
ctx.wayland_protocol_code(proto_dir = ctx.env.WL_PROTO_DIR,
protocol = "unstable/xdg-decoration/xdg-decoration-unstable-v1",
target = "generated/wayland/xdg-decoration-unstable-v1.c")
ctx.wayland_protocol_header(proto_dir = ctx.env.WL_PROTO_DIR,
protocol = "unstable/xdg-decoration/xdg-decoration-unstable-v1",
target = "generated/wayland/xdg-decoration-unstable-v1.h")
ctx.wayland_protocol_code(proto_dir = ctx.env.WL_PROTO_DIR,
protocol = "unstable/linux-dmabuf/linux-dmabuf-unstable-v1",
target = "generated/wayland/linux-dmabuf-unstable-v1.c")
ctx.wayland_protocol_header(proto_dir = ctx.env.WL_PROTO_DIR,
protocol = "unstable/linux-dmabuf/linux-dmabuf-unstable-v1",
target = "generated/wayland/linux-dmabuf-unstable-v1.h")
ctx.wayland_protocol_code(proto_dir = ctx.env.WL_PROTO_DIR,
protocol = "stable/viewporter/viewporter",
target = "generated/wayland/viewporter.c")
ctx.wayland_protocol_header(proto_dir = ctx.env.WL_PROTO_DIR,
protocol = "stable/viewporter/viewporter",
target = "generated/wayland/viewporter.h")
ctx(features = "ebml_header", target = "generated/ebml_types.h")
ctx(features = "ebml_definitions", target = "generated/ebml_defs.inc")
cocoa-cb: initial implementation via opengl-cb API this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739, #2392, #2217
2018-02-12 11:28:19 +00:00
def swift(task):
src = [x.abspath() for x in task.inputs]
bridge = ctx.path.find_node("osdep/macOS_swift_bridge.h").abspath()
cocoa-cb: initial implementation via opengl-cb API this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739, #2392, #2217
2018-02-12 11:28:19 +00:00
tgt = task.outputs[0].abspath()
header = task.outputs[1].abspath()
module = task.outputs[2].abspath()
module_name = os.path.basename(module).rsplit(".", 1)[0]
cocoa-cb: initial implementation via opengl-cb API this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739, #2392, #2217
2018-02-12 11:28:19 +00:00
cmd = [ ctx.env.SWIFT ]
cmd.extend(ctx.env.SWIFT_FLAGS)
cmd.extend([
"-module-name", module_name,
"-emit-module-path", module,
"-import-objc-header", bridge,
"-emit-objc-header-path", header,
"-o", tgt,
])
cmd.extend(src)
cmd.extend([ "-I.", "-I%s" % ctx.srcnode.abspath() ])
cocoa-cb: initial implementation via opengl-cb API this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739, #2392, #2217
2018-02-12 11:28:19 +00:00
return task.exec_command(cmd)
if ctx.dependency_satisfied('cocoa') and ctx.dependency_satisfied('swift'):
cocoa-cb: initial implementation via opengl-cb API this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739, #2392, #2217
2018-02-12 11:28:19 +00:00
swift_source = [
( "osdep/macos/log_helper.swift" ),
( "osdep/macos/libmpv_helper.swift" ),
( "osdep/macos/mpv_helper.swift" ),
( "osdep/macos/swift_extensions.swift" ),
( "osdep/macos/swift_compat.swift" ),
( "osdep/macos/remote_command_center.swift", "macos-media-player" ),
( "video/out/mac/common.swift" ),
( "video/out/mac/view.swift" ),
( "video/out/mac/window.swift" ),
( "video/out/mac/title_bar.swift" ),
( "video/out/cocoa_cb_common.swift", "macos-cocoa-cb" ),
( "video/out/mac/gl_layer.swift", "macos-cocoa-cb" ),
cocoa-cb: initial implementation via opengl-cb API this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739, #2392, #2217
2018-02-12 11:28:19 +00:00
]
ctx(
rule = swift,
source = ctx.filtered_sources(swift_source),
target = [ "osdep/macOS_swift.o",
"osdep/macOS_swift.h",
"osdep/macOS_swift.swiftmodule" ],
cocoa-cb: initial implementation via opengl-cb API this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739, #2392, #2217
2018-02-12 11:28:19 +00:00
before = 'c',
)
ctx.env.append_value('LINKFLAGS', [
'-Xlinker', '-add_ast_path',
'-Xlinker', ctx.path.find_or_declare("osdep/macOS_swift.swiftmodule").abspath()
cocoa-cb: initial implementation via opengl-cb API this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739, #2392, #2217
2018-02-12 11:28:19 +00:00
])
if ctx.dependency_satisfied('cplayer'):
main_fn_c = ctx.pick_first_matching_dep([
( "osdep/main-fn-cocoa.c", "cocoa" ),
( "osdep/main-fn-unix.c", "posix" ),
( "osdep/main-fn-win.c", "win32-desktop" ),
])
getch2_c = ctx.pick_first_matching_dep([
( "osdep/terminal-unix.c", "posix" ),
( "osdep/terminal-win.c", "win32-desktop" ),
( "osdep/terminal-dummy.c" ),
])
timer_c = ctx.pick_first_matching_dep([
( "osdep/timer-win2.c", "os-win32" ),
( "osdep/timer-darwin.c", "os-darwin" ),
( "osdep/timer-linux.c", "posix" ),
])
ipc_c = ctx.pick_first_matching_dep([
( "input/ipc-unix.c", "posix" ),
( "input/ipc-win.c", "win32-desktop" ),
( "input/ipc-dummy.c" ),
])
subprocess_c = ctx.pick_first_matching_dep([
( "osdep/subprocess-posix.c", "posix" ),
( "osdep/subprocess-win.c", "win32-desktop" ),
( "osdep/subprocess-dummy.c" ),
])
sources = [
## Audio
( "audio/aframe.c" ),
( "audio/chmap.c" ),
( "audio/chmap_avchannel.c", "av-channel-layout" ),
( "audio/chmap_sel.c" ),
( "audio/decode/ad_lavc.c" ),
( "audio/decode/ad_spdif.c" ),
( "audio/filter/af_drop.c" ),
( "audio/filter/af_format.c" ),
( "audio/filter/af_lavcac3enc.c" ),
( "audio/filter/af_rubberband.c", "rubberband" ),
( "audio/filter/af_scaletempo.c" ),
( "audio/filter/af_scaletempo2.c" ),
( "audio/filter/af_scaletempo2_internals.c" ),
( "audio/fmt-conversion.c" ),
( "audio/format.c" ),
( "audio/out/ao.c" ),
( "audio/out/ao_alsa.c", "alsa" ),
2018-03-10 03:28:09 +00:00
( "audio/out/ao_audiotrack.c", "android" ),
( "audio/out/ao_audiounit.m", "audiounit" ),
( "audio/out/ao_coreaudio.c", "coreaudio" ),
( "audio/out/ao_coreaudio_chmap.c", "coreaudio || audiounit" ),
( "audio/out/ao_coreaudio_exclusive.c", "coreaudio" ),
( "audio/out/ao_coreaudio_properties.c", "coreaudio" ),
( "audio/out/ao_coreaudio_utils.c", "coreaudio || audiounit" ),
( "audio/out/ao_jack.c", "jack" ),
( "audio/out/ao_lavc.c" ),
( "audio/out/ao_null.c" ),
( "audio/out/ao_openal.c", "openal" ),
( "audio/out/ao_opensles.c", "opensles" ),
( "audio/out/ao_oss.c", "oss-audio" ),
( "audio/out/ao_pcm.c" ),
( "audio/out/ao_pipewire.c", "pipewire" ),
( "audio/out/ao_pulse.c", "pulse" ),
( "audio/out/ao_sdl.c", "sdl2-audio" ),
( "audio/out/ao_sndio.c", "sndio" ),
( "audio/out/ao_wasapi.c", "wasapi" ),
( "audio/out/ao_wasapi_changenotify.c", "wasapi" ),
( "audio/out/ao_wasapi_utils.c", "wasapi" ),
audio: merge pull/push ring buffer glue code This is preparation to further cleanups (and eventually actual improvements) of the audio output code. AOs are split into two classes: pull and push. Pull AOs let an audio callback of the native audio API read from a ring buffer. Push AOs expose a function that works similar to write(), and for which we start a "feeder" thread. It seems making this split was beneficial, because of the different data flow, and emulating the one or other in the AOs directly would have created code duplication (all the "pull" AOs had their own ring buffer implementation before it was cleaned up). Unfortunately, both types had completely separate implementations (in pull.c and push.c). The idea was that little can be shared anyway. But that's very annoying now, because I want to change the API between AO and player. This commit attempts to merge them. I've moved everything from push.c to pull.c, the trivial entrypoints from ao.c to pull.c, and attempted to reconcile the differences. It's a mess, but at least there's only one ring buffer within the AO code now. Everything should work mostly the same. Pull AOs now always copy the audio data under a lock; before this commit, all ring buffer access was lock-free (except for the decoder wakeup callback, which acquired a mutex). In theory, this is "bad", and people obsessed with lock-free stuff will hate me, but in practice probably won't matter. The planned change will probably remove this copying-under-lock again, but who knows when this will happen. One change for the push AOs now makes it drop audio, where before only a warning was logged. This is only in case of AOs or drivers which exhibit unexpected (and now unsupported) behavior. This is a risky change. Although it's completely trivial conceptually, there are too many special cases. In addition, I barely tested it, and I've messed with it in a half-motivated state over a longer time, barely making any progress, and finishing it under a rush when I already should have been asleep. Most things seem to work, and I made superficial tests with alsa, sdl, and encode mode. This should cover most things, but there are a lot of tricky things that received no coverage. All this text means you should be prepared to roll back to an older commit and report your problem.
2020-05-24 23:53:41 +00:00
( "audio/out/buffer.c" ),
## Core
( "common/av_common.c" ),
( "common/av_log.c" ),
( "common/codecs.c" ),
( "common/common.c" ),
( "common/encode_lavc.c" ),
( "common/msg.c" ),
( "common/playlist.c" ),
( "common/recorder.c" ),
( "common/stats.c" ),
( "common/tags.c" ),
( "common/version.c" ),
## Demuxers
( "demux/codec_tags.c" ),
( "demux/cue.c" ),
demux: add a on-disk cache Somewhat similar to the old --cache-file, except for the demuxer cache. Instead of keeping packet data in memory, it's written to disk and read back when needed. The idea is to reduce main memory usage, while allowing fast seeking in large cached network streams (especially live streams). Keeping the packet metadata on disk would be rather hard (would use mmap or so, or rewrite the entire demux.c packet queue handling), and since it's relatively small, just keep it in memory. Also for simplicity, the disk cache is append-only. If you're watching really long livestreams, and need pruning, you're probably out of luck. This still could be improved by trying to free unused blocks with fallocate(), but since we're writing multiple streams in an interleaved manner, this is slightly hard. Some rather gross ugliness in packet.h: we want to store the file position of the cached data somewhere, but on 32 bit architectures, we don't have any usable 64 bit members for this, just the buf/len fields, which add up to 64 bit - so the shitty union aliases this memory. Error paths untested. Side data (the complicated part of trying to serialize ffmpeg packets) untested. Stream recording had to be adjusted. Some minor details change due to this, but probably nothing important. The change in attempt_range_joining() is because packets in cache have no valid len field. It was a useful check (heuristically finding broken cases), but not a necessary one. Various other approaches were tried. It would be interesting to list them and to mention the pros and cons, but I don't feel like it.
2019-06-13 17:10:32 +00:00
( "demux/cache.c" ),
( "demux/demux.c" ),
( "demux/demux_cue.c" ),
demux: restore some of the DVD/BD/CDDA interaction layers This partially reverts commit a9d83eac40c94f44d19fab7b6955331f10efe301 ("Remove optical disc fancification layers"). Mostly due to the timestamp crap, this was never really going to work. The playback layer is sensitive to timestamps, and derives the playback time directly from the low level packet timestamps. DVD/BD works differently, and libdvdnav/libbluray do not make it easy at all to compensate for this. Which is why it never worked well, but not doing it at all is even more awful. demux_disc.c tried this and rewrote packet timestamps from low level TS to playback time. So restore demux_disc.c, which should bring behavior back to the old often non-working but slightly better state. I did not revert anything that affects components above the demuxer layer. For example, the properties for switching DVD angles or listing disc titles are still gone. (Disc titles could be reimplemented as editions. But not by me.) This commit modifies the reverted code a bit; this can't be avoided, because the internal API changed quite a bit. The old seek resync in demux_lavf.c (which was a hack) is replaced with a hack. SEEK_FORCE and demux_params.external_stream are new additions. Some of this could/should be further cleaned up. If you don't want "proper" DVD/BD support to disappear, you should probably volunteer. Now why am I wasting my time for this? Just because some idiot users are too lazy to rip their ever-wearing out shitty physical discs? Then why should I not be lazy and drop support completely? They won't even be thankful for me maintaining this horrible garbage for no compensation.
2019-10-02 22:22:18 +00:00
( "demux/demux_disc.c" ),
( "demux/demux_edl.c" ),
( "demux/demux_lavf.c" ),
( "demux/demux_libarchive.c", "libarchive" ),
( "demux/demux_mf.c" ),
( "demux/demux_mkv.c" ),
( "demux/demux_mkv_timeline.c" ),
( "demux/demux_null.c" ),
( "demux/demux_playlist.c" ),
( "demux/demux_raw.c" ),
Rewrite ordered chapters and timeline stuff This uses a different method to piece segments together. The old approach basically changes to a new file (with a new start offset) any time a segment ends. This meant waiting for audio/video end on segment end, and then changing to the new segment all at once. It had a very weird impact on the playback core, and some things (like truly gapless segment transitions, or frame backstepping) just didn't work. The new approach adds the demux_timeline pseudo-demuxer, which presents an uniform packet stream from the many segments. This is pretty similar to how ordered chapters are implemented everywhere else. It also reminds of the FFmpeg concat pseudo-demuxer. The "pure" version of this approach doesn't work though. Segments can actually have different codec configurations (different extradata), and subtitles are most likely broken too. (Subtitles have multiple corner cases which break the pure stream-concatenation approach completely.) To counter this, we do two things: - Reinit the decoder with each segment. We go as far as allowing concatenating files with completely different codecs for the sake of EDL (which also uses the timeline infrastructure). A "lighter" approach would try to make use of decoder mechanism to update e.g. the extradata, but that seems fragile. - Clip decoded data to segment boundaries. This is equivalent to normal playback core mechanisms like hr-seek, but now the playback core doesn't need to care about these things. These two mechanisms are equivalent to what happened in the old implementation, except they don't happen in the playback core anymore. In other words, the playback core is completely relieved from timeline implementation details. (Which honestly is exactly what I'm trying to do here. I don't think ordered chapter behavior deserves improvement, even if it's bad - but I want to get it out from the playback core.) There is code duplication between audio and video decoder common code. This is awful and could be shareable - but this will happen later. Note that the audio path has some code to clip audio frames for the purpose of codec preroll/gapless handling, but it's not shared as sharing it would cause more pain than it would help.
2016-02-15 20:04:07 +00:00
( "demux/demux_timeline.c" ),
( "demux/ebml.c" ),
( "demux/packet.c" ),
( "demux/timeline.c" ),
( "filters/f_async_queue.c" ),
video: rewrite filtering glue code Get rid of the old vf.c code. Replace it with a generic filtering framework, which can potentially handle more than just --vf. At least reimplementing --af with this code is planned. This changes some --vf semantics (including runtime behavior and the "vf" command). The most important ones are listed in interface-changes. vf_convert.c is renamed to f_swscale.c. It is now an internal filter that can not be inserted by the user manually. f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is conceptually easy, but a big mess due to the data flow changes). The existing filters are all changed heavily. The data flow of the new filter framework is different. Especially EOF handling changes - EOF is now a "frame" rather than a state, and must be passed through exactly once. Another major thing is that all filters must support dynamic format changes. The filter reconfig() function goes away. (This sounds complex, but since all filters need to handle EOF draining anyway, they can use the same code, and it removes the mess with reconfig() having to predict the output format, which completely breaks with libavfilter anyway.) In addition, there is no automatic format negotiation or conversion. libavfilter's primitive and insufficient API simply doesn't allow us to do this in a reasonable way. Instead, filters can use f_autoconvert as sub-filter, and tell it which formats they support. This filter will in turn add actual conversion filters, such as f_swscale, to perform necessary format changes. vf_vapoursynth.c uses the same basic principle of operation as before, but with worryingly different details in data flow. Still appears to work. The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are heavily changed. Fortunately, they all used refqueue.c, which is for sharing the data flow logic (especially for managing future/past surfaces and such). It turns out it can be used to factor out most of the data flow. Some of these filters accepted software input. Instead of having ad-hoc upload code in each filter, surface upload is now delegated to f_autoconvert, which can use f_hwupload to perform this. Exporting VO capabilities is still a big mess (mp_stream_info stuff). The D3D11 code drops the redundant image formats, and all code uses the hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a big mess for now. f_async_queue is unused.
2018-01-16 10:53:44 +00:00
( "filters/f_autoconvert.c" ),
( "filters/f_auto_filters.c" ),
( "filters/f_decoder_wrapper.c" ),
( "filters/f_demux_in.c" ),
video: rewrite filtering glue code Get rid of the old vf.c code. Replace it with a generic filtering framework, which can potentially handle more than just --vf. At least reimplementing --af with this code is planned. This changes some --vf semantics (including runtime behavior and the "vf" command). The most important ones are listed in interface-changes. vf_convert.c is renamed to f_swscale.c. It is now an internal filter that can not be inserted by the user manually. f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is conceptually easy, but a big mess due to the data flow changes). The existing filters are all changed heavily. The data flow of the new filter framework is different. Especially EOF handling changes - EOF is now a "frame" rather than a state, and must be passed through exactly once. Another major thing is that all filters must support dynamic format changes. The filter reconfig() function goes away. (This sounds complex, but since all filters need to handle EOF draining anyway, they can use the same code, and it removes the mess with reconfig() having to predict the output format, which completely breaks with libavfilter anyway.) In addition, there is no automatic format negotiation or conversion. libavfilter's primitive and insufficient API simply doesn't allow us to do this in a reasonable way. Instead, filters can use f_autoconvert as sub-filter, and tell it which formats they support. This filter will in turn add actual conversion filters, such as f_swscale, to perform necessary format changes. vf_vapoursynth.c uses the same basic principle of operation as before, but with worryingly different details in data flow. Still appears to work. The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are heavily changed. Fortunately, they all used refqueue.c, which is for sharing the data flow logic (especially for managing future/past surfaces and such). It turns out it can be used to factor out most of the data flow. Some of these filters accepted software input. Instead of having ad-hoc upload code in each filter, surface upload is now delegated to f_autoconvert, which can use f_hwupload to perform this. Exporting VO capabilities is still a big mess (mp_stream_info stuff). The D3D11 code drops the redundant image formats, and all code uses the hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a big mess for now. f_async_queue is unused.
2018-01-16 10:53:44 +00:00
( "filters/f_hwtransfer.c" ),
( "filters/f_lavfi.c" ),
( "filters/f_output_chain.c" ),
( "filters/f_swresample.c" ),
video: rewrite filtering glue code Get rid of the old vf.c code. Replace it with a generic filtering framework, which can potentially handle more than just --vf. At least reimplementing --af with this code is planned. This changes some --vf semantics (including runtime behavior and the "vf" command). The most important ones are listed in interface-changes. vf_convert.c is renamed to f_swscale.c. It is now an internal filter that can not be inserted by the user manually. f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is conceptually easy, but a big mess due to the data flow changes). The existing filters are all changed heavily. The data flow of the new filter framework is different. Especially EOF handling changes - EOF is now a "frame" rather than a state, and must be passed through exactly once. Another major thing is that all filters must support dynamic format changes. The filter reconfig() function goes away. (This sounds complex, but since all filters need to handle EOF draining anyway, they can use the same code, and it removes the mess with reconfig() having to predict the output format, which completely breaks with libavfilter anyway.) In addition, there is no automatic format negotiation or conversion. libavfilter's primitive and insufficient API simply doesn't allow us to do this in a reasonable way. Instead, filters can use f_autoconvert as sub-filter, and tell it which formats they support. This filter will in turn add actual conversion filters, such as f_swscale, to perform necessary format changes. vf_vapoursynth.c uses the same basic principle of operation as before, but with worryingly different details in data flow. Still appears to work. The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are heavily changed. Fortunately, they all used refqueue.c, which is for sharing the data flow logic (especially for managing future/past surfaces and such). It turns out it can be used to factor out most of the data flow. Some of these filters accepted software input. Instead of having ad-hoc upload code in each filter, surface upload is now delegated to f_autoconvert, which can use f_hwupload to perform this. Exporting VO capabilities is still a big mess (mp_stream_info stuff). The D3D11 code drops the redundant image formats, and all code uses the hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a big mess for now. f_async_queue is unused.
2018-01-16 10:53:44 +00:00
( "filters/f_swscale.c" ),
( "filters/f_utils.c" ),
( "filters/filter.c" ),
( "filters/frame.c" ),
( "filters/user_filters.c" ),
2013-12-17 00:23:09 +00:00
## Input
( "input/cmd.c" ),
( "input/event.c" ),
2013-12-17 00:23:09 +00:00
( "input/input.c" ),
( "input/ipc.c" ),
( ipc_c ),
( "input/keycodes.c" ),
( "input/sdl_gamepad.c", "sdl2-gamepad" ),
2013-12-17 00:23:09 +00:00
## Misc
( "misc/bstr.c" ),
( "misc/charset_conv.c" ),
( "misc/dispatch.c" ),
2018-03-10 03:25:51 +00:00
( "misc/jni.c", "android" ),
( "misc/json.c" ),
( "misc/natural_sort.c" ),
( "misc/node.c" ),
( "misc/rendezvous.c" ),
( "misc/thread_pool.c" ),
( "misc/thread_tools.c" ),
## Options
( "options/m_config_core.c" ),
( "options/m_config_frontend.c" ),
( "options/m_option.c" ),
( "options/m_property.c" ),
( "options/options.c" ),
( "options/parse_commandline.c" ),
( "options/parse_configfile.c" ),
( "options/path.c" ),
2013-12-16 23:53:22 +00:00
## Player
( "player/audio.c" ),
( "player/client.c" ),
2013-12-16 23:53:22 +00:00
( "player/command.c" ),
( "player/configfiles.c" ),
( "player/external_files.c" ),
( "player/javascript.c", "javascript" ),
2013-12-16 23:53:22 +00:00
( "player/loadfile.c" ),
( "player/lua.c", "lua" ),
2013-12-16 23:53:22 +00:00
( "player/main.c" ),
( "player/misc.c" ),
( "player/osd.c" ),
( "player/playloop.c" ),
( "player/screenshot.c" ),
( "player/scripting.c" ),
2013-12-16 23:53:22 +00:00
( "player/sub.c" ),
( "player/video.c" ),
## Streams
( "stream/cookies.c" ),
( "stream/dvb_tune.c", "dvbin" ),
( "stream/stream.c" ),
( "stream/stream_avdevice.c" ),
( "stream/stream_bluray.c", "libbluray" ),
( "stream/stream_cb.c" ),
( "stream/stream_cdda.c", "cdda" ),
( "stream/stream_concat.c" ),
( "stream/stream_slice.c" ),
( "stream/stream_dvb.c", "dvbin" ),
( "stream/stream_dvdnav.c", "dvdnav" ),
( "stream/stream_edl.c" ),
( "stream/stream_file.c" ),
( "stream/stream_lavf.c" ),
( "stream/stream_libarchive.c", "libarchive" ),
( "stream/stream_memory.c" ),
( "stream/stream_mf.c" ),
( "stream/stream_null.c" ),
## Subtitles
( "sub/ass_mp.c" ),
( "sub/dec_sub.c" ),
( "sub/draw_bmp.c" ),
( "sub/filter_regex.c", "posix" ),
( "sub/filter_jsre.c", "javascript" ),
( "sub/filter_sdh.c" ),
( "sub/img_convert.c" ),
( "sub/lavc_conv.c" ),
( "sub/osd.c" ),
( "sub/osd_libass.c" ),
( "sub/sd_ass.c" ),
( "sub/sd_lavc.c" ),
test: make tests part of the mpv binary Until now, each .c file in test/ was built as separate, self-contained binary. Each binary could be run to execute the tests it contained. Change this and make them part of the normal mpv binary. Now the tests have to be invoked via the --unittest option. Do this for two reasons: - Tests now run within a "properly" initialized mpv instance, so all services are available. - Possibly simplifying the situation for future build systems. The first point is the main motivation. The mpv code is entangled with mp_log and the option system. It feels like a bad idea to duplicate some of the initialization of this just so you can call code using them. I'm also getting rid of cmocka. There wouldn't be any problem to keep it (it's a perfectly sane set of helpers), but NIH calls. I would have had to aggregate all tests into a CMUnitTest list, and I don't see how I'd get different types of entry points easily. Probably easily solvable, but since we made only pretty basic use of this library, NIH-ing this is actually easier (I needed a list of tests with custom metadata anyway, so all what was left was reimplement the assert_* helpers). Unit tests now don't output anything, and if they fail, they'll simply crash and leave a message that typically requires inspecting the test code to figure out what went wrong (and probably editing the test code to get more information). I even merged the various test functions into single ones. Sucks, but here you go. chmap_sel.c is merged into chmap.c, because I didn't see the point of this being separate. json.c drops the print_message() to go along with the new silent-by-default idea, also there's a memory leak fix unrelated to the rest of this commit. The new code is enabled with --enable-tests (--enable-test goes away). Due to waf's option parser, --enable-test still works, because it's a unique prefix to --enable-tests.
2019-11-07 21:42:14 +00:00
## Tests
( "test/chmap.c", "tests" ),
( "test/gl_video.c", "tests" ),
( "test/img_format.c", "tests" ),
test: make tests part of the mpv binary Until now, each .c file in test/ was built as separate, self-contained binary. Each binary could be run to execute the tests it contained. Change this and make them part of the normal mpv binary. Now the tests have to be invoked via the --unittest option. Do this for two reasons: - Tests now run within a "properly" initialized mpv instance, so all services are available. - Possibly simplifying the situation for future build systems. The first point is the main motivation. The mpv code is entangled with mp_log and the option system. It feels like a bad idea to duplicate some of the initialization of this just so you can call code using them. I'm also getting rid of cmocka. There wouldn't be any problem to keep it (it's a perfectly sane set of helpers), but NIH calls. I would have had to aggregate all tests into a CMUnitTest list, and I don't see how I'd get different types of entry points easily. Probably easily solvable, but since we made only pretty basic use of this library, NIH-ing this is actually easier (I needed a list of tests with custom metadata anyway, so all what was left was reimplement the assert_* helpers). Unit tests now don't output anything, and if they fail, they'll simply crash and leave a message that typically requires inspecting the test code to figure out what went wrong (and probably editing the test code to get more information). I even merged the various test functions into single ones. Sucks, but here you go. chmap_sel.c is merged into chmap.c, because I didn't see the point of this being separate. json.c drops the print_message() to go along with the new silent-by-default idea, also there's a memory leak fix unrelated to the rest of this commit. The new code is enabled with --enable-tests (--enable-test goes away). Due to waf's option parser, --enable-test still works, because it's a unique prefix to --enable-tests.
2019-11-07 21:42:14 +00:00
( "test/json.c", "tests" ),
( "test/linked_list.c", "tests" ),
( "test/paths.c", "tests" ),
( "test/repack.c", "tests && zimg" ),
( "test/scale_sws.c", "tests" ),
( "test/scale_test.c", "tests" ),
( "test/scale_zimg.c", "tests && zimg" ),
( "test/tests.c", "tests" ),
test: make tests part of the mpv binary Until now, each .c file in test/ was built as separate, self-contained binary. Each binary could be run to execute the tests it contained. Change this and make them part of the normal mpv binary. Now the tests have to be invoked via the --unittest option. Do this for two reasons: - Tests now run within a "properly" initialized mpv instance, so all services are available. - Possibly simplifying the situation for future build systems. The first point is the main motivation. The mpv code is entangled with mp_log and the option system. It feels like a bad idea to duplicate some of the initialization of this just so you can call code using them. I'm also getting rid of cmocka. There wouldn't be any problem to keep it (it's a perfectly sane set of helpers), but NIH calls. I would have had to aggregate all tests into a CMUnitTest list, and I don't see how I'd get different types of entry points easily. Probably easily solvable, but since we made only pretty basic use of this library, NIH-ing this is actually easier (I needed a list of tests with custom metadata anyway, so all what was left was reimplement the assert_* helpers). Unit tests now don't output anything, and if they fail, they'll simply crash and leave a message that typically requires inspecting the test code to figure out what went wrong (and probably editing the test code to get more information). I even merged the various test functions into single ones. Sucks, but here you go. chmap_sel.c is merged into chmap.c, because I didn't see the point of this being separate. json.c drops the print_message() to go along with the new silent-by-default idea, also there's a memory leak fix unrelated to the rest of this commit. The new code is enabled with --enable-tests (--enable-test goes away). Due to waf's option parser, --enable-test still works, because it's a unique prefix to --enable-tests.
2019-11-07 21:42:14 +00:00
## Video
( "video/csputils.c" ),
( "video/cuda.c", "cuda-hwaccel" ),
( "video/d3d.c", "d3d-hwaccel" ),
hwdec/drmprime: add drmprime hwdec-interop In the confusing landscape of hardware video decoding APIs, we have had a long standing support gap for the v4l2 based APIs implemented for the various SoCs from Rockship, Amlogic, Allwinner, etc. While VAAPI is the defacto default for desktop GPUs, the developers who work on these SoCs (who are not the vendors!) have preferred to implement kernel APIs rather than maintain a userspace driver as VAAPI would require. While there are two v4l2 APIs (m2m and requests), and multiple forks of ffmpeg where support for those APIs languishes without reaching upstream, we can at least say that these APIs export frames as DRMPrime dmabufs, and that they use the ffmpeg drm hwcontext. With those two constants, it is possible for us to write a hwdec-interop without worrying about the mess underneath - for the most part. Accordingly, this change implements a hwdec-interop for any decoder that produces frames as DRMPrime dmabufs. The bulk of the heavy lifting is done by the dmabuf interop code we already had from supporting vaapi, and which I refactored for reusability in a previous set of changes. When we combine that with the fact that we can't probe for supported formats, the new code in this change is pretty simple. This change also includes the hwcontext_fns that are required for us to be able to configure the hwcontext used by `hwdec=drm-copy`. This is technically unrelated, but it seemed a good time to fill this gap. From a testing perspective, I have directly tested on a RockPRO64, while others have tested with different flavours of Rockchip and on Amlogic, providing m2m coverage. I have some other SoCs that I need to spin up to test with, but I don't expect big surprises, and when we inevitably need to account for new special cases down the line, we can do so - we won't be able to support every possible configuration blindly.
2022-07-31 20:47:23 +00:00
( "video/drmprime.c", "drm" ),
( "video/decode/vd_lavc.c" ),
( "video/filter/refqueue.c" ),
( "video/filter/vf_d3d11vpp.c", "d3d-hwaccel" ),
( "video/filter/vf_fingerprint.c", "zimg" ),
( "video/filter/vf_format.c" ),
( "video/filter/vf_gpu.c", "egl-helpers && gl && egl" ),
( "video/filter/vf_sub.c" ),
( "video/filter/vf_vapoursynth.c", "vapoursynth" ),
2016-11-22 13:58:31 +00:00
( "video/filter/vf_vavpp.c", "vaapi" ),
( "video/filter/vf_vdpaupp.c", "vdpau" ),
( "video/fmt-conversion.c" ),
( "video/hwdec.c" ),
( "video/image_loader.c" ),
( "video/image_writer.c" ),
( "video/img_format.c" ),
( "video/mp_image.c" ),
( "video/mp_image_pool.c" ),
( "video/out/android_common.c", "android" ),
( "video/out/aspect.c" ),
( "video/out/bitmap_packer.c" ),
( "video/out/cocoa/events_view.m", "cocoa" ),
( "video/out/cocoa/video_view.m", "cocoa" ),
( "video/out/cocoa/window.m", "cocoa" ),
( "video/out/cocoa_common.m", "cocoa" ),
vo_gpu: d3d11: initial implementation This is a new RA/vo_gpu backend that uses Direct3D 11. The GLSL generated by vo_gpu is cross-compiled to HLSL with SPIRV-Cross. What works: - All of mpv's internal shaders should work, including compute shaders. - Some external shaders have been tested and work, including RAVU and adaptive-sharpen. - Non-dumb mode works, even on very old hardware. Most features work at feature level 9_3 and all features work at feature level 10_0. Some features also work at feature level 9_1 and 9_2, but without high-bit- depth FBOs, it's not very useful. (Hardware this old is probably not fast enough for advanced features anyway.) Note: This is more compatible than ANGLE, which requires 9_3 to work at all (GLES 2.0,) and 10_1 for non-dumb-mode (GLES 3.0.) - Hardware decoding with D3D11VA, including decoding of 10-bit formats without truncation to 8-bit. What doesn't work / can be improved: - PBO upload and direct rendering does not work yet. Direct rendering requires persistent-mapped PBOs because the decoder needs to be able to read data from images that have already been decoded and uploaded. Unfortunately, it seems like persistent-mapped PBOs are fundamentally incompatible with D3D11, which requires all resources to use driver- managed memory and requires memory to be unmapped (and hence pointers to be invalidated) when a resource is used in a draw or copy operation. However it might be possible to use D3D11's limited multithreading capabilities to emulate some features of PBOs, like asynchronous texture uploading. - The blit() and clear() operations don't have equivalents in the D3D11 API that handle all cases, so in most cases, they have to be emulated with a shader. This is currently done inside ra_d3d11, but ideally it would be done in generic code, so it can take advantage of mpv's shader generation utilities. - SPIRV-Cross is used through a NIH C-compatible wrapper library, since it does not expose a C interface itself. The library is available here: https://github.com/rossy/crossc - The D3D11 context could be made to support more modern DXGI features in future. For example, it should be possible to add support for high-bit-depth and HDR output with DXGI 1.5/1.6.
2017-09-07 10:18:06 +00:00
( "video/out/d3d11/context.c", "d3d11" ),
( "video/out/d3d11/hwdec_d3d11va.c", "d3d11 && d3d-hwaccel" ),
( "video/out/d3d11/hwdec_dxva2dxgi.c", "d3d11 && d3d9-hwaccel" ),
vo_gpu: d3d11: initial implementation This is a new RA/vo_gpu backend that uses Direct3D 11. The GLSL generated by vo_gpu is cross-compiled to HLSL with SPIRV-Cross. What works: - All of mpv's internal shaders should work, including compute shaders. - Some external shaders have been tested and work, including RAVU and adaptive-sharpen. - Non-dumb mode works, even on very old hardware. Most features work at feature level 9_3 and all features work at feature level 10_0. Some features also work at feature level 9_1 and 9_2, but without high-bit- depth FBOs, it's not very useful. (Hardware this old is probably not fast enough for advanced features anyway.) Note: This is more compatible than ANGLE, which requires 9_3 to work at all (GLES 2.0,) and 10_1 for non-dumb-mode (GLES 3.0.) - Hardware decoding with D3D11VA, including decoding of 10-bit formats without truncation to 8-bit. What doesn't work / can be improved: - PBO upload and direct rendering does not work yet. Direct rendering requires persistent-mapped PBOs because the decoder needs to be able to read data from images that have already been decoded and uploaded. Unfortunately, it seems like persistent-mapped PBOs are fundamentally incompatible with D3D11, which requires all resources to use driver- managed memory and requires memory to be unmapped (and hence pointers to be invalidated) when a resource is used in a draw or copy operation. However it might be possible to use D3D11's limited multithreading capabilities to emulate some features of PBOs, like asynchronous texture uploading. - The blit() and clear() operations don't have equivalents in the D3D11 API that handle all cases, so in most cases, they have to be emulated with a shader. This is currently done inside ra_d3d11, but ideally it would be done in generic code, so it can take advantage of mpv's shader generation utilities. - SPIRV-Cross is used through a NIH C-compatible wrapper library, since it does not expose a C interface itself. The library is available here: https://github.com/rossy/crossc - The D3D11 context could be made to support more modern DXGI features in future. For example, it should be possible to add support for high-bit-depth and HDR output with DXGI 1.5/1.6.
2017-09-07 10:18:06 +00:00
( "video/out/d3d11/ra_d3d11.c", "d3d11" ),
( "video/out/dither.c" ),
( "video/out/dr_helper.c" ),
( "video/out/drm_atomic.c", "drm" ),
( "video/out/drm_common.c", "drm" ),
Remove remains of Libav compatibility Libav seems rather dead: no release for 2 years, no new git commits in master for almost a year (with one exception ~6 months ago). From what I can tell, some developers resigned themselves to the horrifying idea to post patches to ffmpeg-devel instead, while the rest of the developers went on to greener pastures. Libav was a better project than FFmpeg. Unfortunately, FFmpeg won, because it managed to keep the name and website. Libav was pushed more and more into obscurity: while there was initially a big push for Libav, FFmpeg just remained "in place" and visible for most people. FFmpeg was slowly draining all manpower and energy from Libav. A big part of this was that FFmpeg stole code from Libav (regular merges of the entire Libav git tree), making it some sort of Frankenstein mirror of Libav, think decaying zombie with additional legs ("features") nailed to it. "Stealing" surely is the wrong word; I'm just aping the language that some of the FFmpeg members used to use. All that is in the past now, I'm probably the only person left who is annoyed by this, and with this commit I'm putting this decade long problem finally to an end. I just thought I'd express my annoyance about this fucking shitshow one last time. The most intrusive change in this commit is the resample filter, which originally used libavresample. Since the FFmpeg developer refused to enable libavresample by default for drama reasons, and the API was slightly different, so the filter used some big preprocessor mess to make it compatible to libswresample. All that falls away now. The simplification to the build system is also significant.
2020-02-16 14:14:55 +00:00
( "video/out/drm_prime.c", "drm" ),
( "video/out/filter_kernels.c" ),
( "video/out/gpu/context.c" ),
vo_gpu: d3d11: initial implementation This is a new RA/vo_gpu backend that uses Direct3D 11. The GLSL generated by vo_gpu is cross-compiled to HLSL with SPIRV-Cross. What works: - All of mpv's internal shaders should work, including compute shaders. - Some external shaders have been tested and work, including RAVU and adaptive-sharpen. - Non-dumb mode works, even on very old hardware. Most features work at feature level 9_3 and all features work at feature level 10_0. Some features also work at feature level 9_1 and 9_2, but without high-bit- depth FBOs, it's not very useful. (Hardware this old is probably not fast enough for advanced features anyway.) Note: This is more compatible than ANGLE, which requires 9_3 to work at all (GLES 2.0,) and 10_1 for non-dumb-mode (GLES 3.0.) - Hardware decoding with D3D11VA, including decoding of 10-bit formats without truncation to 8-bit. What doesn't work / can be improved: - PBO upload and direct rendering does not work yet. Direct rendering requires persistent-mapped PBOs because the decoder needs to be able to read data from images that have already been decoded and uploaded. Unfortunately, it seems like persistent-mapped PBOs are fundamentally incompatible with D3D11, which requires all resources to use driver- managed memory and requires memory to be unmapped (and hence pointers to be invalidated) when a resource is used in a draw or copy operation. However it might be possible to use D3D11's limited multithreading capabilities to emulate some features of PBOs, like asynchronous texture uploading. - The blit() and clear() operations don't have equivalents in the D3D11 API that handle all cases, so in most cases, they have to be emulated with a shader. This is currently done inside ra_d3d11, but ideally it would be done in generic code, so it can take advantage of mpv's shader generation utilities. - SPIRV-Cross is used through a NIH C-compatible wrapper library, since it does not expose a C interface itself. The library is available here: https://github.com/rossy/crossc - The D3D11 context could be made to support more modern DXGI features in future. For example, it should be possible to add support for high-bit-depth and HDR output with DXGI 1.5/1.6.
2017-09-07 10:18:06 +00:00
( "video/out/gpu/d3d11_helpers.c", "d3d11 || egl-angle-win32" ),
( "video/out/gpu/error_diffusion.c" ),
( "video/out/gpu/hwdec.c" ),
( "video/out/gpu/lcms.c" ),
( "video/out/gpu/libmpv_gpu.c" ),
( "video/out/gpu/osd.c" ),
( "video/out/gpu/ra.c" ),
( "video/out/gpu/shader_cache.c" ),
( "video/out/gpu/spirv.c" ),
( "video/out/gpu/spirv_shaderc.c", "shaderc" ),
( "video/out/gpu/user_shaders.c" ),
( "video/out/gpu/utils.c" ),
( "video/out/gpu/video.c" ),
( "video/out/gpu/video_shaders.c" ),
( "video/out/gpu_next/context.c", "libplacebo-next" ),
( "video/out/hwdec/hwdec_cuda.c", "cuda-interop" ),
( "video/out/hwdec/hwdec_cuda_gl.c", "cuda-interop && gl" ),
( "video/out/hwdec/hwdec_cuda_vk.c", "cuda-interop && vulkan" ),
hwdec/drmprime: add drmprime hwdec-interop In the confusing landscape of hardware video decoding APIs, we have had a long standing support gap for the v4l2 based APIs implemented for the various SoCs from Rockship, Amlogic, Allwinner, etc. While VAAPI is the defacto default for desktop GPUs, the developers who work on these SoCs (who are not the vendors!) have preferred to implement kernel APIs rather than maintain a userspace driver as VAAPI would require. While there are two v4l2 APIs (m2m and requests), and multiple forks of ffmpeg where support for those APIs languishes without reaching upstream, we can at least say that these APIs export frames as DRMPrime dmabufs, and that they use the ffmpeg drm hwcontext. With those two constants, it is possible for us to write a hwdec-interop without worrying about the mess underneath - for the most part. Accordingly, this change implements a hwdec-interop for any decoder that produces frames as DRMPrime dmabufs. The bulk of the heavy lifting is done by the dmabuf interop code we already had from supporting vaapi, and which I refactored for reusability in a previous set of changes. When we combine that with the fact that we can't probe for supported formats, the new code in this change is pretty simple. This change also includes the hwcontext_fns that are required for us to be able to configure the hwcontext used by `hwdec=drm-copy`. This is technically unrelated, but it seemed a good time to fill this gap. From a testing perspective, I have directly tested on a RockPRO64, while others have tested with different flavours of Rockchip and on Amlogic, providing m2m coverage. I have some other SoCs that I need to spin up to test with, but I don't expect big surprises, and when we inevitably need to account for new special cases down the line, we can do so - we won't be able to support every possible configuration blindly.
2022-07-31 20:47:23 +00:00
( "video/out/hwdec/hwdec_drmprime.c", "drm" ),
( "video/out/hwdec/hwdec_vaapi.c", "vaapi-egl || vaapi-libplacebo" ),
( "video/out/hwdec/dmabuf_interop_gl.c", "dmabuf-interop-gl" ),
( "video/out/hwdec/dmabuf_interop_pl.c", "dmabuf-interop-pl" ),
( "video/out/libmpv_sw.c" ),
( "video/out/placebo/ra_pl.c", "libplacebo" ),
( "video/out/placebo/utils.c", "libplacebo" ),
( "video/out/opengl/angle_dynamic.c", "egl-angle" ),
( "video/out/opengl/common.c", "gl" ),
( "video/out/opengl/context.c", "gl" ),
( "video/out/opengl/context_android.c", "egl-android" ),
( "video/out/opengl/context_angle.c", "egl-angle-win32" ),
( "video/out/opengl/context_cocoa.c", "gl-cocoa" ),
( "video/out/opengl/context_drm_egl.c", "egl-drm" ),
( "video/out/opengl/context_dxinterop.c","gl-dxinterop" ),
( "video/out/opengl/context_glx.c", "gl-x11" ),
( "video/out/opengl/context_rpi.c", "rpi" ),
( "video/out/opengl/context_wayland.c", "gl-wayland" ),
( "video/out/opengl/context_win.c", "gl-win32" ),
( "video/out/opengl/context_x11egl.c", "egl-x11" ),
( "video/out/opengl/egl_helpers.c", "egl-helpers" ),
( "video/out/opengl/formats.c", "gl" ),
( "video/out/opengl/hwdec_d3d11egl.c", "d3d-hwaccel && egl-angle" ),
Remove remains of Libav compatibility Libav seems rather dead: no release for 2 years, no new git commits in master for almost a year (with one exception ~6 months ago). From what I can tell, some developers resigned themselves to the horrifying idea to post patches to ffmpeg-devel instead, while the rest of the developers went on to greener pastures. Libav was a better project than FFmpeg. Unfortunately, FFmpeg won, because it managed to keep the name and website. Libav was pushed more and more into obscurity: while there was initially a big push for Libav, FFmpeg just remained "in place" and visible for most people. FFmpeg was slowly draining all manpower and energy from Libav. A big part of this was that FFmpeg stole code from Libav (regular merges of the entire Libav git tree), making it some sort of Frankenstein mirror of Libav, think decaying zombie with additional legs ("features") nailed to it. "Stealing" surely is the wrong word; I'm just aping the language that some of the FFmpeg members used to use. All that is in the past now, I'm probably the only person left who is annoyed by this, and with this commit I'm putting this decade long problem finally to an end. I just thought I'd express my annoyance about this fucking shitshow one last time. The most intrusive change in this commit is the resample filter, which originally used libavresample. Since the FFmpeg developer refused to enable libavresample by default for drama reasons, and the API was slightly different, so the filter used some big preprocessor mess to make it compatible to libswresample. All that falls away now. The simplification to the build system is also significant.
2020-02-16 14:14:55 +00:00
( "video/out/opengl/hwdec_drmprime_drm.c","drm" ),
( "video/out/opengl/hwdec_dxva2egl.c", "d3d9-hwaccel && egl-angle" ),
( "video/out/opengl/hwdec_dxva2gldx.c", "gl-dxinterop-d3d9" ),
( "video/out/opengl/hwdec_ios.m", "ios-gl" ),
( "video/out/opengl/hwdec_osx.c", "videotoolbox-gl" ),
2019-07-14 13:56:10 +00:00
( "video/out/opengl/hwdec_rpi.c", "rpi-mmal" ),
( "video/out/opengl/hwdec_vdpau.c", "vdpau-gl-x11" ),
( "video/out/opengl/libmpv_gl.c", "gl" ),
( "video/out/opengl/ra_gl.c", "gl" ),
( "video/out/opengl/utils.c", "gl" ),
( "video/out/present_sync.c", "wayland || x11" ),
( "video/out/vo.c" ),
( "video/out/vo_caca.c", "caca" ),
( "video/out/vo_direct3d.c", "direct3d" ),
( "video/out/vo_drm.c", "drm" ),
( "video/out/vo_gpu.c" ),
( "video/out/vo_gpu_next.c", "libplacebo-next" ),
( "video/out/vo_image.c" ),
( "video/out/vo_lavc.c" ),
( "video/out/vo_libmpv.c" ),
( "video/out/vo_mediacodec_embed.c", "android" ),
( "video/out/vo_null.c" ),
2019-07-14 13:56:10 +00:00
( "video/out/vo_rpi.c", "rpi-mmal" ),
( "video/out/vo_sdl.c", "sdl2-video" ),
( "video/out/vo_sixel.c", "sixel" ),
( "video/out/vo_tct.c" ),
( "video/out/vo_vaapi.c", "vaapi-x11 && gpl" ),
( "video/out/vo_vaapi_wayland.c", "vaapi-wayland-memfd" ),
( "video/out/vo_vdpau.c", "vdpau" ),
( "video/out/vo_wlshm.c", "wayland && memfd_create" ),
( "video/out/vo_x11.c" , "x11" ),
( "video/out/vo_xv.c", "xv" ),
vo_gpu: vulkan: initial implementation This time based on ra/vo_gpu. 2017 is the year of the vulkan desktop! Current problems / limitations / improvement opportunities: 1. The swapchain/flipping code violates the vulkan spec, by assuming that the presentation queue will be bounded (in cases where rendering is significantly faster than vsync). But apparently, there's simply no better way to do this right now, to the point where even the stupid cube.c examples from LunarG etc. do it wrong. (cf. https://github.com/KhronosGroup/Vulkan-Docs/issues/370) 2. The memory allocator could be improved. (This is a universal constant) 3. Could explore using push descriptors instead of descriptor sets, especially since we expect to switch descriptors semi-often for some passes (like interpolation). Probably won't make a difference, but the synchronization overhead might be a factor. Who knows. 4. Parallelism across frames / async transfer is not well-defined, we either need to use a better semaphore / command buffer strategy or a resource pooling layer to safely handle cross-frame parallelism. (That said, I gave resource pooling a try and was not happy with the result at all - so I'm still exploring the semaphore strategy) 5. We aggressively use pipeline barriers where events would offer a much more fine-grained synchronization mechanism. As a result of this, we might be suffering from GPU bubbles due to too-short dependencies on objects. (That said, I'm also exploring the use of semaphores as a an ordering tactic which would allow cross-frame time slicing in theory) Some minor changes to the vo_gpu and infrastructure, but nothing consequential. NOTE: For safety, all use of asynchronous commands / multiple command pools is currently disabled completely. There are some left-over relics of this in the code (e.g. the distinction between dev_poll and pool_poll), but that is kept in place mostly because this will be re-extended in the future (vulkan rev 2). The queue count is also currently capped to 1, because of the lack of cross-frame semaphores means we need the implicit synchronization from the same-queue semantics to guarantee a correct result.
2016-09-14 18:54:18 +00:00
( "video/out/vulkan/context.c", "vulkan" ),
( "video/out/vulkan/context_display.c", "vulkan" ),
2019-09-21 20:30:10 +00:00
( "video/out/vulkan/context_android.c", "vulkan && android" ),
( "video/out/vulkan/context_wayland.c", "vulkan && wayland" ),
( "video/out/vulkan/context_win.c", "vulkan && win32-desktop" ),
( "video/out/vulkan/context_xlib.c", "vulkan && x11" ),
( "video/out/vulkan/utils.c", "vulkan" ),
( "video/out/w32_common.c", "win32-desktop" ),
( "generated/wayland/idle-inhibit-unstable-v1.c", "wayland" ),
( "generated/wayland/presentation-time.c", "wayland" ),
( "generated/wayland/xdg-decoration-unstable-v1.c", "wayland" ),
( "generated/wayland/xdg-shell.c", "wayland" ),
( "generated/wayland/linux-dmabuf-unstable-v1.c", "wayland" ),
( "generated/wayland/viewporter.c", "wayland" ),
( "video/out/wayland_common.c", "wayland" ),
( "video/out/win32/displayconfig.c", "win32-desktop" ),
( "video/out/win32/droptarget.c", "win32-desktop" ),
( "video/out/win_state.c"),
( "video/out/x11_common.c", "x11" ),
( "video/repack.c" ),
( "video/sws_utils.c" ),
( "video/zimg.c", "zimg" ),
( "video/vaapi.c", "vaapi" ),
( "video/vdpau.c", "vdpau" ),
( "video/vdpau_mixer.c", "vdpau" ),
## osdep
( getch2_c ),
( "osdep/io.c" ),
( "osdep/threads.c" ),
( "osdep/timer.c" ),
( timer_c ),
( "osdep/polldev.c", "posix" ),
( "osdep/android/strnlen.c", "android"),
( "osdep/glob-win.c", "glob-win32" ),
( "osdep/macosx_application.m", "cocoa" ),
( "osdep/macosx_events.m", "cocoa" ),
( "osdep/macosx_menubar.m", "cocoa" ),
2017-02-25 20:56:59 +00:00
( "osdep/macosx_touchbar.m", "macos-touchbar" ),
( "osdep/mpv.rc", "win32-executable" ),
( "osdep/path-macosx.m", "cocoa" ),
( "osdep/path-unix.c"),
( "osdep/path-uwp.c", "uwp" ),
( "osdep/path-win.c", "win32-desktop" ),
( "osdep/semaphore_osx.c" ),
( "osdep/subprocess.c" ),
( subprocess_c ),
( "osdep/w32_keyboard.c", "os-cygwin" ),
( "osdep/w32_keyboard.c", "os-win32" ),
( "osdep/win32/pthread.c", "win32-internal-pthreads"),
( "osdep/windows_utils.c", "os-cygwin" ),
( "osdep/windows_utils.c", "os-win32" ),
## tree_allocator
"ta/ta.c", "ta/ta_talloc.c", "ta/ta_utils.c"
]
if ctx.dependency_satisfied('win32-executable'):
from waflib import TaskGen
TaskGen.declare_chain(
name = 'windres',
rule = '${WINDRES} ${WINDRES_FLAGS} ${SRC} ${TGT}',
ext_in = '.rc',
ext_out = '-rc.o',
color = 'PINK')
ctx.env.WINDRES_FLAGS = [
'--include-dir={0}'.format(ctx.bldnode.abspath()),
2018-01-01 21:26:18 +00:00
'--include-dir={0}'.format(ctx.srcnode.abspath()),
'--codepage=65001' # Unicode codepage
]
for node in 'osdep/mpv.exe.manifest etc/mpv-icon.ico'.split():
ctx.add_manual_dependency(
ctx.path.find_node('osdep/mpv.rc'),
ctx.path.find_node(node))
version = ctx.bldnode.find_node('generated/version.h')
if version:
ctx.add_manual_dependency(
ctx.path.find_node('osdep/mpv.rc'),
version)
2015-07-15 13:23:10 +00:00
test: make tests part of the mpv binary Until now, each .c file in test/ was built as separate, self-contained binary. Each binary could be run to execute the tests it contained. Change this and make them part of the normal mpv binary. Now the tests have to be invoked via the --unittest option. Do this for two reasons: - Tests now run within a "properly" initialized mpv instance, so all services are available. - Possibly simplifying the situation for future build systems. The first point is the main motivation. The mpv code is entangled with mp_log and the option system. It feels like a bad idea to duplicate some of the initialization of this just so you can call code using them. I'm also getting rid of cmocka. There wouldn't be any problem to keep it (it's a perfectly sane set of helpers), but NIH calls. I would have had to aggregate all tests into a CMUnitTest list, and I don't see how I'd get different types of entry points easily. Probably easily solvable, but since we made only pretty basic use of this library, NIH-ing this is actually easier (I needed a list of tests with custom metadata anyway, so all what was left was reimplement the assert_* helpers). Unit tests now don't output anything, and if they fail, they'll simply crash and leave a message that typically requires inspecting the test code to figure out what went wrong (and probably editing the test code to get more information). I even merged the various test functions into single ones. Sucks, but here you go. chmap_sel.c is merged into chmap.c, because I didn't see the point of this being separate. json.c drops the print_message() to go along with the new silent-by-default idea, also there's a memory leak fix unrelated to the rest of this commit. The new code is enabled with --enable-tests (--enable-test goes away). Due to waf's option parser, --enable-test still works, because it's a unique prefix to --enable-tests.
2019-11-07 21:42:14 +00:00
if ctx.dependency_satisfied('cplayer'):
ctx(
target = "objects",
source = ctx.filtered_sources(sources),
use = ctx.dependencies_use(),
includes = _all_includes(ctx),
features = "c",
)
syms = False
if ctx.dependency_satisfied('cplugins'):
syms = True
ctx.load("syms")
additional_objects = []
if ctx.dependency_satisfied('swift'):
additional_objects.append("osdep/macOS_swift.o")
if ctx.dependency_satisfied('cplayer'):
ctx(
target = "mpv",
source = main_fn_c,
use = ctx.dependencies_use() + ['objects'],
add_objects = additional_objects,
includes = _all_includes(ctx),
features = "c cprogram" + (" syms" if syms else ""),
export_symbols_def = "libmpv/mpv.def", # for syms=True
install_path = ctx.env.BINDIR
)
2016-01-11 21:13:16 +00:00
for f in ['mpv.conf', 'input.conf', 'mplayer-input.conf', \
'restore-old-bindings.conf']:
ctx.install_as(os.path.join(ctx.env.DOCDIR, f),
os.path.join('etc/', f))
if ctx.env.DEST_OS == 'win32':
wrapctx = ctx(
target = "mpv",
source = ['osdep/win32-console-wrapper.c'],
features = "c cprogram",
install_path = ctx.env.BINDIR
)
wrapctx.env.cprogram_PATTERN = "%s.com"
wrapflags = ['-municode', '-Wl,--subsystem,console']
wrapctx.env.CFLAGS = ctx.env.CFLAGS + wrapflags
wrapctx.env.LAST_LINKFLAGS = ctx.env.LAST_LINKFLAGS + wrapflags
build_shared = ctx.dependency_satisfied('libmpv-shared')
build_static = ctx.dependency_satisfied('libmpv-static')
if build_shared or build_static:
if build_shared:
waftoolsdir = os.path.join(os.path.dirname(__file__), "waftools")
ctx.load("syms", tooldir=waftoolsdir)
vre = '#define MPV_CLIENT_API_VERSION MPV_MAKE_VERSION\((.*), (.*)\)'
libmpv_header = ctx.path.find_node("libmpv/client.h").read()
major, minor = re.search(vre, libmpv_header).groups()
libversion = major + '.' + minor + '.0'
2014-06-20 17:21:11 +00:00
def _build_libmpv(shared):
features = "c "
if shared:
features += "cshlib syms"
else:
features += "cstlib"
libmpv_kwargs = {
"target": "mpv",
"source": ctx.filtered_sources(sources),
"use": ctx.dependencies_use(),
"add_objects": additional_objects,
"includes": [ctx.bldnode.abspath(), ctx.srcnode.abspath()] + \
ctx.dependencies_includes(),
"features": features,
"export_symbols_def": "libmpv/mpv.def",
"install_path": ctx.env.LIBDIR,
"install_path_implib": ctx.env.LIBDIR,
}
if shared and ctx.dependency_satisfied('android'):
# for Android we just add the linker flag without version
# as we still need the SONAME for proper linkage.
# (LINKFLAGS logic taken from waf's apply_vnum in ccroot.py)
v=ctx.env.SONAME_ST%'libmpv.so'
ctx.env.append_value('LINKFLAGS',v.split())
else:
# for all other configurations we want SONAME to be used
libmpv_kwargs["vnum"] = libversion
if shared and ctx.env.DEST_OS == 'win32':
libmpv_kwargs["install_path"] = ctx.env.BINDIR
ctx(**libmpv_kwargs)
if build_shared:
_build_libmpv(True)
if build_static:
_build_libmpv(False)
def get_deps():
res = []
for k in ctx.env.keys():
if (k.startswith("LIB_") and k != "LIB_ST") \
or (k.startswith("STLIB_") and k != "STLIB_ST" and k != "STLIB_MARKER"):
for l in ctx.env[k]:
if l in res:
res.remove(l)
res.append(l)
return " ".join(["-l" + l for l in res])
2014-03-11 15:55:49 +00:00
ctx(
target = 'libmpv/mpv.pc',
source = 'libmpv/mpv.pc.in',
features = 'subst',
PREFIX = ctx.env.PREFIX,
LIBDIR = ctx.env.LIBDIR,
INCDIR = ctx.env.INCLUDEDIR,
VERSION = libversion,
PRIV_LIBS = get_deps(),
2014-03-11 15:55:49 +00:00
)
headers = ["client.h", "render.h",
"render_gl.h", "stream_cb.h"]
for f in headers:
ctx.install_as(ctx.env.INCLUDEDIR + '/mpv/' + f, 'libmpv/' + f)
2014-03-11 15:55:49 +00:00
ctx.install_as(ctx.env.LIBDIR + '/pkgconfig/mpv.pc', 'libmpv/mpv.pc')
2015-12-29 19:57:09 +00:00
if ctx.dependency_satisfied('html-build'):
_build_html(ctx)
if ctx.dependency_satisfied('manpage-build'):
_build_man(ctx)
if ctx.dependency_satisfied('pdf-build'):
_build_pdf(ctx)
if ctx.dependency_satisfied('cplayer'):
zsh completion: move generation to runtime and improve The completion function itself now parses --list-options on the first tab press and caches the results. This does mean a slight delay on that first tab press, but it will only do this if the argument being completed looks like an option (i.e. starts with "-"), so there is never a delay when just completing a file name. I've also put some effort into making it reasonably fast; on my machine it's consistently under 100 ms, more than half of which is mpv itself. Installation of zsh completion is now done unconditionally because it's nothing more than copying a file. If you really don't want it installed, set zshdir to empty: `./waf configure --zshdir= ...` Improvements in functionality compared to the old script: * Produces the right results for mpv binaries other than the one it was installed with (like a dev build for testing changes). * Does not require running mpv at build time, so it won't cause problems with cross compilation. * Handles aliases. * Slightly nicer handling of options that take comma-separated values and/or sub-options: A space is now inserted at the end instead of a comma, allowing you to immediately start typing the next argument, but typing a comma will still remove the automatically added space, and = and : will now do that too, so you can immediately add a sub-option. * More general/flexible handling of values for options that print their possible values with --option=help. The code as is could handle quite a few more options (*scale, demuxers, decoders, ...), but nobody wants to maintain that list here so we'll just stick with what the old completion script already did.
2017-11-23 00:09:06 +00:00
if ctx.env.ZSHDIR:
ctx.install_as(ctx.env.ZSHDIR + '/_mpv', 'etc/_mpv.zsh')
if ctx.env.BASHDIR:
ctx.install_as(ctx.env.BASHDIR + '/mpv', 'etc/mpv.bash-completion')
ctx.install_files(
ctx.env.DATADIR + '/applications',
['etc/mpv.desktop'] )
ctx.install_files(ctx.env.CONFDIR, ['etc/encoding-profiles.conf'] )
for size in '16x16 32x32 64x64 128x128'.split():
ctx.install_as(
ctx.env.DATADIR + '/icons/hicolor/' + size + '/apps/mpv.png',
'etc/mpv-icon-8bit-' + size + '.png')
ctx.install_as(
ctx.env.DATADIR + '/icons/hicolor/scalable/apps/mpv.svg',
'etc/mpv-gradient.svg')
2016-03-10 09:15:48 +00:00
ctx.install_files(
ctx.env.DATADIR + '/icons/hicolor/symbolic/apps',
['etc/mpv-symbolic.svg'])