2014-03-11 23:40:55 +00:00
|
|
|
import re
|
2014-11-19 17:51:53 +00:00
|
|
|
import os
|
2014-03-11 23:40:55 +00:00
|
|
|
|
2013-07-16 11:28:28 +00:00
|
|
|
def _add_rst_manual_dependencies(ctx):
|
|
|
|
|
manpage_sources_basenames = """
|
|
|
|
|
options.rst ao.rst vo.rst af.rst vf.rst encode.rst
|
2017-10-09 15:30:41 +00:00
|
|
|
input.rst osc.rst stats.rst lua.rst ipc.rst changes.rst""".split()
|
2013-07-16 11:28:28 +00:00
|
|
|
|
2014-06-20 21:01:12 +00:00
|
|
|
manpage_sources = ['DOCS/man/'+x for x in manpage_sources_basenames]
|
2013-07-16 11:28:28 +00:00
|
|
|
|
|
|
|
|
for manpage_source in manpage_sources:
|
|
|
|
|
ctx.add_manual_dependency(
|
2014-06-20 21:01:12 +00:00
|
|
|
ctx.path.find_node('DOCS/man/mpv.rst'),
|
2013-07-16 11:28:28 +00:00
|
|
|
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}',
|
2016-07-26 06:55:54 +00:00
|
|
|
install_path = ctx.env.HTMLDIR)
|
2015-12-29 19:57:09 +00:00
|
|
|
|
|
|
|
|
_add_rst_manual_dependencies(ctx)
|
|
|
|
|
|
2013-07-16 11:28:28 +00:00
|
|
|
def _build_man(ctx):
|
|
|
|
|
ctx(
|
|
|
|
|
name = 'rst2man',
|
2014-06-20 21:01:12 +00:00
|
|
|
target = 'DOCS/man/mpv.1',
|
|
|
|
|
source = 'DOCS/man/mpv.rst',
|
2016-12-14 00:21:30 +00:00
|
|
|
rule = '${RST2MAN} --strip-elements-with-class=contents ${SRC} ${TGT}',
|
2013-11-23 10:35:16 +00:00
|
|
|
install_path = ctx.env.MANDIR + '/man1')
|
2013-07-16 11:28:28 +00:00
|
|
|
|
|
|
|
|
_add_rst_manual_dependencies(ctx)
|
|
|
|
|
|
|
|
|
|
def _build_pdf(ctx):
|
2014-01-08 15:43:33 +00:00
|
|
|
ctx(
|
|
|
|
|
name = 'rst2pdf',
|
2014-06-20 21:01:12 +00:00
|
|
|
target = 'DOCS/man/mpv.pdf',
|
|
|
|
|
source = 'DOCS/man/mpv.rst',
|
2016-12-11 00:01:42 +00:00
|
|
|
rule = '${RST2PDF} -c -b 1 --repeat-table-rows ${SRC} -o ${TGT}',
|
2014-01-08 15:43:33 +00:00
|
|
|
install_path = ctx.env.DOCDIR)
|
2013-07-16 11:28:28 +00:00
|
|
|
|
|
|
|
|
_add_rst_manual_dependencies(ctx)
|
|
|
|
|
|
2014-12-28 08:38:22 +00:00
|
|
|
def _all_includes(ctx):
|
|
|
|
|
return [ctx.bldnode.abspath(), ctx.srcnode.abspath()] + \
|
|
|
|
|
ctx.dependencies_includes()
|
|
|
|
|
|
2013-07-16 11:28:28 +00:00
|
|
|
def build(ctx):
|
|
|
|
|
ctx.load('waf_customizations')
|
|
|
|
|
ctx.load('generators.sources')
|
|
|
|
|
|
2016-12-17 16:12:56 +00:00
|
|
|
ctx(
|
|
|
|
|
features = "file2string",
|
2014-01-14 07:18:05 +00:00
|
|
|
source = "TOOLS/osxbundle/mpv.app/Contents/Resources/icon.icns",
|
2019-06-21 22:03:31 +00:00
|
|
|
target = "generated/TOOLS/osxbundle/mpv.app/Contents/Resources/icon.icns.inc",
|
2016-12-17 16:12:56 +00:00
|
|
|
)
|
2014-01-14 07:18:05 +00:00
|
|
|
|
2019-06-21 22:03:31 +00:00
|
|
|
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
|
|
|
|
2016-12-17 16:12:56 +00:00
|
|
|
ctx(
|
|
|
|
|
features = "file2string",
|
2013-07-16 11:28:28 +00:00
|
|
|
source = "etc/input.conf",
|
2019-06-21 22:03:31 +00:00
|
|
|
target = "generated/etc/input.conf.inc",
|
2016-12-17 16:12:56 +00:00
|
|
|
)
|
2013-07-16 11:28:28 +00:00
|
|
|
|
2016-12-17 16:12:56 +00:00
|
|
|
ctx(
|
|
|
|
|
features = "file2string",
|
2016-09-15 11:45:23 +00:00
|
|
|
source = "etc/builtin.conf",
|
2019-06-21 22:03:31 +00:00
|
|
|
target = "generated/etc/builtin.conf.inc",
|
2016-12-17 16:12:56 +00:00
|
|
|
)
|
2016-09-15 11:45:23 +00:00
|
|
|
|
2016-12-17 16:12:56 +00:00
|
|
|
ctx(
|
|
|
|
|
features = "file2string",
|
2013-07-16 11:28:28 +00:00
|
|
|
source = "sub/osd_font.otf",
|
2019-06-21 22:03:31 +00:00
|
|
|
target = "generated/sub/osd_font.otf.inc",
|
2016-12-17 16:12:56 +00:00
|
|
|
)
|
2013-07-16 11:28:28 +00:00
|
|
|
|
2014-11-19 17:51:53 +00:00
|
|
|
lua_files = ["defaults.lua", "assdraw.lua", "options.lua", "osc.lua",
|
2020-08-05 20:37:47 +00:00
|
|
|
"ytdl_hook.lua", "stats.lua", "console.lua",
|
|
|
|
|
"auto_profiles.lua"]
|
2016-12-17 16:12:56 +00:00
|
|
|
|
2014-11-19 17:51:53 +00:00
|
|
|
for fn in lua_files:
|
|
|
|
|
fn = "player/lua/" + fn
|
2016-12-17 16:12:56 +00:00
|
|
|
ctx(
|
|
|
|
|
features = "file2string",
|
|
|
|
|
source = fn,
|
2019-06-21 22:03:31 +00:00
|
|
|
target = "generated/%s.inc" % fn,
|
2016-12-17 16:12:56 +00:00
|
|
|
)
|
2013-07-16 11:28:28 +00:00
|
|
|
|
2014-12-13 16:27:47 +00:00
|
|
|
ctx(
|
|
|
|
|
features = "file2string",
|
|
|
|
|
source = "player/javascript/defaults.js",
|
2019-06-21 22:03:31 +00:00
|
|
|
target = "generated/player/javascript/defaults.js.inc",
|
2014-12-13 16:27:47 +00:00
|
|
|
)
|
|
|
|
|
|
2017-10-01 20:16:49 +00:00
|
|
|
if ctx.dependency_satisfied('wayland'):
|
|
|
|
|
ctx.wayland_protocol_code(proto_dir = ctx.env.WL_PROTO_DIR,
|
2018-04-23 14:10:40 +00:00
|
|
|
protocol = "stable/xdg-shell/xdg-shell",
|
2019-06-21 22:03:31 +00:00
|
|
|
target = "generated/wayland/xdg-shell.c")
|
2017-10-01 20:16:49 +00:00
|
|
|
ctx.wayland_protocol_header(proto_dir = ctx.env.WL_PROTO_DIR,
|
2018-04-23 14:10:40 +00:00
|
|
|
protocol = "stable/xdg-shell/xdg-shell",
|
2019-06-21 22:03:31 +00:00
|
|
|
target = "generated/wayland/xdg-shell.h")
|
2017-10-01 20:16:49 +00:00
|
|
|
ctx.wayland_protocol_code(proto_dir = ctx.env.WL_PROTO_DIR,
|
|
|
|
|
protocol = "unstable/idle-inhibit/idle-inhibit-unstable-v1",
|
2019-06-21 22:03:31 +00:00
|
|
|
target = "generated/wayland/idle-inhibit-unstable-v1.c")
|
2017-10-01 20:16:49 +00:00
|
|
|
ctx.wayland_protocol_header(proto_dir = ctx.env.WL_PROTO_DIR,
|
|
|
|
|
protocol = "unstable/idle-inhibit/idle-inhibit-unstable-v1",
|
2019-06-21 22:03:31 +00:00
|
|
|
target = "generated/wayland/idle-inhibit-unstable-v1.h")
|
2019-10-10 19:14:40 +00:00
|
|
|
ctx.wayland_protocol_code(proto_dir = ctx.env.WL_PROTO_DIR,
|
|
|
|
|
protocol = "stable/presentation-time/presentation-time",
|
2019-06-21 22:03:31 +00:00
|
|
|
target = "generated/wayland/presentation-time.c")
|
2019-10-10 19:14:40 +00:00
|
|
|
ctx.wayland_protocol_header(proto_dir = ctx.env.WL_PROTO_DIR,
|
|
|
|
|
protocol = "stable/presentation-time/presentation-time",
|
2019-06-21 22:03:31 +00:00
|
|
|
target = "generated/wayland/presentation-time.h")
|
2018-11-07 12:53:46 +00:00
|
|
|
ctx.wayland_protocol_code(proto_dir = ctx.env.WL_PROTO_DIR,
|
|
|
|
|
protocol = "unstable/xdg-decoration/xdg-decoration-unstable-v1",
|
2019-06-21 22:03:31 +00:00
|
|
|
target = "generated/wayland/xdg-decoration-unstable-v1.c")
|
2018-11-07 12:53:46 +00:00
|
|
|
ctx.wayland_protocol_header(proto_dir = ctx.env.WL_PROTO_DIR,
|
|
|
|
|
protocol = "unstable/xdg-decoration/xdg-decoration-unstable-v1",
|
2019-06-21 22:03:31 +00:00
|
|
|
target = "generated/wayland/xdg-decoration-unstable-v1.h")
|
2022-05-18 14:35:53 +00:00
|
|
|
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")
|
2017-10-01 20:16:49 +00:00
|
|
|
|
wayland: add support for content-type protocol
The content-type protocol allows mpv to send compositor a hint about the
type of content being displayed on its surface so it could potentially
make some sort of optimization. Fundamentally, this is pretty simple but
since this requires a very new wayland-protocols version (1.27), we have
to mess with the build to add a new define and add a bunch of if's in
here. The protocol itself exposes 4 different types of content: none,
photo, video, and game.
To do that, let's add a new option (wayland-content-type) that lets
users control what hint to send to the compossitor. Since the previous
commit adds a VOCTRL that notifies us about the content being displayed,
we can also add an auto value to this option. As you'd expect, the
compositor hint would be set to photo if mpv's core detects an image,
video for other things, and it is set to none for the special case of
forcing a window when there is not a video track. For completion's sake,
game is also allowed as a value for this option, but in practice there
shouldn't be a reason to use that.
2022-11-15 21:51:45 +00:00
|
|
|
if ctx.dependency_satisfied('wayland-protocols-1-27'):
|
|
|
|
|
ctx.wayland_protocol_code(proto_dir = ctx.env.WL_PROTO_DIR,
|
|
|
|
|
protocol = "staging/content-type/content-type-v1",
|
|
|
|
|
target = "generated/wayland/content-type-v1.c")
|
|
|
|
|
ctx.wayland_protocol_header(proto_dir = ctx.env.WL_PROTO_DIR,
|
|
|
|
|
protocol = "staging/content-type/content-type-v1",
|
|
|
|
|
target = "generated/wayland/content-type-v1.h")
|
2022-11-16 01:52:56 +00:00
|
|
|
ctx.wayland_protocol_code(proto_dir = ctx.env.WL_PROTO_DIR,
|
|
|
|
|
protocol = "staging/single-pixel-buffer/single-pixel-buffer-v1",
|
|
|
|
|
target = "generated/wayland/single-pixel-buffer-v1.c")
|
|
|
|
|
ctx.wayland_protocol_header(proto_dir = ctx.env.WL_PROTO_DIR,
|
|
|
|
|
protocol = "staging/single-pixel-buffer/single-pixel-buffer-v1",
|
|
|
|
|
target = "generated/wayland/single-pixel-buffer-v1.h")
|
wayland: add support for content-type protocol
The content-type protocol allows mpv to send compositor a hint about the
type of content being displayed on its surface so it could potentially
make some sort of optimization. Fundamentally, this is pretty simple but
since this requires a very new wayland-protocols version (1.27), we have
to mess with the build to add a new define and add a bunch of if's in
here. The protocol itself exposes 4 different types of content: none,
photo, video, and game.
To do that, let's add a new option (wayland-content-type) that lets
users control what hint to send to the compossitor. Since the previous
commit adds a VOCTRL that notifies us about the content being displayed,
we can also add an auto value to this option. As you'd expect, the
compositor hint would be set to photo if mpv's core detects an image,
video for other things, and it is set to none for the special case of
forcing a window when there is not a video track. For completion's sake,
game is also allowed as a value for this option, but in practice there
shouldn't be a reason to use that.
2022-11-15 21:51:45 +00:00
|
|
|
|
2019-06-21 22:03:31 +00:00
|
|
|
ctx(features = "ebml_header", target = "generated/ebml_types.h")
|
2021-10-19 01:04:30 +00:00
|
|
|
ctx(features = "ebml_definitions", target = "generated/ebml_defs.inc")
|
2013-07-16 11:28:28 +00:00
|
|
|
|
cocoa-cb: initial implementation via opengl-cb API
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend in the future. the problems are various shortcomings of
Apple's opengl implementation and buggy behaviour in certain
circumstances that couldn't be properly worked around. there are also
certain regressions on newer macOS versions from 10.11 onwards.
- awful opengl performance with a none layer backed context
- huge amount of dropped frames with an early context flush
- flickering of system elements like the dock or volume indicator
- double buffering not properly working with a none layer backed context
- bad performance in fullscreen because of system optimisations
all the problems were caused by using a normal opengl context, that
seems somewhat abandoned by apple, and are fixed by using a layer backed
opengl context instead. problems that couldn't be fixed could be
properly worked around.
this has all features our old backend has sans the wid embedding,
the possibility to disable the automatic GPU switching and taking
screenshots of the window content. the first was deemed unnecessary by
me for now, since i just use the libmpv API that others can use anyway.
second is technically not possible atm because we have to pre-allocate
our opengl context at a time the config isn't read yet, so we can't get
the needed property. third one is a bit tricky because of deadlocking
and it needed to be in sync, hopefully i can work around that in the
future.
this also has at least one additional feature or eye-candy. a properly
working fullscreen animation with the native fs. also since this is a
direct port of the old backend of the parts that could be used, though
with adaptions and improvements, this looks a lot cleaner and easier to
understand.
some credit goes to @pigoz for the initial swift build support which
i could improve upon.
Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739,
#2392, #2217
2018-02-12 11:28:19 +00:00
|
|
|
def swift(task):
|
2018-10-27 15:27:01 +00:00
|
|
|
src = [x.abspath() for x in task.inputs]
|
2018-03-09 13:05:38 +00:00
|
|
|
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()
|
2018-10-27 15:20:57 +00:00
|
|
|
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
|
|
|
|
2018-10-27 15:27:01 +00:00
|
|
|
cmd = [ ctx.env.SWIFT ]
|
|
|
|
|
cmd.extend(ctx.env.SWIFT_FLAGS)
|
|
|
|
|
cmd.extend([
|
2018-10-27 15:20:57 +00:00
|
|
|
"-module-name", module_name,
|
2018-10-27 15:27:01 +00:00
|
|
|
"-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)
|
|
|
|
|
|
2020-06-27 09:12:46 +00:00
|
|
|
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 = [
|
2019-09-29 16:35:12 +00:00
|
|
|
( "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" ),
|
2019-12-29 15:39:09 +00:00
|
|
|
( "osdep/macos/remote_command_center.swift", "macos-media-player" ),
|
2020-06-27 09:12:46 +00:00
|
|
|
( "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),
|
2018-10-27 15:27:01 +00:00
|
|
|
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',
|
2018-10-27 15:27:01 +00:00
|
|
|
'-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
|
|
|
])
|
|
|
|
|
|
2017-08-22 09:40:39 +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" ),
|
|
|
|
|
])
|
2017-06-27 11:47:46 +00:00
|
|
|
|
|
|
|
|
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([
|
2020-05-15 14:15:58 +00:00
|
|
|
( "osdep/subprocess-posix.c", "posix" ),
|
2020-07-19 13:50:25 +00:00
|
|
|
( "osdep/subprocess-win.c", "win32-desktop" ),
|
2017-06-27 11:47:46 +00:00
|
|
|
( "osdep/subprocess-dummy.c" ),
|
|
|
|
|
])
|
2013-07-16 11:28:28 +00:00
|
|
|
|
|
|
|
|
sources = [
|
|
|
|
|
## Audio
|
2018-02-21 12:05:08 +00:00
|
|
|
( "audio/aframe.c" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "audio/chmap.c" ),
|
2022-06-01 20:50:49 +00:00
|
|
|
( "audio/chmap_avchannel.c", "av-channel-layout" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "audio/chmap_sel.c" ),
|
|
|
|
|
( "audio/decode/ad_lavc.c" ),
|
|
|
|
|
( "audio/decode/ad_spdif.c" ),
|
2020-05-23 02:04:46 +00:00
|
|
|
( "audio/filter/af_drop.c" ),
|
2018-01-18 13:44:20 +00:00
|
|
|
( "audio/filter/af_format.c" ),
|
|
|
|
|
( "audio/filter/af_lavcac3enc.c" ),
|
2017-09-21 11:50:18 +00:00
|
|
|
( "audio/filter/af_rubberband.c", "rubberband" ),
|
2018-01-18 13:44:20 +00:00
|
|
|
( "audio/filter/af_scaletempo.c" ),
|
2020-07-25 16:02:58 +00:00
|
|
|
( "audio/filter/af_scaletempo2.c" ),
|
|
|
|
|
( "audio/filter/af_scaletempo2_internals.c" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "audio/fmt-conversion.c" ),
|
|
|
|
|
( "audio/format.c" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "audio/out/ao.c" ),
|
|
|
|
|
( "audio/out/ao_alsa.c", "alsa" ),
|
2018-03-10 03:28:09 +00:00
|
|
|
( "audio/out/ao_audiotrack.c", "android" ),
|
2016-10-19 22:08:48 +00:00
|
|
|
( "audio/out/ao_audiounit.m", "audiounit" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "audio/out/ao_coreaudio.c", "coreaudio" ),
|
2019-01-24 00:10:00 +00:00
|
|
|
( "audio/out/ao_coreaudio_chmap.c", "coreaudio || audiounit" ),
|
2014-10-23 07:55:17 +00:00
|
|
|
( "audio/out/ao_coreaudio_exclusive.c", "coreaudio" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "audio/out/ao_coreaudio_properties.c", "coreaudio" ),
|
2019-01-24 00:10:00 +00:00
|
|
|
( "audio/out/ao_coreaudio_utils.c", "coreaudio || audiounit" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "audio/out/ao_jack.c", "jack" ),
|
2018-04-29 18:03:24 +00:00
|
|
|
( "audio/out/ao_lavc.c" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "audio/out/ao_null.c" ),
|
|
|
|
|
( "audio/out/ao_openal.c", "openal" ),
|
2016-02-14 17:03:47 +00:00
|
|
|
( "audio/out/ao_opensles.c", "opensles" ),
|
2020-11-24 01:22:40 +00:00
|
|
|
( "audio/out/ao_oss.c", "oss-audio" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "audio/out/ao_pcm.c" ),
|
2022-01-06 20:54:21 +00:00
|
|
|
( "audio/out/ao_pipewire.c", "pipewire" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "audio/out/ao_pulse.c", "pulse" ),
|
2019-10-22 14:41:19 +00:00
|
|
|
( "audio/out/ao_sdl.c", "sdl2-audio" ),
|
2020-11-25 03:10:19 +00:00
|
|
|
( "audio/out/ao_sndio.c", "sndio" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "audio/out/ao_wasapi.c", "wasapi" ),
|
2014-11-17 11:37:51 +00:00
|
|
|
( "audio/out/ao_wasapi_changenotify.c", "wasapi" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "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" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
|
|
|
|
|
## Core
|
2013-12-17 01:39:45 +00:00
|
|
|
( "common/av_common.c" ),
|
|
|
|
|
( "common/av_log.c" ),
|
|
|
|
|
( "common/codecs.c" ),
|
|
|
|
|
( "common/common.c" ),
|
2018-04-29 18:03:24 +00:00
|
|
|
( "common/encode_lavc.c" ),
|
2013-12-17 01:39:45 +00:00
|
|
|
( "common/msg.c" ),
|
|
|
|
|
( "common/playlist.c" ),
|
2017-02-07 16:05:17 +00:00
|
|
|
( "common/recorder.c" ),
|
stats: some more performance graphs
Add an infrastructure for collecting performance-related data, use it in
some places. Add rendering of them to stats.lua.
There were two main goals: minimal impact on the normal code and normal
playback. So all these stats_* function calls either happen only during
initialization, or return immediately if no stats collection is going
on. That's why it does this lazily adding of stats entries etc. (a first
iteration made each stats entry an API thing, instead of just a single
stats_ctx, but I thought that was getting too intrusive in the "normal"
code, even if everything gets worse inside of stats.c).
You could get most of this information from various profilers (including
the extremely primitive --dump-stats thing in mpv), but this makes it
easier to see the most important information at once (at least in
theory), partially because we know best about the context of various
things.
Not very happy with this. It's all pretty primitive and dumb. At this
point I just wanted to get over with it, without necessarily having to
revisit it later, but with having my stupid statistics.
Somehow the code feels terrible. There are a lot of meh decisions in
there that could be better or worse (but mostly could be better), and it
just sucks but it's also trivial and uninteresting and does the job. I
guess I hate programming. It's so tedious and the result is always shit.
Anyway, enjoy.
2020-04-08 22:27:54 +00:00
|
|
|
( "common/stats.c" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "common/tags.c" ),
|
2013-12-17 01:39:45 +00:00
|
|
|
( "common/version.c" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
|
|
|
|
|
## Demuxers
|
|
|
|
|
( "demux/codec_tags.c" ),
|
2015-05-19 19:36:21 +00:00
|
|
|
( "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" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "demux/demux.c" ),
|
|
|
|
|
( "demux/demux_cue.c" ),
|
2019-10-02 22:22:18 +00:00
|
|
|
( "demux/demux_disc.c" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "demux/demux_edl.c" ),
|
|
|
|
|
( "demux/demux_lavf.c" ),
|
stream: libarchive wrapper for reading compressed archives
This works similar to the existing .rar support, but uses libarchive.
libarchive supports a number of formats, including zip and (most of)
rar.
Unfortunately, seeking does not work too well. Most libarchive readers
do not support seeking, so it's emulated by skipping data until the
target position. On backwards seek, the file is reopened. This works
fine on a local machine (and if the file is not too large), but will
perform not so well over network connection.
This is disabled by default for now. One reason is that we try
libarchive on every file we open, before trying libavformat, and I'm not
sure if I trust libarchive that much yet. Another reason is that this
breaks multivolume rar support. While libarchive supports seeking in
rar, and (probably) supports multivolume archive, our support of
libarchive (probably) does not. I don't care about multivolume rar, but
vocal users do.
2015-08-16 22:55:26 +00:00
|
|
|
( "demux/demux_libarchive.c", "libarchive" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "demux/demux_mf.c" ),
|
|
|
|
|
( "demux/demux_mkv.c" ),
|
2015-02-17 22:47:37 +00:00
|
|
|
( "demux/demux_mkv_timeline.c" ),
|
2016-03-04 22:51:55 +00:00
|
|
|
( "demux/demux_null.c" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "demux/demux_playlist.c" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "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" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "demux/ebml.c" ),
|
2014-07-05 14:45:28 +00:00
|
|
|
( "demux/packet.c" ),
|
2015-02-17 22:46:12 +00:00
|
|
|
( "demux/timeline.c" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
|
filter: add async queue filter
This is supposed to enable communication between filter graphs on
separate threads. Having multiple threads makes only sense if they can
run concurrently with each other, which requires such an asynchronous
queue as a building block. (Probably.)
The basic idea is that you have two independent filters, which can be
each part of separate filter graphs, but which communicate into one
direction with an explicit queue. This is rather similar to unix pipes.
Just like unix pipes, the queue is limited in size, so that still some
data flow control enforced, and runaway memory usage is avoided.
This implementation is pretty dumb. In theory, you could avoid avoid
waking up the filter graphs in quite a lot of situations. For example,
you don't need to wake up the consumer filter if there are already
frames queued. Also, you could add "watermarks" that set a threshold at
which producer or consumer should be woken up to produce/consume more
frames (this would generally serve to "batch" multiple frames at once,
instead of performing high-frequency wakeups). But this is hard, so the
code is dumb. (I just deleted all related code when I still got
situations where wakeups were lost.)
This is actually salvaged and modified from a much older branch I had
lying around. It will be used in the next commit.
2020-02-29 20:13:56 +00:00
|
|
|
( "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" ),
|
video: make decoder wrapper a filter
Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes
a source filter. vd.h mostly disappears, because mp_filter takes care of
the dataflow, but its remains are in struct mp_decoder_fns.
One goal is to simplify dataflow by letting the filter framework handle
it (or more accurately, using its conventions). One result is that the
decode calls disappear from video.c, because we simply connect the
decoder wrapper and the filter chain with mp_pin_connect().
Another goal is to eventually remove the code duplication between the
audio and video paths for this. This commit prepares for this by trying
to make f_decoder_wrapper.c extensible, so it can be used for audio as
well later.
Decoder framedropping changes a bit. It doesn't seem to be worse than
before, and it's an obscure feature, so I'm content with its new state.
Some special code that was apparently meant to avoid dropping too many
frames in a row is removed, though.
I'm not sure how the source code tree should be organized. For one,
video/decode/vd_lavc.c is the only file in its directory, which is a bit
annoying.
2018-01-28 09:08:45 +00:00
|
|
|
( "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" ),
|
2018-01-18 13:44:20 +00:00
|
|
|
( "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
|
2018-05-01 01:16:03 +00:00
|
|
|
( "input/cmd.c" ),
|
2014-01-04 15:59:22 +00:00
|
|
|
( "input/event.c" ),
|
2013-12-17 00:23:09 +00:00
|
|
|
( "input/input.c" ),
|
2016-03-17 08:27:30 +00:00
|
|
|
( "input/ipc.c" ),
|
2017-06-27 11:47:46 +00:00
|
|
|
( ipc_c ),
|
2013-12-26 16:10:35 +00:00
|
|
|
( "input/keycodes.c" ),
|
2019-10-22 14:41:19 +00:00
|
|
|
( "input/sdl_gamepad.c", "sdl2-gamepad" ),
|
2013-12-17 00:23:09 +00:00
|
|
|
|
2013-12-17 01:39:45 +00:00
|
|
|
## Misc
|
2014-08-29 10:09:04 +00:00
|
|
|
( "misc/bstr.c" ),
|
2013-12-17 01:39:45 +00:00
|
|
|
( "misc/charset_conv.c" ),
|
2014-04-23 18:37:57 +00:00
|
|
|
( "misc/dispatch.c" ),
|
2018-03-10 03:25:51 +00:00
|
|
|
( "misc/jni.c", "android" ),
|
2014-10-16 09:48:18 +00:00
|
|
|
( "misc/json.c" ),
|
2018-07-27 03:01:35 +00:00
|
|
|
( "misc/natural_sort.c" ),
|
2016-08-28 17:33:52 +00:00
|
|
|
( "misc/node.c" ),
|
Add Plan 9-style barriers
Plan 9 has a very interesting synchronization mechanism, the
rendezvous() call. A good property of this is that you don't need to
explicitly initialize and destroy a barrier object, unlike as with e.g.
POSIX barriers (which are mandatory to begin with). Upon "meeting", they
can exchange a value.
This mechanism will be nice to synchronize certain stages of
initialization between threads in the following commit.
Unlike Plan 9 rendezvous(), this is not implemented with a hashtable,
because that would require additional effort (especially if you want to
make it actually scele). Unlike the Plan 9 variant, we use intptr_t
instead of void* as type for the value, because I expect that we will be
mostly passing a status code as value and not a pointer. Converting an
integer to void* requires two cast (because the integer needs to be
intptr_t), the other way around it's only one cast.
We don't particularly care about performance in this case either. It's
simply not important for our use-case. So a simple linked list is used
for waiters, and on wakeup, all waiters are temporarily woken up.
2014-07-26 18:29:48 +00:00
|
|
|
( "misc/rendezvous.c" ),
|
2022-08-15 01:28:54 +00:00
|
|
|
( "misc/random.c" ),
|
player: make screenshot commands honor the async flag
And also change input.conf to make all screenshots async. (Except the
every-frame mode, which always uses synchronous mode and ignores the
flag.) By default, the "screenshot" command is still asynchronous,
because scripts etc. might depend on this behavior.
This is only partially async. The code for determining the filename is
still always run synchronously. Only encoding the screenshot and writing
it to disk is asynchronous. We explicitly document the exact behavior as
undefined, so it can be changed any time.
Some of this is a bit messy, because I wanted to avoid duplicating the
message display code between sync and async mode. In async mode, this is
called from a worker thread, which is not safe because showing a message
accesses the thread-unsafe OSD code. So the core has to be locked during
this, which implies accessing the core and all that. So the code has
weird locking calls, and we need to do core destruction in a more
"controlled" manner (thus the outstanding_async field).
(What I'd really want would be the OSD simply showing log messages
instead.)
This is pretty untested, so expect bugs.
Fixes #4250.
2017-04-01 18:45:20 +00:00
|
|
|
( "misc/thread_pool.c" ),
|
2018-05-06 11:00:05 +00:00
|
|
|
( "misc/thread_tools.c" ),
|
2013-12-17 01:39:45 +00:00
|
|
|
|
2013-12-17 01:02:25 +00:00
|
|
|
## Options
|
2020-03-12 22:07:05 +00:00
|
|
|
( "options/m_config_core.c" ),
|
|
|
|
|
( "options/m_config_frontend.c" ),
|
2013-12-17 01:02:25 +00:00
|
|
|
( "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" ),
|
2014-02-10 20:01:35 +00:00
|
|
|
( "player/client.c" ),
|
2013-12-16 23:53:22 +00:00
|
|
|
( "player/command.c" ),
|
|
|
|
|
( "player/configfiles.c" ),
|
2015-09-20 16:05:06 +00:00
|
|
|
( "player/external_files.c" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "player/javascript.c", "javascript" ),
|
2013-12-16 23:53:22 +00:00
|
|
|
( "player/loadfile.c" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "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" ),
|
2014-05-12 23:14:07 +00:00
|
|
|
( "player/scripting.c" ),
|
2013-12-16 23:53:22 +00:00
|
|
|
( "player/sub.c" ),
|
|
|
|
|
( "player/video.c" ),
|
|
|
|
|
|
2013-07-16 11:28:28 +00:00
|
|
|
## Streams
|
|
|
|
|
( "stream/cookies.c" ),
|
|
|
|
|
( "stream/dvb_tune.c", "dvbin" ),
|
|
|
|
|
( "stream/stream.c" ),
|
|
|
|
|
( "stream/stream_avdevice.c" ),
|
2014-07-14 23:49:02 +00:00
|
|
|
( "stream/stream_bluray.c", "libbluray" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "stream/stream_cb.c" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "stream/stream_cdda.c", "cdda" ),
|
2019-06-19 17:24:01 +00:00
|
|
|
( "stream/stream_concat.c" ),
|
2020-08-16 21:46:13 +00:00
|
|
|
( "stream/stream_slice.c" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "stream/stream_dvb.c", "dvbin" ),
|
2014-07-14 23:49:02 +00:00
|
|
|
( "stream/stream_dvdnav.c", "dvdnav" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "stream/stream_edl.c" ),
|
|
|
|
|
( "stream/stream_file.c" ),
|
|
|
|
|
( "stream/stream_lavf.c" ),
|
stream: libarchive wrapper for reading compressed archives
This works similar to the existing .rar support, but uses libarchive.
libarchive supports a number of formats, including zip and (most of)
rar.
Unfortunately, seeking does not work too well. Most libarchive readers
do not support seeking, so it's emulated by skipping data until the
target position. On backwards seek, the file is reopened. This works
fine on a local machine (and if the file is not too large), but will
perform not so well over network connection.
This is disabled by default for now. One reason is that we try
libarchive on every file we open, before trying libavformat, and I'm not
sure if I trust libarchive that much yet. Another reason is that this
breaks multivolume rar support. While libarchive supports seeking in
rar, and (probably) supports multivolume archive, our support of
libarchive (probably) does not. I don't care about multivolume rar, but
vocal users do.
2015-08-16 22:55:26 +00:00
|
|
|
( "stream/stream_libarchive.c", "libarchive" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "stream/stream_memory.c" ),
|
|
|
|
|
( "stream/stream_mf.c" ),
|
|
|
|
|
( "stream/stream_null.c" ),
|
|
|
|
|
|
|
|
|
|
## Subtitles
|
2020-03-18 21:45:59 +00:00
|
|
|
( "sub/ass_mp.c" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "sub/dec_sub.c" ),
|
|
|
|
|
( "sub/draw_bmp.c" ),
|
2020-02-16 01:03:36 +00:00
|
|
|
( "sub/filter_regex.c", "posix" ),
|
2021-07-23 16:11:23 +00:00
|
|
|
( "sub/filter_jsre.c", "javascript" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "sub/filter_sdh.c" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "sub/img_convert.c" ),
|
2015-12-18 00:57:35 +00:00
|
|
|
( "sub/lavc_conv.c" ),
|
2013-11-24 11:58:06 +00:00
|
|
|
( "sub/osd.c" ),
|
2020-03-18 21:45:59 +00:00
|
|
|
( "sub/osd_libass.c" ),
|
|
|
|
|
( "sub/sd_ass.c" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "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" ),
|
2019-11-08 16:20:57 +00:00
|
|
|
( "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" ),
|
2020-02-06 12:44:16 +00:00
|
|
|
( "test/paths.c", "tests" ),
|
2020-05-09 15:56:44 +00:00
|
|
|
( "test/repack.c", "tests && zimg" ),
|
2019-11-09 00:50:46 +00:00
|
|
|
( "test/scale_sws.c", "tests" ),
|
|
|
|
|
( "test/scale_test.c", "tests" ),
|
|
|
|
|
( "test/scale_zimg.c", "tests && zimg" ),
|
2019-11-08 13:35:35 +00:00
|
|
|
( "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
|
|
|
|
2013-07-16 11:28:28 +00:00
|
|
|
## Video
|
|
|
|
|
( "video/csputils.c" ),
|
2019-12-28 20:58:39 +00:00
|
|
|
( "video/cuda.c", "cuda-hwaccel" ),
|
2017-12-01 16:51:39 +00:00
|
|
|
( "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" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "video/decode/vd_lavc.c" ),
|
2016-05-25 17:01:32 +00:00
|
|
|
( "video/filter/refqueue.c" ),
|
2016-05-28 16:23:17 +00:00
|
|
|
( "video/filter/vf_d3d11vpp.c", "d3d-hwaccel" ),
|
video: add vf_fingerprint and a skip-logo script
skip-logo.lua is just what I wanted to have. Explanations are on the top
of that file. As usual, all documentation threatens to remove this stuff
all the time, since this stuff is just for me, and unlike a normal user
I can afford the luxuary of hacking the shit directly into the player.
vf_fingerprint is needed to support this script. It needs to scale down
video frames as part of its operation. For that, it uses zimg. zimg is
much faster than libswscale and generates more correct output. (The
filter includes a runtime fallback, but it doesn't even work because
libswscale fucks up and can't do YUV->Gray with range adjustment.)
Note on the algorithm: seems almost too simple, but was suggested to me.
It seems to be pretty effective, although long time experience with
false positives is missing. At first I wanted to use dHash [1][2], which
is also pretty simple and effective, but might actually be worse than
the implemented mechanism. dHash has the advantage that the fingerprint
is smaller. But exact matching is too unreliable, and you'd still need
to determine the number of different bits for fuzzier comparison. So
there wasn't really a reason to use it.
[1] https://pypi.org/project/dhash/
[2] http://www.hackerfactor.com/blog/index.php?/archives/529-Kind-of-Like-That.html
2019-07-15 01:20:40 +00:00
|
|
|
( "video/filter/vf_fingerprint.c", "zimg" ),
|
2017-11-29 17:20:29 +00:00
|
|
|
( "video/filter/vf_format.c" ),
|
2019-12-15 23:37:18 +00:00
|
|
|
( "video/filter/vf_gpu.c", "egl-helpers && gl && egl" ),
|
2017-11-29 17:20:29 +00:00
|
|
|
( "video/filter/vf_sub.c" ),
|
2019-06-29 23:20:06 +00:00
|
|
|
( "video/filter/vf_vapoursynth.c", "vapoursynth" ),
|
2016-11-22 13:58:31 +00:00
|
|
|
( "video/filter/vf_vavpp.c", "vaapi" ),
|
2014-04-29 13:07:21 +00:00
|
|
|
( "video/filter/vf_vdpaupp.c", "vdpau" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "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" ),
|
2019-09-23 11:49:36 +00:00
|
|
|
( "video/out/android_common.c", "android" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "video/out/aspect.c" ),
|
|
|
|
|
( "video/out/bitmap_packer.c" ),
|
2014-10-05 20:31:33 +00:00
|
|
|
( "video/out/cocoa/events_view.m", "cocoa" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "video/out/cocoa/video_view.m", "cocoa" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "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" ),
|
2017-12-05 12:47:59 +00:00
|
|
|
( "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" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "video/out/dither.c" ),
|
2018-04-20 15:48:44 +00:00
|
|
|
( "video/out/dr_helper.c" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "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" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "video/out/filter_kernels.c" ),
|
2017-09-22 03:35:26 +00:00
|
|
|
( "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" ),
|
2019-03-16 11:19:51 +00:00
|
|
|
( "video/out/gpu/error_diffusion.c" ),
|
2017-09-22 03:35:26 +00:00
|
|
|
( "video/out/gpu/hwdec.c" ),
|
|
|
|
|
( "video/out/gpu/lcms.c" ),
|
2018-02-20 12:30:18 +00:00
|
|
|
( "video/out/gpu/libmpv_gpu.c" ),
|
2017-09-22 03:35:26 +00:00
|
|
|
( "video/out/gpu/osd.c" ),
|
|
|
|
|
( "video/out/gpu/ra.c" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "video/out/gpu/shader_cache.c" ),
|
2017-09-13 01:09:48 +00:00
|
|
|
( "video/out/gpu/spirv.c" ),
|
|
|
|
|
( "video/out/gpu/spirv_shaderc.c", "shaderc" ),
|
2017-09-22 03:35:26 +00:00
|
|
|
( "video/out/gpu/user_shaders.c" ),
|
|
|
|
|
( "video/out/gpu/utils.c" ),
|
|
|
|
|
( "video/out/gpu/video.c" ),
|
|
|
|
|
( "video/out/gpu/video_shaders.c" ),
|
2022-02-03 15:14:27 +00:00
|
|
|
( "video/out/gpu_next/context.c", "libplacebo-next" ),
|
2021-10-18 14:50:39 +00:00
|
|
|
( "video/out/hwdec/hwdec_aimagereader.c", "android-media-ndk" ),
|
2019-12-28 20:58:39 +00:00
|
|
|
( "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" ),
|
2022-08-27 16:53:31 +00:00
|
|
|
( "video/out/hwdec/hwdec_drmprime_overlay.c","drm" ),
|
2022-02-26 14:13:10 +00:00
|
|
|
( "video/out/hwdec/hwdec_vaapi.c", "vaapi-egl || vaapi-libplacebo" ),
|
2022-07-31 19:59:15 +00:00
|
|
|
( "video/out/hwdec/dmabuf_interop_gl.c", "dmabuf-interop-gl" ),
|
|
|
|
|
( "video/out/hwdec/dmabuf_interop_pl.c", "dmabuf-interop-pl" ),
|
2022-09-27 16:12:54 +00:00
|
|
|
( "video/out/hwdec/dmabuf_interop_wl.c", "dmabuf-wayland" ),
|
2020-07-08 19:55:24 +00:00
|
|
|
( "video/out/libmpv_sw.c" ),
|
2018-11-10 11:53:33 +00:00
|
|
|
( "video/out/placebo/ra_pl.c", "libplacebo" ),
|
|
|
|
|
( "video/out/placebo/utils.c", "libplacebo" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "video/out/opengl/angle_dynamic.c", "egl-angle" ),
|
2015-08-29 02:12:56 +00:00
|
|
|
( "video/out/opengl/common.c", "gl" ),
|
2015-12-19 11:59:07 +00:00
|
|
|
( "video/out/opengl/context.c", "gl" ),
|
2018-07-21 08:38:54 +00:00
|
|
|
( "video/out/opengl/context_android.c", "egl-android" ),
|
2017-09-15 15:37:28 +00:00
|
|
|
( "video/out/opengl/context_angle.c", "egl-angle-win32" ),
|
|
|
|
|
( "video/out/opengl/context_cocoa.c", "gl-cocoa" ),
|
2015-12-19 12:05:10 +00:00
|
|
|
( "video/out/opengl/context_drm_egl.c", "egl-drm" ),
|
2017-09-15 15:37:28 +00:00
|
|
|
( "video/out/opengl/context_dxinterop.c","gl-dxinterop" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "video/out/opengl/context_glx.c", "gl-x11" ),
|
2015-12-19 12:05:10 +00:00
|
|
|
( "video/out/opengl/context_rpi.c", "rpi" ),
|
|
|
|
|
( "video/out/opengl/context_wayland.c", "gl-wayland" ),
|
2017-09-15 15:37:28 +00:00
|
|
|
( "video/out/opengl/context_win.c", "gl-win32" ),
|
2015-12-19 12:05:10 +00:00
|
|
|
( "video/out/opengl/context_x11egl.c", "egl-x11" ),
|
2015-12-19 11:45:07 +00:00
|
|
|
( "video/out/opengl/egl_helpers.c", "egl-helpers" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "video/out/opengl/formats.c", "gl" ),
|
2018-01-24 01:28:22 +00:00
|
|
|
( "video/out/opengl/hwdec_d3d11egl.c", "d3d-hwaccel && egl-angle" ),
|
|
|
|
|
( "video/out/opengl/hwdec_dxva2egl.c", "d3d9-hwaccel && egl-angle" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "video/out/opengl/hwdec_dxva2gldx.c", "gl-dxinterop-d3d9" ),
|
2017-02-16 18:53:48 +00:00
|
|
|
( "video/out/opengl/hwdec_ios.m", "ios-gl" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "video/out/opengl/hwdec_osx.c", "videotoolbox-gl" ),
|
2019-07-14 13:56:10 +00:00
|
|
|
( "video/out/opengl/hwdec_rpi.c", "rpi-mmal" ),
|
2015-08-29 02:12:56 +00:00
|
|
|
( "video/out/opengl/hwdec_vdpau.c", "vdpau-gl-x11" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "video/out/opengl/libmpv_gl.c", "gl" ),
|
|
|
|
|
( "video/out/opengl/ra_gl.c", "gl" ),
|
|
|
|
|
( "video/out/opengl/utils.c", "gl" ),
|
2022-06-10 16:49:28 +00:00
|
|
|
( "video/out/present_sync.c", "wayland || x11" ),
|
2022-09-27 16:12:54 +00:00
|
|
|
( "video/out/wldmabuf/context_wldmabuf.c", "dmabuf-wayland" ),
|
|
|
|
|
( "video/out/wldmabuf/ra_wldmabuf.c", "dmabuf-wayland" ),
|
|
|
|
|
( "video/out/wlbuf_pool.c", "dmabuf-wayland" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "video/out/vo.c" ),
|
|
|
|
|
( "video/out/vo_caca.c", "caca" ),
|
|
|
|
|
( "video/out/vo_direct3d.c", "direct3d" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "video/out/vo_drm.c", "drm" ),
|
|
|
|
|
( "video/out/vo_gpu.c" ),
|
2022-02-03 15:14:27 +00:00
|
|
|
( "video/out/vo_gpu_next.c", "libplacebo-next" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "video/out/vo_image.c" ),
|
2018-04-29 18:03:24 +00:00
|
|
|
( "video/out/vo_lavc.c" ),
|
2018-02-20 12:30:18 +00:00
|
|
|
( "video/out/vo_libmpv.c" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "video/out/vo_mediacodec_embed.c", "android" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "video/out/vo_null.c" ),
|
2019-07-14 13:56:10 +00:00
|
|
|
( "video/out/vo_rpi.c", "rpi-mmal" ),
|
2019-10-22 14:41:19 +00:00
|
|
|
( "video/out/vo_sdl.c", "sdl2-video" ),
|
2020-11-01 11:13:31 +00:00
|
|
|
( "video/out/vo_sixel.c", "sixel" ),
|
2022-12-13 14:58:13 +00:00
|
|
|
( "video/out/vo_kitty.c" ),
|
2016-10-21 23:38:32 +00:00
|
|
|
( "video/out/vo_tct.c" ),
|
vaapi: change license to LGPL
Originally mpv vaapi support was based on the MPlayer-vaapi patches.
These were never merged in upstream MPlayer. The license headers
indicated they were GPL-only. Although the actual author agreed to
relicensing, the company employing him to write this code did not, so
the original code is unusable to us.
Fortunately, vaapi support was refactored and rewritten several times,
meaning little code is actually left. The previous commits removed or
moved that to GPL-only code. Namely, vo_vaapi.c remains GPL-only. The
other code went away or became unnecessary mainly because libavcodec
itself gained the ability to manage the hw decoder, and libavutil
provides code to manage vaapi surfaces. We also changed to mainly using
EGL interop, making any of the old rendering code unnecessary.
hwdec_vaglx.c is still GPL. It's possibly relicensable, because much of
it was changed, but I'm not too sure and further investigation would be
required. Also, this has been disabled by default for a while now, so
bothering with this is a waste of time. This commit simply disables it
at compile time as well in LGPL mode.
2017-09-29 16:44:47 +00:00
|
|
|
( "video/out/vo_vaapi.c", "vaapi-x11 && gpl" ),
|
2022-09-27 16:12:54 +00:00
|
|
|
( "video/out/vo_dmabuf_wayland.c", "dmabuf-wayland" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "video/out/vo_vdpau.c", "vdpau" ),
|
2019-10-17 11:03:14 +00:00
|
|
|
( "video/out/vo_wlshm.c", "wayland && memfd_create" ),
|
2015-09-30 20:52:22 +00:00
|
|
|
( "video/out/vo_x11.c" , "x11" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "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" ),
|
vo_gpu: vulkan: implement a VkDisplayKHR backed context
This is the Vulkan equivalent of the drm context for OpenGL, with
the big difference that it's implemented purely in terms of Vulkan
calls and doesn't actually require drm or kms.
The basic idea is to identify a display, mode, and plane on a device,
and then create a display backed surface for the swapchain. In theory,
past that point, everything is the same, and this is in fact the case
on Intel hardware. I can get a video playing on a vt.
On nvidia, naturally, things don't work that way. Instead, nvidia only
implemented the extension for scenarios where a VR application is
stealing a display from a running window system, and not for
standalone scenarios. With additional code, I've got this scenario to
work but that's a separate incremental change.
Other people have tested on AMD, and report roughly the same behaviour
as on Intel.
Note, that in this change, the VT will not be correctly restored after
qutting. The only way to restore the VT is to introduce some drm
specific code which I will illustrate in a separate change.
2019-12-02 02:37:40 +00:00
|
|
|
( "video/out/vulkan/context_display.c", "vulkan" ),
|
2019-09-21 20:30:10 +00:00
|
|
|
( "video/out/vulkan/context_android.c", "vulkan && android" ),
|
2017-09-16 02:46:38 +00:00
|
|
|
( "video/out/vulkan/context_wayland.c", "vulkan && wayland" ),
|
2018-12-09 07:34:22 +00:00
|
|
|
( "video/out/vulkan/context_win.c", "vulkan && win32-desktop" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "video/out/vulkan/context_xlib.c", "vulkan && x11" ),
|
|
|
|
|
( "video/out/vulkan/utils.c", "vulkan" ),
|
|
|
|
|
( "video/out/w32_common.c", "win32-desktop" ),
|
2022-11-16 01:52:56 +00:00
|
|
|
( "generated/wayland/single-pixel-buffer-v1.c", "wayland-protocols-1-27" ),
|
wayland: add support for content-type protocol
The content-type protocol allows mpv to send compositor a hint about the
type of content being displayed on its surface so it could potentially
make some sort of optimization. Fundamentally, this is pretty simple but
since this requires a very new wayland-protocols version (1.27), we have
to mess with the build to add a new define and add a bunch of if's in
here. The protocol itself exposes 4 different types of content: none,
photo, video, and game.
To do that, let's add a new option (wayland-content-type) that lets
users control what hint to send to the compossitor. Since the previous
commit adds a VOCTRL that notifies us about the content being displayed,
we can also add an auto value to this option. As you'd expect, the
compositor hint would be set to photo if mpv's core detects an image,
video for other things, and it is set to none for the special case of
forcing a window when there is not a video track. For completion's sake,
game is also allowed as a value for this option, but in practice there
shouldn't be a reason to use that.
2022-11-15 21:51:45 +00:00
|
|
|
( "generated/wayland/content-type-v1.c", "wayland-protocols-1-27" ),
|
2019-06-21 22:03:31 +00:00
|
|
|
( "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" ),
|
2022-05-18 14:35:53 +00:00
|
|
|
( "generated/wayland/linux-dmabuf-unstable-v1.c", "wayland" ),
|
|
|
|
|
( "generated/wayland/viewporter.c", "wayland" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "video/out/wayland_common.c", "wayland" ),
|
|
|
|
|
( "video/out/win32/displayconfig.c", "win32-desktop" ),
|
|
|
|
|
( "video/out/win32/droptarget.c", "win32-desktop" ),
|
2014-05-06 18:22:32 +00:00
|
|
|
( "video/out/win_state.c"),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "video/out/x11_common.c", "x11" ),
|
2020-05-09 15:56:44 +00:00
|
|
|
( "video/repack.c" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "video/sws_utils.c" ),
|
2019-10-19 23:54:45 +00:00
|
|
|
( "video/zimg.c", "zimg" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "video/vaapi.c", "vaapi" ),
|
|
|
|
|
( "video/vdpau.c", "vdpau" ),
|
|
|
|
|
( "video/vdpau_mixer.c", "vdpau" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
|
|
|
|
|
## osdep
|
|
|
|
|
( getch2_c ),
|
|
|
|
|
( "osdep/io.c" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "osdep/threads.c" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "osdep/timer.c" ),
|
|
|
|
|
( timer_c ),
|
2017-12-09 14:41:09 +00:00
|
|
|
( "osdep/polldev.c", "posix" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
|
2018-02-21 12:05:08 +00:00
|
|
|
( "osdep/android/strnlen.c", "android"),
|
|
|
|
|
( "osdep/glob-win.c", "glob-win32" ),
|
2015-05-02 16:09:01 +00:00
|
|
|
( "osdep/macosx_application.m", "cocoa" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "osdep/macosx_events.m", "cocoa" ),
|
2017-07-29 13:26:58 +00:00
|
|
|
( "osdep/macosx_menubar.m", "cocoa" ),
|
2017-02-25 20:56:59 +00:00
|
|
|
( "osdep/macosx_touchbar.m", "macos-touchbar" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "osdep/mpv.rc", "win32-executable" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
( "osdep/path-macosx.m", "cocoa" ),
|
2015-05-01 19:13:44 +00:00
|
|
|
( "osdep/path-unix.c"),
|
2017-06-27 11:50:58 +00:00
|
|
|
( "osdep/path-uwp.c", "uwp" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "osdep/path-win.c", "win32-desktop" ),
|
|
|
|
|
( "osdep/semaphore_osx.c" ),
|
|
|
|
|
( "osdep/subprocess.c" ),
|
|
|
|
|
( subprocess_c ),
|
2014-01-19 13:20:02 +00:00
|
|
|
( "osdep/w32_keyboard.c", "os-cygwin" ),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "osdep/w32_keyboard.c", "os-win32" ),
|
2015-01-01 14:10:42 +00:00
|
|
|
( "osdep/win32/pthread.c", "win32-internal-pthreads"),
|
2018-02-21 12:05:08 +00:00
|
|
|
( "osdep/windows_utils.c", "os-cygwin" ),
|
|
|
|
|
( "osdep/windows_utils.c", "os-win32" ),
|
2013-07-16 11:28:28 +00:00
|
|
|
|
|
|
|
|
## 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
|
2013-07-16 11:28:28 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
|
|
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))
|
|
|
|
|
|
2019-06-21 22:03:31 +00:00
|
|
|
version = ctx.bldnode.find_node('generated/version.h')
|
2015-07-17 07:39:52 +00:00
|
|
|
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'):
|
2014-12-28 08:38:22 +00:00
|
|
|
ctx(
|
|
|
|
|
target = "objects",
|
|
|
|
|
source = ctx.filtered_sources(sources),
|
|
|
|
|
use = ctx.dependencies_use(),
|
|
|
|
|
includes = _all_includes(ctx),
|
|
|
|
|
features = "c",
|
|
|
|
|
)
|
|
|
|
|
|
2017-01-12 16:37:11 +00:00
|
|
|
syms = False
|
|
|
|
|
if ctx.dependency_satisfied('cplugins'):
|
|
|
|
|
syms = True
|
|
|
|
|
ctx.load("syms")
|
|
|
|
|
|
2019-09-21 21:33:07 +00:00
|
|
|
additional_objects = []
|
2019-09-20 10:35:54 +00:00
|
|
|
if ctx.dependency_satisfied('swift'):
|
2019-09-21 21:33:07 +00:00
|
|
|
additional_objects.append("osdep/macOS_swift.o")
|
2019-09-20 10:35:54 +00:00
|
|
|
|
2014-08-04 08:54:22 +00:00
|
|
|
if ctx.dependency_satisfied('cplayer'):
|
|
|
|
|
ctx(
|
|
|
|
|
target = "mpv",
|
2015-03-29 11:36:46 +00:00
|
|
|
source = main_fn_c,
|
2014-12-29 17:30:24 +00:00
|
|
|
use = ctx.dependencies_use() + ['objects'],
|
2019-09-21 21:33:07 +00:00
|
|
|
add_objects = additional_objects,
|
2014-12-28 08:38:22 +00:00
|
|
|
includes = _all_includes(ctx),
|
2017-01-12 16:37:11 +00:00
|
|
|
features = "c cprogram" + (" syms" if syms else ""),
|
|
|
|
|
export_symbols_def = "libmpv/mpv.def", # for syms=True
|
2014-11-01 09:57:10 +00:00
|
|
|
install_path = ctx.env.BINDIR
|
2014-08-04 08:54:22 +00:00
|
|
|
)
|
2016-01-11 21:13:16 +00:00
|
|
|
for f in ['mpv.conf', 'input.conf', 'mplayer-input.conf', \
|
2014-10-11 14:16:02 +00:00
|
|
|
'restore-old-bindings.conf']:
|
|
|
|
|
ctx.install_as(os.path.join(ctx.env.DOCDIR, f),
|
|
|
|
|
os.path.join('etc/', f))
|
2013-07-16 11:28:28 +00:00
|
|
|
|
2014-11-21 00:47:30 +00:00
|
|
|
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"
|
2020-09-10 17:56:26 +00:00
|
|
|
wrapflags = ['-municode', '-Wl,--subsystem,console']
|
2018-07-18 00:49:01 +00:00
|
|
|
wrapctx.env.CFLAGS = ctx.env.CFLAGS + wrapflags
|
|
|
|
|
wrapctx.env.LAST_LINKFLAGS = ctx.env.LAST_LINKFLAGS + wrapflags
|
2014-11-21 00:47:30 +00:00
|
|
|
|
2014-06-16 09:22:46 +00:00
|
|
|
build_shared = ctx.dependency_satisfied('libmpv-shared')
|
|
|
|
|
build_static = ctx.dependency_satisfied('libmpv-static')
|
|
|
|
|
if build_shared or build_static:
|
|
|
|
|
if build_shared:
|
2014-08-12 17:19:20 +00:00
|
|
|
waftoolsdir = os.path.join(os.path.dirname(__file__), "waftools")
|
|
|
|
|
ctx.load("syms", tooldir=waftoolsdir)
|
2016-03-11 16:22:50 +00:00
|
|
|
vre = '#define MPV_CLIENT_API_VERSION MPV_MAKE_VERSION\((.*), (.*)\)'
|
2014-08-05 00:23:14 +00:00
|
|
|
libmpv_header = ctx.path.find_node("libmpv/client.h").read()
|
2016-03-11 16:22:50 +00:00
|
|
|
major, minor = re.search(vre, libmpv_header).groups()
|
2014-08-05 00:23:14 +00:00
|
|
|
libversion = major + '.' + minor + '.0'
|
2014-06-20 17:21:11 +00:00
|
|
|
|
2014-06-16 09:22:46 +00:00
|
|
|
def _build_libmpv(shared):
|
|
|
|
|
features = "c "
|
|
|
|
|
if shared:
|
|
|
|
|
features += "cshlib syms"
|
|
|
|
|
else:
|
|
|
|
|
features += "cstlib"
|
2016-02-08 20:39:57 +00:00
|
|
|
|
|
|
|
|
libmpv_kwargs = {
|
|
|
|
|
"target": "mpv",
|
|
|
|
|
"source": ctx.filtered_sources(sources),
|
|
|
|
|
"use": ctx.dependencies_use(),
|
2019-09-21 21:33:07 +00:00
|
|
|
"add_objects": additional_objects,
|
2016-02-08 20:39:57 +00:00
|
|
|
"includes": [ctx.bldnode.abspath(), ctx.srcnode.abspath()] + \
|
|
|
|
|
ctx.dependencies_includes(),
|
|
|
|
|
"features": features,
|
|
|
|
|
"export_symbols_def": "libmpv/mpv.def",
|
|
|
|
|
"install_path": ctx.env.LIBDIR,
|
2017-04-24 14:05:22 +00:00
|
|
|
"install_path_implib": ctx.env.LIBDIR,
|
2016-02-08 20:39:57 +00:00
|
|
|
}
|
|
|
|
|
|
2016-07-28 22:03:19 +00:00
|
|
|
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:
|
2016-02-08 20:39:57 +00:00
|
|
|
# for all other configurations we want SONAME to be used
|
|
|
|
|
libmpv_kwargs["vnum"] = libversion
|
|
|
|
|
|
2017-04-24 14:05:22 +00:00
|
|
|
if shared and ctx.env.DEST_OS == 'win32':
|
|
|
|
|
libmpv_kwargs["install_path"] = ctx.env.BINDIR
|
|
|
|
|
|
2016-02-08 20:39:57 +00:00
|
|
|
ctx(**libmpv_kwargs)
|
|
|
|
|
|
2014-06-16 09:22:46 +00:00
|
|
|
if build_shared:
|
|
|
|
|
_build_libmpv(True)
|
|
|
|
|
if build_static:
|
|
|
|
|
_build_libmpv(False)
|
2014-02-10 20:25:22 +00:00
|
|
|
|
2014-08-07 21:45:40 +00:00
|
|
|
def get_deps():
|
2018-06-20 08:38:51 +00:00
|
|
|
res = []
|
2014-08-07 21:45:40 +00:00
|
|
|
for k in ctx.env.keys():
|
2018-06-20 08:38:51 +00:00
|
|
|
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-08-07 21:45:40 +00:00
|
|
|
|
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,
|
2018-07-01 19:09:45 +00:00
|
|
|
INCDIR = ctx.env.INCLUDEDIR,
|
2014-03-11 23:40:55 +00:00
|
|
|
VERSION = libversion,
|
2014-08-07 21:45:40 +00:00
|
|
|
PRIV_LIBS = get_deps(),
|
2014-03-11 15:55:49 +00:00
|
|
|
)
|
|
|
|
|
|
2021-11-29 12:12:02 +00:00
|
|
|
headers = ["client.h", "render.h",
|
2018-03-04 02:52:09 +00:00
|
|
|
"render_gl.h", "stream_cb.h"]
|
2014-02-10 20:25:22 +00:00
|
|
|
for f in headers:
|
2018-07-01 19:09:45 +00:00
|
|
|
ctx.install_as(ctx.env.INCLUDEDIR + '/mpv/' + f, 'libmpv/' + f)
|
2014-02-10 20:25:22 +00:00
|
|
|
|
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)
|
|
|
|
|
|
2013-07-16 11:28:28 +00:00
|
|
|
if ctx.dependency_satisfied('manpage-build'):
|
|
|
|
|
_build_man(ctx)
|
|
|
|
|
|
|
|
|
|
if ctx.dependency_satisfied('pdf-build'):
|
|
|
|
|
_build_pdf(ctx)
|
|
|
|
|
|
2014-11-28 21:25:54 +00:00
|
|
|
if ctx.dependency_satisfied('cplayer'):
|
2014-06-08 14:00:43 +00:00
|
|
|
|
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')
|
2014-11-28 21:25:54 +00:00
|
|
|
|
2020-01-09 03:09:14 +00:00
|
|
|
if ctx.env.BASHDIR:
|
|
|
|
|
ctx.install_as(ctx.env.BASHDIR + '/mpv', 'etc/mpv.bash-completion')
|
|
|
|
|
|
2014-11-28 21:25:54 +00:00
|
|
|
ctx.install_files(
|
|
|
|
|
ctx.env.DATADIR + '/applications',
|
|
|
|
|
['etc/mpv.desktop'] )
|
2013-07-16 11:28:28 +00:00
|
|
|
|
2022-09-06 18:17:36 +00:00
|
|
|
ctx.install_files(
|
|
|
|
|
ctx.env.DATADIR + '/metainfo',
|
|
|
|
|
['etc/mpv.metainfo.xml'] )
|
|
|
|
|
|
2018-04-29 18:03:24 +00:00
|
|
|
ctx.install_files(ctx.env.CONFDIR, ['etc/encoding-profiles.conf'] )
|
2013-12-28 15:32:49 +00:00
|
|
|
|
2020-07-19 17:13:16 +00:00
|
|
|
for size in '16x16 32x32 64x64 128x128'.split():
|
2014-11-28 21:25:54 +00:00
|
|
|
ctx.install_as(
|
|
|
|
|
ctx.env.DATADIR + '/icons/hicolor/' + size + '/apps/mpv.png',
|
|
|
|
|
'etc/mpv-icon-8bit-' + size + '.png')
|
2015-12-01 07:02:52 +00:00
|
|
|
|
|
|
|
|
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'])
|
