We want to distinguish actual errors, and just aborting the program
intentionally.
Also be a bit more careful with handling the wait() exit status: do not
called WEXITSTATUS() without checking WIFEXITED() first.
mpv usually sets the terminal to non-canonical mode (which in particular
disables line buffering). But the old mode is restored if the process is
not foregrounded. This is supposed to make mpv behave nicer when it is
backgrounded.
getch2_poll() enables canonical mode. Unfortunately, this was only
called after the poll timeout elapsed, so non-canonical mode is first
enabled after about a second after program start. Fix this by moving the
poll call before the timeout.
(As far as we're aware, there's no event-based way to determine when the
FD's process group changes, thus we're polling.)
This reverts commit fc9695e63b.
Users were complaining that both mpv and something else (what? I don't
know) respond to some multimedia keys, such as volume change.
While all functions of input_ctx are inherently thread-safe, access to
the _inputContext field itself is not. It could be unset any time by
cocoa_set_input_context(). So even trivial input_ctx calls must be under
a lock, so that the input_ctx can not be destroyed while the function
call is "starting". (Even a function call in progress wouldn't be fine,
because mp_input_uninit() requires the caller to "own" the object, i.e.
no other threads can access it at this point.)
This was called for formal reasons at best. The way it does this is
somewhat dangerous, because if libmpv is unloaded as DLL, this would
attempt to call a dangling function pointer.
(No, we don't want an extra DllMain entrypoint just for win32.)
There is not much of a reason to have these wrappers around. Use POSIX
standard functions directly, and use a separate utility function to take
care of the timespec calculations. (Course POSIX for using this weird
format for time values.)
As usual, we prefer plain C11 names and semantics, and have to emulate
them if C11 atomics are not available.
For the non-atomic fallback (which is just there to make code compile in
situations the atomic property is not overly important), we require a
gross hack to make the generic macros work without using compiler-
specific extensions.
OpenSSL and GnuTLS are still causing this problem (although FFmpeg could
be blamed as well - but not really). In particular, it was happening to
libmpv users and in cases the pseudo-gui profile is used. This was
because all signal handling is in the terminal code, so if terminal is
disabled, it won't be set. This was obviously a questionable shortcut.
Avoid further problems by always blocking the signal. This is done even
for libmpv, despite our policy of not messing with global state.
Explicitly document this in the libmpv docs. It turns out that a version
bump to 1.17 was forgotten for the addition of MPV_FORMAT_BYTE_ARRAY, so
document that change as part of 1.16.
It's useless, and creates a bogus warning in subprocess-posix.c.
Since I don't know which compilers might have it by default, just change
it to -Wno-redundant-decls.
This was a mistake, it should definitely be using the device namespace
rather than the file namespace. As it says in the docs, all pipe names
must start with \\.\pipe\
And split the Cocoa and Unix cases. Simplify the Cocoa case slightly by
calling mpv_main directly, instead of passing a function pointer. Also
add a comment explaining why Cocoa needs a special case at all.
This unbreaks compiling command line player and libmpv at the same
time. The problem was that doing so silently disabled the OSX
application thing - but the command line player can not use the
vo_opengl Cocoa backend without it.
The OSX application code is basically dead in libmpv, but it's not
that much code anyway.
If you want a mpv binary that does not create an OSX application
singleton (and creates a menu etc.), you must disable cocoa
completely, as cocoa can't be used anyway in this case.
win32 has a special function for this.
I'm not sure about OSX - it seems ~/Desktop can be hardcoded, and the
OSX GUI actually localizes the _displayed_ path in its UI.
For Unix, there is not much to be done, or is there.
Somewhat less ifdeffery, higher flexibility. Now there are 3 separate
config file resolvers for 3 platforms (unix, win, osx), and they can
still interact with each other somewhat. For example, OSX for now uses
most of Unix, but adds the OSX bundle path.
This can be extended to resolve very specific platform paths, such as
location of the desktop.
Most of the Unix specific code moves to path-unix.c.
The behavior should be the same - if not, it is likely a bug.
It appears youtube-dl sometimes asks for a password on stdin. This won't
work, because mpv already uses the terminal.
(I wonder if this could be simpler, like simply closing FD 0, but let's
not. The FD would be reused by something random.)
Previously, mpv.exe used the --terminal option to decide whether to
attach to the parent process's console, which made it impossible to tell
whether mpv would attach to the console before the config files were
parsed. Instead, make mpv always attach to the console when launched
from the console wrapper (mpv.com) and never attach otherwise. This will
be useful for the next commit, which will use the presence of the
console to decide whether to use the pseudo-gui profile.
This change should also be an improvement in behavior. The old code
would attach to the parent process's console, regardless of whether it
was mpv.com or some other program like cmd.exe. This could be confusing,
since mpv.exe is marked as a Windows GUI program and shouldn't write
text to its parent process's console when launched directly. (See #768.)
Visual Studio does something similar with its devenv.com wrapper.
devenv.exe only attaches to the console when launched from devenv.com.
Add a platform-specific entry-point for Windows. This will allow some
platform-specific initialization to be added without the need for ugly
ifdeffery in main.c.
As an immediate advantage, mpv can now use a unicode entry-point and
convert the command line arguments to UTF-8 before passing them to
mpv_main, so osdep_preinit can be simplified a little bit.
Commit e920a00eb assumed that terminate_cocoa_application() actually
would exit. But apparently that is not always the case; e.g. mpv --help
will just hang. The old code had a dummy exit(0), which was apparently
actually called. Fix by explicitly exiting if mpv_main() returns and
terminate_cocoa_application() does nothing.
This allows getting the log at all with --no-terminal and without having
to retrieve log messages manually with the client API. The log level is
hardcoded to -v. A higher log level would lead to too much log output
(huge file sizes and latency issues due to waiting on the disk), and
isn't too useful in general anyway. For debugging, the terminal can be
used instead.
If the program name isn't quoted and the .exe it refers to isn't found,
CreateProcess will add the program arguments to the program name and
continue searching, so for "program arg1 arg2", CreateProcess would try
"program.exe", "program arg1.exe", then "program arg1 arg2.exe". This
behaviour is weird and not really desirable, so prevent it by always
quoting the program name.
When quoting argv[0], escape sequences shouldn't be used. msvcrt, .NET
and CommandLineToArgvW all treat argv[0] literally and end it on the
trailing quote, without processing escape sequences.
The function terminal_in_background() reports whether the player was
backgrounded. In this case, we don't want to annoy the user by still
printing the status to stderr. If no terminal interaction is assumed,
this mechanism is disabled, and stderr is always used. The read_terminal
variable signals this case.
Oddly, just redirecting stderr will disable output to stderr, because
the background check with tcgetpgrp() is done on stderr, but
read_terminal is still true (because that one depends on stdin and
stdout).
Explicitly disable this mechanism if --no-input-terminal is used by
setting read_terminal to true only if terminal input is actually
initialized.
Our own code was introduced when FFmpeg didn't provide this API (or
maybe didn't even have a way to determine the CPU count). But now,
av_cpu_count() is available for all FFmpeg/Libav versions we support,
and there's no reason to have our own code.
libavutil's code seems to be slightly more sophisticated than our's, and
it's possible that the detected CPU count is different on some platforms
after this change.
If the stdout or stderr write callback is NULL, then don't redirect this
stream. Preparation for the next commit.
Not sure what to do on Windows; it seems STARTUPINFO doesn't allow
redirection only one of them. So just let them write nothing. For our
intended use-case (next commit), this is probably sensible.
wm4
Marcin Kurczewski
Michael Vetter
James Ross-Gowan
Stefano Pigozzi
Kevin Mitchell
Hiltjo Posthuma