This only existed as essentially a workaround for meson's behavior and
to maintain compatibility with the waf build. Since waf put everything
in a generated subdirectory, we had to put make a subdirectory called
"generated" in the source for meson so stuff could go to the right
place. Well now we don't need to do that anymore. Move the meson.build
files around so they go in the appropriate place in the subdirectory of
the source tree and change the paths of the headers accordingly. A
couple of important things to note.
1. mpv.com now gets made in build/player/mpv.com (necessary because of
a meson limitation)
2. The macos icon generation path is shortened to
TOOLS/osxbundle/icon.icns.inc.
If we see "C" in one of the language vars we check, don't treat it as a language tag.
Once we've checked everything, if we don't have any languages, but saw "C" anywhere, fall back on "en".
4502522a7a implemented cache directories
but only on linux which meant other OSes continued to save this stuff in
their config directory. Since we turned on cache by default, people are
getting cache files in there which is understandably causing some
confusion. Let's go ahead and implement a separate cache directory for
windows since there seems to be some established conventions for this
already. For people using the portable_path, the cache is saved in a
subdirectory within the portable_path since the idea is for that to be
completely self contained.
the reason for checking `EBADF|EINVAL` specifically is unknown. but it's
clearly not working as intended since it can cause issues like #11795.
instead of checking for "bad errors" check for known "good errors" where
we might not want to break out. this includes:
* EINTR: which can happen if read() is interrupted by some signal.
* EAGAIN: which happens if a non-blocking fd would block. `tty_in` is
_not_ non-blocking, so EAGAIN should never occur here. but it's added
just in case that changes in the future.
Fixes: https://github.com/mpv-player/mpv/issues/11795
Closes: https://github.com/mpv-player/mpv/pull/11805
first of all, POLLERR is supposed to be ignored in `.events` and only
returned in `.revents`.
secondly select()'s exceptfds does not have a 1:1 correspondence with
POLLERR. thankfully, the only caller of this function (in terminal-unix)
never set the POLLERR flag so the errorfds were unused anyways.
so go ahead and remove it entirely instead of pretending we can emulate
something that's not possible.
This adds cache as a possible path for mpv to internally pick
(~/.cache/mpv for non-darwin unix-like systems, the usual config
directory for everyone else). For gpu shader cache and icc cache,
controlling whether or not to write such files is done with the new
--gpu-shader-cache and --icc-cache options respectively. Additionally,
--cache-on-disk no longer requires explicitly setting the --cache-dir
option. The old options, --cache-dir, --gpu-shader-cache-dir, and
--icc-cache-dir simply set an override for the directory to save cache
files. If unset, then the cache is saved in XDG_CACHE_HOME.
A pain point for some users is the fact that watch_later is stored in
the ~/.config directory when it's really not configuration data. Roughly
2 years ago, XDG_STATE_DIR was added to the XDG Base Directory
Specification[0] and its description, user-specific state data, actually
perfectly matches what watch_later data is for. Let's go ahead and use
this directory as the default for watch_later. This change only affects
non-darwin unix-like systems (i.e. Linux, BSDs, etc.). The directory
doesn't move for anyone else.
Internally, quite a few things change with regards to the path
selection. If the platform in question does not have a statedir concept,
then the path selection will simply return "home" instead (old
behavior). Fixes#9147.
[0]: 4f2884e16d
macOS really has completely different path conventions that mpv doesn't
take into account and it treats it just like any other old unix-like
system. This means mpv enforces certain conventions on it (like all the
XDG stuff) that doesn't really apply. Since we'd like to use more of
this but at the same time not distrupt mac users even more, let's just
copy and paste the current code to a new file, update the build and call
it a day. This way, the paths of these two platforms can more freely
diverge.
c784820454 introduced a bool option type
as a replacement for the flag type, but didn't actually transition and
remove the flag type because it would have been too much mundane work.
Add xoshiro as a PRNG implementation instead of relying
on srand() and rand() from the C standard library. This,
in particular, lets us avoid platform-defined behavior with
respect to threading.
During execve() ignored and blocked signals carry over to the child
process, though apparently for SIGCHLD (which the bug report was about)
this is implementation-defined.
fixes#9613
Not all deprecated symbols were removed. Only three events were removed for now
since these are not used internally.
This bumps the library version to 2.0.
This seems to work on gcc, clang and mingw as-is, but I made it
conditional on __GNUC__ just in case, even though I can't figure out
which compilers we care about that don't export this define.
Also replace all instances of assert(0) in the code by MP_UNREACHABLE(),
which is a strict improvement.
Before this commit, timeBeginPeriod(1) was set once when mpv starts,
and the timers remained hi-res till mpv exits.
Now we do the same as before on Windows version < 10.
On Windows 10+ we now use timeBeginPeriod if needed, per timeout.
To force a mode regardless of Windows version, set env MPV_HRT:
- "always": the old behavior - hires timers as long as mpv runs.
- "perwait": sets 1ms timer resolution if timeout <= 50ms.
- "never": don't use timeBeginPeriod at all.
It was observed that on Windows 10 we lose about 0.5ms accuracy of
timeouts with "perwait" mode (acceptable), but otherwise it works
well for continuous timeouts (one after the other) and random ones.
On Windows 7 with "perwait": continous timeouts are accurate, but
random timeouts (after some time without timeouts) have bad
accuracy - roughly 16ms resolution instead of the requested 1ms.
Windows 8 was not tested, so to err on the side of caution, we keep
the legacy behavior "always" by default.
If an unknown ESC sequence is detected where an ASCII char <X> follows
the ESC, mpv interprets it as ALT+<X>, which is the traditional
terminal encoding of ALT+letter.
However, if <X> is '[' then it's a CSI sequence which continues after
the '[', and has its own termination rules (can be many chars).
Previously, mpv interpreted unknown CSI sequences as (incorrect) ALT+[
followed by (incorrect) "keys" from the rest of the sequence.
In this commit, if a unknown CSI sequence is detected, mpv ignores
exactly the complete sequence.
When using "stty susp ''" to disable sending the TSTP signal with ^Z,
mpv didn't recognize ^Z correctly in the terminal:
[input] No key binding found for key 'Ctrl+2'.
Because ASCII 26 (^Z) and above were incorrectly considered ^<NUMBER>.
This commit moves the cutoff between letters/numbers from 25 to 26 so
that ^Z is now detected correctly as ^<LETTER>.
Additionally, it rephrases the ^<NUMBER> formula for clarity.
the slider on the touch bar was always updated when any of the related
properties changed their value. this is partially dependent on the
refresh rate of the video, in the case of time-pos. too many updates to
touch bar impact the render performance.
to prevent this we only update the slider when necessary, when the touch
bar or the touch bar item is visible. the touch bar items only need a
granularity of seconds without any decimals, but the time-pos property
provides a granularity with decimals. we floor those values and only
update the touch bar items when we have at least a 1 second difference.
we also check for the visibility of the touch bar and its items.
Fixes#8477
the NSSliderTouchBarItem seem to be broken in a way it can't be fixed.
it has constraints set by default that can't be removed and lead to
warnings and render performance regressions.
instead of using the preconfigured NSSliderTouchBarItem we use a custom
touch bar item (NSCustomTouchBarItem) with a slider, which essential are
the same. this way we can configure our constraints ourselves, which
aren't needed in the first place.
Fixes: #7047
initialising UnsafeMutableRawPointer the way we did won't free those
pointers and we get dangling pointers. explicitly define a scope those
pointers are alive and auto freed.
this drops support for swift <4.1 and with this support for xcode <=9.2.
this was the last setup that is officially working on macOS 10.12.
our old legacy build macOS 10.12 + xcode 9.2 is replaced by macOS 10.13
+ xcode 9.4.1 with swift 4.1. the macOS 10.13 + xcode 10.1 VM is
replaced by the latest macOS 10.14 + xcode 11.3.1 VM. this is the oldest
version officially supported by Apple.
this is in preparations for the following commit.
the pointer used to initialise the respective structs is only guaranteed
to be alive within this constructor. the struct itself is used later and
the data it points to, is not guaranteed to be the same.
to fix this we define a scope that pointer is definitely valid and use
it within this scope. a helper function was added to get the pointers
for several data at once. otherwise we would need to nest
withUnsafeMutableBytes several times, which would make it hard to read.
currently we use the whole screen rectangle to calculate the window
geometry. this doesn't take the menu bar or the Dock into account.
by default use the visible screen rectangle instead. this is also a
change in behaviour, since the window can't be placed outside of this
rectangle anymore. also add an option to change to the old behaviour,
because it can still be useful in certain cases, like placing the window
directly underneath the menu bar when used a desktop background.
Fixes#8272
When mpv is in the background because it was started with
`mpv foo.mp3 &`, or the user did ctrl+z bg, and is then brought to the
foreground with fg, it buffers input until you press enter. This makes
it accept input almost immediately. Having a short interval isn't
important, since input is buffered until the next loop iteration.
Closes#8120.
Apparently mpv supports loading config files from the same directory as
the mpv.exe. This is a fallback of some sort. It used the old_home
mechanism.
I want to add a warning if old_home exists, but that would always show
the warning on win32. Obviously we don't want that.
Add a separate exe_dir entry to deal with that.
Untested, but probably works.
Mistakenly reverted as part of the default configuration directory
location switch-back in aa18a8e1cd.
Separation of the mpv executable directory from old_path is a
good change now that we warn about the old_config directory also
existing.
Fixes#8232Fixes#8244Fixes#8262
In the recent terminal commit, I "compressed" the read() error handling,
and messed it up. The return value could be -1 for other non-fatal
errors (such as EIO when trying to read while backgrounded), which
resulted in buf.len getting messed up.
Fixes: 602384348e
Due to Unix being legacy garbage, it's not possible to safely detect the
ESC key on terminal. The key sequences are ambiguous. The code for the
ESC key also starts the sequences for other special keys.
Until now, you needed to hit ESC twice for it to be recognized.
Attempt to handle this better by using a timeout to detect the key. If
ESC is in the input buffer, but nothing else arrived after a timeout,
assume it's the ESC key. I think this is the method vim uses. Currently,
the timeout is set at 100ms. This is hardcoded and cannot be changed.
It's possible that this causes problems on slow ssh connections or so.
I'm not sure what exactly happens if you manage to get ESC + another
normal key into the input buffer. If it's a known sequence, it will be
matched and interpreted as such. If not, it'll probably be discarded.
remove the libmpv observer for the macOS specific options and use a
config cache + change callback for runtime changes. this is also a
preparation for new backends and generalises even more, since libmpv
functions can't and shouldn't be used in usual vo backends. for feature
parity the config cache is used.
move all backend independent code parts in their own folder and files,
to simplify adding new backends. the goal is to only extend one class
and add the backend dependent parts there. usually only the (un)init,
config and related parts need to be implemented per backend. furthermore
all needed windowing and related events are propagated and can be
overwritten. the other backend dependent part is usually the surface for
rendering, for example the opengl oder metal layer.
in the best case a new backend can be added with only a few hundred
lines.
lua/js utils.get_env_list() uses `environ' which was ANSI, thus
it broke any unicode names/values.
mpv already has an internal utf8_environ for win32, but it's used
only at the getenv(..) wrapper and not exposed in itself, and also it
has lazy initialization - on first getenv() call.
Now `environ' maps to a function which ensures initialization while
keeping it an l-value (like posix expects).
The cost of this fuglyness is that files should include osdep/io.h
(which now declares environ as extern) rather than declaring it
themselves, or else the build will break on mingw.
Make it possible to feed a string to stdin of a subprocess. Out of
laziness, it can't be an arbitrary byte string. (Would require adding an
option type that takes in a Lua byte string.)
Do not set stdin of a subprocess to fd 0 (i.e. mpv's stdin) anymore,
because it makes things more consistent. Enabling stdin didn't make too
much sense in the first place, so this behavior change seems
justifiable.
win32 support missing.
Fixes: #8003
This sets the activeCodePage property in the manifest, which forces the
ANSI code page to be UTF-8 in Windows 10 1903 and up. It shouldn't make
a difference for mpv itself, since mpv already uses the wide-char APIs
for most functions, however some of mpv's dependencies, such as Lua,
rely on the ANSI codepage. Hence this change enables support for Unicode
file names in Lua's I/O library.
Thanks @avih for finding this property.
See:
https://docs.microsoft.com/en-us/windows/uwp/design/globalizing/use-utf8-code-page
This fixes the "run" and "subprocess" commands on Windows, including
youtube-dl support.
Unix-like FD inheritance is emulated on Windows by using an undocumented
data structure[1] that gets passed to the newly created process in
STARTUPINFO.lpReserved2. It consists of two sparse arrays listing the
HANDLE and internal CRT flags corresponding to each FD. This structure
is used and understood primarily by MSVCRT, but there are other runtimes
and frameworks that can write it, like libuv.
The code for creating asynchronous "anonymous" pipes in Windows has been
enhanced and moved into windows_utils.c. This is mainly an artifact of
an unfinished future change to support anonymous IPC clients in Windows.
Right now, it's still only used in subprocess-win.c
[1]: https://www.catch22.net/tuts/undocumented-createprocess
Add env and detach arguments. This means the command.c code must use the
"new" mp_subprocess2(). So also take this as an opportunity to clean up.
win32 support gets broken by it, because it never made the switch to the
newer function.
The new detach parameter makes the "run" command fully redundant, but I
guess we'll keep it for simplicity. But change its implementation to use
mp_subprocess2() (couldn't do this earlier, because win32).
Privately, I'm going to use the "env" argument to add a key binding that
starts a shell with a FILE environment variable set to the currently
playing file, so this is very useful to me.
Note: breaks windows, so for example youtube-dl on windows will not work
anymore. mp_subprocess2() has to be implemented. The old functions are
gone, and subprocess-win.c is not built anymore. It will probably work
on Cygwin.
Apparently mpv supports loading config files from the same directory as
the mpv.exe. This is a fallback of some sort. It used the old_home
mechanism.
I want to add a warning if old_home exists, but that would always show
the warning on win32. Obviously we don't want that.
Add a separate exe_dir entry to deal with that.
Untested, but probably works.
XDG is stupid, so change back to the standard behavior. Unfortunately,
most users will now have the XDG one, so we will still need to load
this. (This is exactly the same problem as when XDG support was
introduced, just the other way around).
This should not affect any normal users. Hopefully I tested this well
enough; my intention is not to torment miserable XDG fans; they can keep
using their config dir if they want it.
This changes behavior in two cases:
- new users (now creates ~/.mpv/ instead of ~/.config/mpv/)
- users which have both directories
The latter case will behave subtly or obviously different, not sure.
Just fix your shit.
Extend the manpage with all the messy details, as far as I could reverse
engineer them from the code.
This should make --term-title work in Windows 8.1 and below.
OSC sequences are defined in ECMA-48. The 'Change Window Title' command,
as far as I can tell, is a de-facto standard defined by xterm[1]. In
either case, this code is probably still not standards-compliant.
This also changes mp_write_console_ansi to convert to UTF-16 before
parsing control sequences, because that made it easier to pass the OSC
param to SetConsoleTitleW. I think it's also more correct to do it this
way, even though it doesn't really matter much for our limited terminal
parsing. As a side-effect of this, mp_write_console_ansi no longer
mutates its argument.
[1]: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Operating-System-Commands
This code runs posix_spawnp() within a fork() in some cases, in order to
"disown" processes which are meant as being started detached. But
posix_spawnp() is not marked as async-signal-safe, so what we do is not
allowed. It could for example cause deadlocks, depending on
implementation and luck at runtime. Turns out posix_spawnp() is useless
crap.
Replace it with "classic" fork() to ensure correctness.
We could probably use another mechanism to start a process "disowned"
than doing a double-fork(). The only problem with "disowning" a process
is calling setsid() (which posix_spawnp() didn't support, but maybe will
in newer revisions), and removing as as parent from the child process
(the double-fork() will make PID 1 the parent). But there is no good way
to either remove us as parent, or to "reap" the PID in a way that is
safe and less of a mess than the current code. This is because
POSIX/UNIX is a miserable heap of shit. (Less shit than "alternatives"
like win32, no doubt.)
Because POSIX/UNIX is a miserable heap of shit, execvp() is also not
specified as async-signal-safe. It's funny how you can run a full
fledged HTTP server in an async-signal-safe context, but not start a
shitty damn process. Unix is really, really, really extremely bad at
this process management stuff. So we reimplement execvp() in an
async-signal-safe way.
The new code assumes that CLOEXEC is a thing. Since POSIX/UNIX is such a
heap of shit, O_CLOEXEC and FD_CLOEXEC were (probably) added at
different times, but both must be present. io.h defines them to 0 if
they don't exist, and in this case the code will error out at runtime.
Surely we could do without CLOEXEC via fallback, but I'll do that only
if at least 1 bug is reported wrt. this issue.
The idea how to report exec() failure or success is from musl. The way
as_execvpe() is also inspired by musl (for example, the list of error
codes that should make it fail is the same as in musl's code).
This fixes two issues with invalid value after 38/48:
- It was not detected correctly and ended up skipping 4 instead of 0.
- The intent was to skip 0, but it's better to skip the rest.
Behavior with valid 2/5 after 38/48 was correct and is unaffected.
This enables native and more complete escape-sequence handling instead
of our emulation. E.g. it supports 256/true colors, and more.
This should get enabled automatically on Windows 10 build 16257
(August 2017) or later.
Previously an SGR sequence was emulated correctly only if:
- It had exactly 1 or 2 numeric values (not 0).
- Only reset, bold, and foreground colors were supported.
- 256/true colors were not skipped correctly with their sub-values.
Now it supports the same as before, plus:
- 0-16 (inclusive) numeric values, e.g. \e[m now resets correctly.
- Supports also codes for background color, reverse, underline* .
- Supports also codes for default intensity/fg/bg/reverse/underline.
- 256/true colors are recognized and skipped gracefully.
* Reverse/underline seem to work only on windows 10.
On FreeBSD non-POSIX threading functions are in a separate header.
DragonFly and OpenBSD adopted FreeBSD header and extensions.
../test.c:3:3: error: implicit declaration of function 'pthread_set_name_np' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
{ pthread_set_name_np(pthread_self(), "ducks"); return 0; }
^
../osdep/threads.c:47:5: error: implicit declaration of function 'pthread_set_name_np' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
pthread_set_name_np(pthread_self(), tname);
^
Signed-off-by: Jan Beich <jbeich@FreeBSD.org>
zsh often sets DECCKM (i.e. Cursor Key Mode) meaning the arrow keys
send `SS3 A/B/C/D` instead of `CSI A/B/C/D`.
Add `key_entry` definitions for this alongside the existing DECCKM Reset
definitions.
Because pthread failures are virtually undebuggable (which sure is
pretty strange, given all these heavy instrumentation tools these days).
Of course it affects only files which include osdep/threads.h.
I'm departing from the usual way to add symbols with config.h and using
"#if", and defining it on the compiler command line + "#ifdef" because I
don't want to include config.h from a header (which would be necessary
in this case) to keep things slightly cleaner. Maybe this is misguided,
but still.
This would have been easier if mpv defined its own wrappers for all
thread functions. But we don't (which to be honest is probably better
than e.g. going crazy like VLC and essentially reimplementing
everything). This seems to be a good compromise. Since it's off by
default and basically a developer tool, the minor undefined behavior
(redefining reserved symbols) isn't much of an issue.
Change all OPT_* macros such that they don't define the entire m_option
initializer, and instead expand only to a part of it, which sets certain
fields. This requires changing almost every option declaration, because
they all use these macros. A declaration now always starts with
{"name", ...
followed by designated initializers only (possibly wrapped in macros).
The OPT_* macros now initialize the .offset and .type fields only,
sometimes also .priv and others.
I think this change makes the option macros less tricky. The old code
had to stuff everything into macro arguments (and attempted to allow
setting arbitrary fields by letting the user pass designated
initializers in the vararg parts). Some of this was made messy due to
C99 and C11 not allowing 0-sized varargs with ',' removal. It's also
possible that this change is pointless, other than cosmetic preferences.
Not too happy about some things. For example, the OPT_CHOICE()
indentation I applied looks a bit ugly.
Much of this change was done with regex search&replace, but some places
required manual editing. In particular, code in "obscure" areas (which I
didn't include in compilation) might be broken now.
In wayland_common.c the author of some option declarations confused the
flags parameter with the default value (though the default value was
also properly set below). I fixed this with this change.
The option code is very old and was added to MPlayer in the early 2000s,
when C99 was still new. MPlayer did not use the "bool" type anywhere,l
and the logical option equivalent to bool, the "flag" option type, used
int, with the convention that only the values 0 and 1 are allowed.
mpv may have hammered many, many additional tentacles to the option
code, but some of the basics never changed, and m_option_type_flag still
uses int. This seems a bit weird, since mpv uses bool for booleans. So
finally introduce an m_option_type_bool. To avoid duplicating too much
code, change the flag code to bool, and "reimplement" m_option_type_flag
on top of m_option_type_bool.
As a "demonstration", change the --fullscreen option to this new type.
Ideally, all options would be changed too bool, and m_option_type_flag
would be removed. But that is a lot of monotonous thankless work, so I'm
not doing it, and making it a painful years long transition.
At the same time, I'm introducing a new concept for option declarations.
Instead of OPT_BOOL(), which define the full m_option struct contents,
there's OPTF_BOOL(), which only takes the option field name itself. The
name is provided via a normal struct field initializer. Other fields
(such as flags) can be provided via designated initializers.
The advantage of this is that we don't need tons of nested vararg
macros. We also don't need to deal with 0-sized varargs being a pain
(and in fact they are not a thing in standard C99 and probably C11).
There is no need to provide a mandatory flags argument either, which is
the reason why so many OPT_ macros are used with a "0" argument. (The
flag argument seems to confuse other developers; they either don't
immediately recognize what it is, and sometimes it's supposed to be the
option's default value.)
Not having to mess with the flag argument in such option macros is also
a reason for the removal of M_OPT_RANGE etc., for the better or worse.
The only place that special-cased the _flag option type was in
command.c; change it to use something effectively very similar that
automatically includes the new _bool option type. Everything else should
be transparent to the change. The fullscreen option change should be
transparent too, as C99 bool is basically an integer type that is
clamped to 0/1 (except in Swift, Swift sucks).
this basically moves the remote command center to our mac events instead
of keeping it our Application, which is only available when started from
mpv itself. also make it independent of the NSApplication.
this also prevents a runtime crash
This is just a more convenient way to start IPC client scripts per mpv
instance.
Does not work on Windows, although it could if the subprocess and IPC
parts are implemented (and I guess .exe/.bat suffixes are required).
Also untested whether it builds on Windows. A lot of other things are
untested too, so don't complain.
The previous method for this sucked: for every launched detached
process, it started a thread, which then would leak if the launched
process didn't end before the player uninitialized. This was very racy
(although I bet the race condition wouldn't trigger in a 100 years), and
wasteful (threads aren't a cheap resource).
Implement it for POSIX directly. posix_spawn() has no direct support for
this, so we need to do it ourselves with fork(). We could probably do it
without fork(), and attempt to collect the PID in another thread. But
then we'd either have a waiting thread again, or we'd need to do an
unsafe waitpid(-1, ...) call. (POSIX process management sucks so badly,
how did they even manage this. Hopefully I'm just missing something, but
I'm not.) So now we depend on both posix_spawn() _and_ fork(), isn't it
fun?
Also call setsid(), to essentially detach the child process from the
terminal. (Otherwise it can receive various signals from the terminal,
which is probably not what you want.) posix_spawn() adds
POSIX_SPAWN_SETSID in newer POSIX releases, but we don't want to rely on
this yet.
The posix_spawnp() call is duplicated, but this is better than somehow
trying to unify the code paths.
Only somewhat tested, so enjoy the bugs.
Introduce mp_subprocess() and related definitions. This is a bit more
flexible than the old stuff. This may or may not be used for a more
complicated feature that involves starting processes, and which would
require more control.
Only port subprocess-posix.c to this API. The player still uses the
"old" API, so for win32 and dummy implementations, the new API is simply
not available, while for POSIX, the old APIs are emulated on top of the
new one. I'm hoping the win32 code can be ported as well, so the ifdefs
in subprocess.c can be dropped, and the player can (if convenient or
needed) use the new API.
this creates a default log for the last mpv run when started from the
bundle. that way one can get a log of what happened even after an issue
occurred. also add a menu entry under Help to show the current log, but
only when the bundle is used.
Fixes#7396Fixes#2547
this deprecates the old cocoa backend only option and moves it to the
general macos ones. add support for the new option in the cocoa-cb
layer creation and use the new option in the olde cocoa backend.
Fixes#7272
when swift is disabled some headers are not included. one of them is the
options/options.h header that is needed for the vo_sub_opts struct. we
include it to fix the build without swift.
the second problem is the build time check for the macOS 10.12.2
features or more specific the Media Player support. since it is a swift
feature we can not use it when swift is disabled. add a separate
Media Player check that also depends on swift and use that new
preprocessor variable as a build time check instead.
Fixes#7282
the old event tap has several problems, like no proper priority support
or having to set accessibility permissions for mpv or the terminal.
it is now replaced by the new MediaPlayer which has proper priority
support and isn't as greedy as previously. this only includes Media Key
support and not any of the other features included in the MediaPlayer
framework, like proper Now Playing data (only set dummy data for now).
this is only available on macOS 10.12.2 and higher.
also removes some unnecessary redefines.
Fixes#6389
the Apple Remote has long been deprecated and abandoned by Apple.
current macs don't come with support for it anymore. support might be
re-added with the next commit.
using the MPContext as ta parent was a bad idea and shouldn't be done in
any circumstances there because it only supposed to be for internal
usage. this had the undesired effect that the options group was freed
but still used since the MPContext is freed afterwards.
instead manually free options group.
this removes the direct access of the mp_vo_opts stuct via the vo struct
and replaces it with the m_config_cache usage. this updates the
fullscreen and window-minimized property via m_config_cache_write_opt
instead of the old mechanism via VOCTRL and event flagging. also use the
new VOCTRL_VO_OPTS_CHANGED event for fullscreen and border changes.
I often watch sporting events. On many occasions I get files with the
same filename for each session. For example, for F1 I might have the
following directory structure:
F1/
FP1.mkv
FP2.mkv
FP3.mkv
Qualification.mkv
Race.mkv
Since usually one simply watches one race after the other, I usually
just rsync the new event's files over the old ones, so, for example,
Race.mkv will be replaced from the file for the last event with the file
from the new event.
One problem with this is that I like to use --resume-playback for other
kinds of media, so I have it on by default. That works great for, say, a
movie, but doesn't work so well with this scheme, because you can
trivially forget to pass --no-resume-playback on the command line and
end up 2 hours in, watching spoilers as the race results scroll down the
screen :-)
This patch adds a new option, --resume-playback-check-mtime, which
validates that the file's mtime hasn't changed since the watch_later
configuration was saved. It does this by setting the watch_later
configuration to have the same mtime as the file after it is saved.
Switching back and forth between checking mtime and not checking mtime
works fine, as we only choose whether to compare based on it, but we
update the watch_later configuration mtime regardless of its value.
all the get_property_* usages were removed because in some circumstances
they can lead to deadlocks. they were replaced by accessing the vo and
mp_vo_opts structs directly, like on other vos.
additionally the mpv helper was split into a mpv and libmpv helper, to
differentiate between private and public APIs and for future changes
like a macOS vulkan context for vo=gpu.
Unused now. The old stream cache used it, but it was removed.
On a side note, the demuxer cache uses mp_mkostemps(). It looks like our
Windows open() emulation handles this correctly by using CREATE_NEW, so
no functionality gets lost by the "new" approach. On the other hand, the
demuxer cache does not set FILE_FLAG_DELETE_ON_CLOSE, but instead tries
to delete the file after opening (POSIX style), which probably won't
work on Windows. But I'm not sure how to make it use the DELETE_ON_CLOSE
flag, so whatever.
If this is used, the runtime expects that wmain() instead of main() is
defined. This caused me severe problems in a certain now irrelevant
case. I think it's a good idea to avoid this special case.
We can just use main() and call GetCommandLineW() instead. This function
returns a single string, so use CommandLineToArgvW() to split it, and
hope it has the same semantics. Should this ever return NULL, hope that
it leaves argc at 0.
Untested, I think.
Supposed to follow the standard function.
The standard function is not standard, but a GNU extension. Adding some
ifdef mess is pointless too - it has no advantages other than having a
mess, and not spotting implementation bugs in the emulation due to
running it only on "obscure" platforms (like Windows, so most computers
actually, except the developer's platform).
There is mkstemp(), which at least is in POSIX 2008. But it's 100%
useless, except in some obscure cases: it doesn't set O_CLOEXEC, nor can
you pass it to it. Without O_CLOEXEC, we'd leak the temporary file to
all child processes. (The fact that the file, which is expected to reach
double or tripple digit GB sizes, will be deleted only once all
processes unreference the FD, makes this sort of a big deal. You could
ftruncate() it, but that doesn't fix all the other problems.)
Why did POSIX standardize mkstemp() and O_CLOEXEC apparently at the same
time, but provided no way to pass O_CLOEXEC to mkstemp()? With the
introduction of O_CLOEXEC, they acknowledged that there's a need to
atomically set the FD_CLOEXEC flag when creating file descriptors.
(FD_CLOEXEC was standard before that, but setting it with fcntl() is
racy.) You're much more likely to need a temp file that is CLOEXEC
rather than the opposite, and even if they were somehow opposed to
CLOEXEC by default (such as for compat. reasons), surely POSIX could
have standardized mkostemp() too or instead.
And then there's the fact that this whole O_CLOEXEC mess is stupid.
Surely there would have been a better way to handle this, instead of
requiring adding O_CLOEXEC to almost ALL instances of open() in all code
that has been written ever. The justification for this is that the
historic default was wrong, and you can't change it (e.g. this won't
work: changing the behavior of exec() and not inherit the FD to the
child process, unless a hypothetical O_KEEP_EXEC flag is set).
But on the other hand, surely you could have introduced an exec()
variant which does close all FDs, except a whitelist of FDs passed to
it. Let's call it execve2(). In fact, I'm going to argue that exec()
call sites are the most aware of whether (and which) FDs to inherit.
Some programs even tried to explicitly iterate over all opened FDs and
explicitly close "unwanted" FDs (which of course was problematic for
other reasons), and such an execve2() call would have been the ideal
solution.
Maybe this proposed solution would have had problems too. But surely
revisiting and reviewing every exec*() call would have been simpler than
reviewing every open() call. And more importantly, having to extend
every damn library function that either calls open() or creates FDs in
some other way, like mkstemp().
What argument are there going to be against this? That there will be
library code that can't keep working correctly with processes that use
the "old" exec? Well, what about all my legacy library code that uses
open() incorrectly, and that will break no matter what?
Well, I'm not going to claim that I can come up with better solutions
than POSIX (generally or in this case), but this situation is ABSOLUTELY
ATROCIOUS. It makes win32 programming look attractive compared to POSIX,
that standard pandering to dead people from the past. (Note: not trying
to insult dead people.)
I'm not sure what POSIX is even doing. Anything useful? Doesn't look
like it to me. Are they paid? Why? They didn't even fix the locale mess,
nor do they intend to. I bet they're proud of discussing compatibility
to 70ies code day in and day out iwtohut ever producing anything useful.
What a load of crap. They seriously got to do better than this.
Oh, and my wrapper is probably buggy. Fortunately that doesn't matter.
Also I'm dumping this into io.h. Originally, io.h was just supposed to
replace broken implementation of standard functions by MinGW (and then
by Android), but whatever, just give a dumping ground for shit code.
this migrates our current swift code to version 5 and 4. building is
support from 10.12.6 and xcode 9.1 onwards.
dynamic linking is the new default, since Apple removed static libs
from their new toolchains and it's the recommended way.
additionally the found macOS SDK version is printed since it's an
important information for finding possible errors now.
Fixes#6470
the force unwrapping of optionals caused many unpredictable segfaults
instead of gracefully exiting or falling back. besides that, it is bad
practice and the code is a lot more stable now.
half of the materials we used were deprecated with macOS 10.14, broken
and not supported by run time changes of the macOS theme. furthermore
our styling names were completely inconsistent with the actually look
since macOS 10.14, eg ultradark got a lot brighter and couldn't be
considered ultradark anymore.
i decided to drop the old option --macos-title-bar-style and rework
the whole mechanism to allow more freedom. now materials and appearance
can be set separately. even if apple changes the look or semantics in
the future the new options can be easily adapted.
new events were added but not fetched by the vo, because we didn't
signal the vo that new events were available.
actually wakeup the vo when new events are available.
Manual changes done:
* Merged the interface-changes under the already master'd changes.
* Moved the hwdec-related option changes to video/decode/vd_lavc.c.
this adds support for GPU rendered screenshots, DR (theoretically) and
possible other advanced functions in the future that need to be executed
from the rendering thread.
additionally frames that would be off screen or not be displayed when on
screen are being dropped now.
without assistive-device permissions the event tap can't be create on
10.14 any more which lead to an assertion.
System Preferences > Security & Privacy > Privacy > Accessibility and
add mpv or your terminal App to the list.
by default the pixel format creation falls back to software renderer
when everything fails. this is mostly needed for VMs. additionally one
can directly request an sw renderer or exclude it entirely.
moved the retrieval of the macOS specific options from the backend
initialisation to the initialisation of the CocoaCB class, the earliest
point possible. this way macOS specific options can be used for the
opengl context creation for example.
the pre-allocation was needed because the layer allocated a opengl
context async itself and we couldn't influence that. so we had to start
the core after the context was actually allocated. furthermore a window,
view and layer hierarchy had to be created so the layer would create
a context.
now, instead of relying on the layer to create a context we do this
manually and re-use that context later when the layer wants to create
one async itself.
Avoids 100% CPU usage due to terminal code retrying read(). Seems like
this was "forgotten" (or there was somehow the assumption poll() would
not signal POLLIN anymore).
Fixes#5842.
Avoids 100% CPU usage due to terminal code retrying read(). Seems like
this was "forgotten" (or there was somehow the assumption poll() would
not signal POLLIN anymore).
Fixes#5842.
It seems a bit inappropriate to have dumped this into stream.c, even if
it's roughly speaking its main user. At least it made its way somewhat
unfortunately to other components not related to the stream or demuxer
layer at all.
I'm too greedy to give this weird helper its own file, so dump it into
thread_tools.c.
Probably a somewhat pointless change.
This makes ICY title changes show up at approximately the correct time,
even if the demuxer buffer is huge. (It'll still be wrong if the stream
byte cache contains a meaningful amount of data.)
It should have the same effect for mid-stream metadata changes in e.g.
OGG (untested).
This is still somewhat fishy, but in parts due to ICY being fishy, and
FFmpeg's metadata change API being somewhat fishy. For example, what
happens if you seek? With FFmpeg AVFMT_EVENT_FLAG_METADATA_UPDATED and
AVSTREAM_EVENT_FLAG_METADATA_UPDATED we hope that FFmpeg will correctly
restore the correct metadata when the first packet is returned.
If you seke with ICY, we're out of luck, and some audio will be
associated with the wrong tag until we get a new title through ICY
metadata update at an essentially random point (it's mostly inherent to
ICY). Then the tags will switch back and forth, and this behavior will
stick with the data stored in the demuxer cache. Fortunately, this can
happen only if the HTTP stream is actually seekable, which it usually is
not for ICY things. Seeking doesn't even make sense with ICY, since you
can't know the exact metadata location. Basically ICY metsdata sucks.
Some complexity is due to a microoptimization: I didn't want additional
atomic accesses for each packet if no timed metadata is used. (It
probably doesn't matter at all.)
the icc profile data is mutated to an UnsafeMutablePointer and could
possibly changed. therefore the size of it should be accessed before a
possible change.
commit 2edf00f changed the MPV_EVENT_SHUTDOWN behaviour slightly, such
that it will only be sent once. cocoa-cb relied on it being sent
continuously till all mpv_handles are destroyed. now it manually shuts
down and destroys the mpv_handle after the animation instead of relying
on this removed behaviour.
when we transitioned to the new libmpv API with commit ae29725 i
reintroduced an old bug that was fixed with 7f714c6 because of a dumb
rebasing error on my part. the branch i based the libmpv changed on was
originally without the fbo fix and on rebasing i forgot to change the
variable to the proper one, basically deactivating the fix.
it's possible to get a function pointer through a closure after all in
swift. remove the GL dummy function from the c header and do it in the
swift code instead.
The stdatomic emulation adds "_" to each variable used inside the
macros, to avoid that compilers print -Wshadow warnings for identifiers
that are also used in surrounding code. Do this more consistently,
because new warnings have been showing up.
the title bar is now within the window bounds instead of outside. same
as QuickTime Player. it supports several standard styles, two dark and
two light ones. additionally we have properly rounded corners now and
the borderless window also has the proper window shadow.
Also make the earliest supported macOS version 10.10.
Fixes#4789, #3944
in certain circumstances the returned fbo for drawing is 0, but that
fbo is solely used internally by the CAOpenGLLayer for its drawing and
should never be used. in that case we fallback to 1 or the last used fbo
instead if it was not 0.
Fixes#5546
Usable for uniquely identifying mpv instances from
subprocesses, controlling mpv with AppleScript, ...
Adds a new mp_getpid() wrapper for cross-platform reasons.
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
this adds the standard menu bar items Services, Hide Others, Show All
and Close, as suggested by Apple's HIG.
https://developer.apple.com/macos/human-interface-guidelines/menus/menu-bar-menus/#app-menu
- Services are useful to add custom actions and shortcuts via the
System Preferences to mpv
- Close is important since the menu bar can open secondary windows, like
About or the Open dialogue. those couldn't be closed with the standard
system shortcut before. this is now possible.
NSFileHandlingPanelOKButton is deprecated with macOS 10.13, but the
replacement NSModalResponseOK is not available on 10.8 and earlier.
added a declaration for 10.8 and earlier since i only officially
dropped support for 10.7 and earlier. this is untested.
Dudemanguy
Kacper Michajłow
rcombs
NRK
m154k1
Christoph Heinrich
Thomas Weißschuh
Mia Herkt
Leo Izen
Cœur
Aman Karmani
sfan5
Niklas Haas
Avi Halachmi (:avih)
Martin Tournoij
Evgeny Zinoviev
der richter
Guido Cella
Shreesh Adiga
wm4
Philip Langdale
James Ross-Gowan
RealDolos
Jan Beich
Murray Campbell
Chris Down
James Hilliard
Rodger Combs
Jan Ekström
Ken
Anton Kindestam
Tom Yan
Michael Hoang