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.
Now macosx_menubar.m and mpv.rc (win32) use the same copyright string.
(This is a bit roundabout, because mpv.rc can't use C constants. Also
the C code wants to avoid rebuilding real source files if only version.h
changed, so only version.c includes version.h.)
By default the CreateProcess changes the mouse cursor to
IDC_APPSTARTING. The new flag added to STARTUPINFOEXW prevents
changing the cursor from default arrow on creating a new process.
Calling do_deactivate_getch2 before joining the terminal thread could
lead to breakage if the terminal thread got another interation in before
it was signaled to stop.
This also addresses a minor error with the order in which things are
initialized - getch2_poll would previously call tcgetpgrp(tty_in) before
tty_in was initialized, which did not lead to broken behavior, but was
not correct either.
Fixes#5195
This implements a poll-compatible interface, backed by select on macOS,
suitable for polling on device files - which are not supported by
macOS's implementation of poll. This is a (long-standing) bug in macOS,
so hopefully we can eventually remove this shim.
POSIX permits select() to modify the timeout, which can happen on the
Linux implementation. This can reset the timeout, which spins this into
a tight loop. A timeout isn't necessary in the first place, so just use
NULL instead.
stdatomic.h defines no atomic_float typedef. We can't just use _Atomic
unconditionally, because we support compilers without C11 atomics. So
just create a custom atomic_float typedef in the wrapper, which uses
_Atomic in the C11 code path.
This sliences some warnings about unused values and statements with no
effect, but it also fixes a logic error with freelocale(), since
previously it would not work as expected when used in the body of an if
statement without braces.
Uses real functions, because with macros, I don't think there is a way
to silence the "statement with no effect" warnings in the case where the
return value of uselocale() is ignored.
As for replacing the these functions with working implementations, I
don't think this is possible for mpv's use-case, since MSVCRT does not
support UTF-8 locales, or any locale with multibyte characters that are
three or more bytes long. See:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/setlocale-wsetlocale
Directory-opening never worked on Windows because MSVCRT's open()
doesn't open directories and its fstat() doesn't recognise directory
handles. These are just MSVCRT restrictions, and the Windows API itself
has no problem with opening directories as file objects, so reimplement
mpv's mp_open and mp_stat to use the Windows API directly. This should
fix directory playback.
This also populates the st_dev and st_ino fields of struct stat, so
filesystem loop checking in demux_playlist.c should now work on Windows.
Fixes#4711
with the previous commit we removed the ability of loading the standard
shell environment. this exact behaviour can only be re-added by either
invoking the standard shell in a background process and reading it's
environment vars or by manually reading all the various shell configs.
both ways are kinda dirty and the former was already rejected before.
for now we will just add some commonly used paths, when started from the
bundle, so it can find the binaries used by mpv again. for example the
youtube-dl one for our youtube-dl hook.
Apple slightly changed the App bundle mechanism which broke wrapper
scripts that invoke the actual binary. it caused the bundle to always
open a new instance of mpv instead of reusing the currently running one.
just removing the wrapper script would lead to several regressions, so
it was replaced with a symlink to the bundle binary. detection if mpv
was started from the bundle was replaced by comparing the execution name
of the binary, eg the name of the symlink "mpv-bundle". additionally,
because we load a standard config from the Resources folder of the
bundle again, we prevent that config from being loaded if mpv wasn't
started via the bundle. the psn argument has to be removed manually
again.
the ability of loading your standard shell environment has been removed
with the wrapper. a substitution will be added with another commit. as a
side effect this fixes an issues when zsh was used with common NodeJS
configuration scripts.
Fixes#4926#4866
This fixes >2GiB files with at least API level 21.
See: https://android.googlesource.com/platform/bionic/+/master/docs/32-bit-abi.md
for the gritty details.
* Based on libavformat's things, except we do not care about API
versions or NDKs without unistd.h, which contains all sorts of
things that we utilize.
* Redefines lseek to always point to the 64bit version.
* Redefines fseeko to always point towards an inlined static
implementation that utilizes the 64bit version of lseek underneath.
other Apps do the same as mpv and tap into the global event chain.
events that are handled are not being propagated down the event chain.
that can lead to mpv not getting any media key events anymore when they
are held back by other Apps. we will just move mpv back to the top of
the event list when mpv is refocused and is not at the top of the list
any more.
Fixes#4834
98f5579 added a safeguard for the deactivation of the automatic tab bar
but it still needs a compile time guard. add a forward declaration for
the setAllowsAutomaticWindowTabbing method of NSWindow.
Fixes#4783
As pointed out by uau on IRC, the pointer to info is still used outside
of the lock. An extremely small race condition window, but still a race
condition.
The struct m_thread_info pointer is part of an array, that will be
reallocated if another thread is created while the run_thread is just
being called. In previous versions of this code, the pointer was stable
(as long as the thread existed), so this was overlooked.
Fixes#4770. I'm not sure why this triggers it so reliably, while it
remained undetected otherwise.
This currently is only limited to Android. Its stdlib contains the
things that mpv's POSIX check checks for, but unfortunately not
glob().
This fixes Android compilation broken in 70a70b9da .
This was attempted before in fc9695e63b, but it was reverted in
1b7ce759b1 because it caused conflicts with other software watching
the same keys (See #2041.) It seems like some PCs ship with OEM software
that watches the volume keys without consuming key events and this
causes them to be handled twice, once by mpv and once by the other
software.
In order to prevent conflicts like this, use the WM_APPCOMMAND message
to handle media keys. Returning TRUE from the WM_APPCOMMAND handler
should indicate to the operating system that we consumed the key event
and it should not be propogated to the shell. Also, we now only listen
for keys that are directly related to multimedia playback (eg. the
APPCOMMAND_MEDIA_* keys.) Keys like APPCOMMAND_VOLUME_* are ignored, so
they can be handled by the shell, or by other mixer software.
The count parameter refers to the number of wide-characters to write to
the buffer (including the terminating NUL character, which is always
added,) not the number of bytes. See C99 7.24.2.3 or
https://msdn.microsoft.com/en-us/library/ybk95axf.aspx
While this is perfectly OK on Unix, it causes annoying valgrind
warnings, and might be otherwise confusing to others.
On Windows, the runtime can actually abort the process if this is
called.
push.c part taken from a patch by Pedro Pombeiro.
In a bunch of cases, we emulate highly platform specific APIs on a
higher level across all OSes, such as IPC, terminal, subprocess
handling, and more. We have source files for each OS, and they implement
all the same mpv internal API.
Selecting which source file to use on an OS can be tricky, because there
is partially overlapping and emulated APIs (consider Cygwin on Windows).
Add a pick_first_matching_dep() function to make this slightly easier
and more structured.
Also add dummy backends in some cases, to deal with APIs not being
available.
Clarify the Windows dependency identifiers, as these are the most
confusing.
This reverts commit 2e81698d28.
Seems like this was a patch applied from someone who can't agree to LGPL
relicensing (see previous commit), with the author field not properly
set.
This is not so important anyway, so just revert it.
Don't use __thread, which requires heavy runtime in some cases (such as
MinGW-w64, at least under some configurations, forcing you to link to
its pthread runtime DLL).
The pthread_t struct was needed over a simple thread ID, because
pthread_join() needed to access some sort of context from pthread_t.
Further, pthread_exit() and pthread_detach() need the context of the
current thread, for which we relied on TLS.
Replace these uses by a global thread array. This includes all threads
created by the thread wrapper. Hopefully the number of threads created
by mpv is low (say, below 20), and threads are not that often created or
destroyed. So just keeping them in an array with linear search lookup
should be reasonable.
All authors of the current code have agreed.
The code probably originates from a software named GySmail (as the
copyright header indicates). As far as I can tell, it was written by
Arpi (who has agreed), possibly with unknown co-authors. This is most
likely OK, as none of the original code is around anymore anyway. I
could not find a working download of GySmail, that actually contained
the original getch2.c code.
This also has a wild history of random people adding ifdef guards to
control ioctl() vs. tcgetattr() calls. (See for example 2b1310abba4c1.)
Later, the ioctl() was removed in favor of the POSIX tcgetattr(), and
the ifdeffery was removed. So these people were not contacted.
All authors have agreed.
mpv.exe.manifest probably can't have a copyright header, so it doesn't.
These files don't add license info to the executables. And of course the
executable license is still GPL.
Windows, as of the Creators Update, finally has a sane API for giving a
name to a thread that can be used by debuggers. This is similar to
pthread_setname_np on Linux and some Unixes. Expose it in the pthread
wrapper and use it for mpthread_set_name().
This didn't have a header and this was implied LGPL, but this was not
entirely correct. It turns out the printf attribute code was leaked in
from talloc, which is "LGPL v3 or later". talloc was added to the
mplayer2 code base in 27a30e310e. This remaining code was an oversight.
Since we want to reduce LGPL v3 code, replace this code with the one
from ta/ta.h. This code was explicitly written newly to get rid of
talloc and its license in 0933f12d28.
All authors have agreed, with the following exceptions:
e68d7f6858: wight wasn't asked (I think...), but even if he modified the
patch he applied, all code added by it was removed again later.
cb7768f9bb: nick could not be reached, but the declarations he added as
well as the full timer.c file were deleted again in cff81fe498 and
f800a42e45 (did it really take 6 years to remove unused declarations?).
ffaf4af230: it looks like this person wasn't contacted, but the code
added was removed again in f544bcf105.
There is explicit code to handle the libmpv case, but it expects that
a dispatch queue is running. This is not necessarily the case. E.g.
edit the simple.c mpv example not to do any playback and to destroy
the mpv handle immediately. It will freeze on exit, because nothing
will release the mpv_handle.
I'm not sure how this should be fixed, so disable it for now in
library mode.
The license text refers a "above copyright notice", so I guess it'd be
good to actually provide such a notice.
Add the license to some files that were missing it (since in theory, our
Copyright file says that such files are LGPL by default).
Remove the questionable remarks about the license in the client API.
when building with a deployment target older than an SDK with Touch Bar
support we still tried to access the TouchBar, since the compile time
checks are positive. to prevent this we add two runtime checks.
a small logic error in 063ca8f broke the filtering of the menu bar item
key shortcuts. they where called several times per event because the
propagation wasn't stopped properly.
for a reason i can just assume some key events can vanish from the
event chain and mpv seems unresponsive.
after quite some testing i could confirm that the events are present at
the first entry point of the event chain, the sendEvent method of the
Application, and that they vanish at a point afterwards. now we use
that entry point to grab keyDown and keyUp events. we also stop
propagating those key events to prevent the no key input' error sound.
if we ever need the key events somewhere down the event chain we need
to start propagating them again. though this is not necessary currently.
fffab30 introduced a small regression where the cursor couldn't be
unhidden after refocusing. the problem is that no mouseUp event was
reported in our events_view. work around this with a separate event
monitor. this also fixes another regression when the window is being
dragged from the title bar.
#4174
we have two problems here. first when mpv is started from the bundle it
uses its own environment variables and possibly can't find for example
the youtube-dl binary for our youtube-dl hook. second we couldn't
reliable determine when mpv was started from the bundle, which led to
the pseudo-gui usage even when the binary was invoked from a shell.
to prevent this we will wrap the bundle binary with a shell script,
which will only be called when we start mpv from the bundle. this way
we can get the same environment variables, like $PATH, for our bundle
and additional we can set the pseudo-gui only when started through this
script. it is also possible to detect the bundle usage properly and
accurately through the usage of another environment var.
Fixes#2061
quitting mpv from the Dock's context menu leaves the shell in a bad
state where you can't see your input any more and other weirdnesses.
in a big refactor (afdc9c4) the method to handle this case was actually
copied over but the the code to register the event itself was removed or
forgotten by accident, leaving some lines of dead code. i re-added the
event and slightly adjusted the function. the function was slightly
changed so the head of it is consistent with our other events and it is
associated with this commit and functionality in the future.
Using these was a temporary solution while some compilers implemented
the underlying atomic mechanisms, but not the C11 language parts (or
that's what I guess). Not really useful for us anymore. Also, there is
the slight risk of having subtly incorrect semantics by using
potentially changing compiler internals and such.
This replaces the old backend that exclusively used EGL windowing with
one that can also use ANGLE's ability to render to directly to a
texture. The advantage of this is that it allows mpv to create the swap
chain itself and this allows mpv to use a flip-mode swap chain on a HWND
(which avoids problems with DirectComposition) and to use a longer swap
chain that has six backbuffers by default (which reportedly fixes
problems with rendering 24fps video on 24Hz monitors.)
Also, "screenshot window" should now work on DXGI 1.2 and up (Windows 8
and up.)
See: https://msdn.microsoft.com/en-us/library/windows/desktop/dd743946.aspx
Microsoft example code often uses a SAFE_RELEASE macro like the one in
the above link. This makes it easier to avoid errors when releasing COM
interfaces. It also reduces noise in COM-heavy code.
ao_wasapi.h also had a macro called SAFE_RELEASE, though unlike the
version above, its SAFE_RELEASE macro accepted a second parameter which
allowed it to destroy arbitrary objects other than just COM interfaces.
This renames ao_wasapi's SAFE_RELEASE to SAFE_DESTROY, which should more
accurately reflect what it does and prevent confusion with the Microsoft
version.
The correctness of the stdatomic.h emulation via the __sync builtins is
questionable, and we've been relying on exact stdatomic semantics for a
while, so just get rid of it. Compilers which support __sync but not
stdatomic.h will use to the slow mutex fallback.
Not sure about the __atomic builtins. It doesn't seem to harm either, so
leave it for now.
this replaces the old fullscreen with the native
macOS fullscreen. additional the
--fs-black-out-screens was removed since the new
API doesn't support it in a way the old one did.
it can possibly be re-added if done manually.
Fixes#2857#3272#1352#2062#3864
When dropping a file on mpv, either on the window
or the App bundle icon, while holding the shift
key the dropped files will be appended to the
playlist.
Fixes#2166
Remove 'Quit mpv & remember playback position'
from the menu because it conflicts with the global
logout shortcut. add separator between 'Hide' and
'Quit' for consistency with other Apps.
also rename the 'Movie' menu to 'Video'. it's a
bit more generic.
Fixes#3865
- win32-console-wrapper.c was inconsistently using the explicit Unicode
versions of some Windows API functions and structures.
- vo.c should use llabs for int64_t, since long is 32-bit on Windows.
- vo_direct3d.c had a potential use of an uninitialized variable if it
took the first goto error_exit.
This fixes the build in mingw-w64/Clang on MSYS2. It also disables the
use of gnu_printf in Clang, which was what was causing most of the
warnings. The Clang-compiled mpv binary appears to work, but there are
no guarantees yet, since until now mpv has only been tested with
mingw-w64/GCC on Windows.
Fixes#3800
Keyboard input in the console still isn't quite as flexible as it is in
the video window. Ctrl+<letter> and Ctrl+LEFT/RIGHT work, but
Ctrl+Alt+<letter> and Ctrl+<number> do not. Also, in the new Windows 10
console, a bunch of Ctrl keystrokes including Ctrl+UP/DOWN are handled
by the console window and not passed to the application.
Unlike in w32_common.c, we can't really translate keyboaard input
ourselves because the keyboard layout of the console window (in
conhost.exe) doesn't necessarily match the keyboard layout of mpv's
console input thread, however, using ToUnicode as a fallback when the
console doesn't return a unicode value could be a possible future
improvement.
Fixes#3625
The original version of this code in getch2-win.c fetched 128 console
events at once. This was probably to maximize the chance of getting a
key event if there were other events in the buffer, because it returned
the value of the first key event it found and ignored all others. Since
that code was written, it has been modified to receive console input in
an event-based way using an input thread, so it is probably not
necessary to fetch so many events at once any more. Also, I'm not sure
what it would have done if there were more than 128 events in the
console input buffer. It's possible that fetching multiple events at a
time also had performance advantages, but I can't find any other
programs that do this. Even libuv just fetches one console event at a
time.
Change read_input() to fetch only one event at a time and to consume all
available events before returning to WaitForMultipleObjects. Also remove
some outdated comments and pass the console handle through to the input
thread instead of calling GetStdHandle multiple times (I think this is
theoretically more correct because it is possible for the handles
returned by GetStdHandle to be changed by other threads.)
We always want to use __declspec(selectany) to declare GUIDs, but
manually including <initguid.h> in every file that used GUIDs was
error-prone. Since all <initguid.h> does is define INITGUID and include
<guiddef.h>, we can remove all references to <initguid.h> and just
compile with -DINITGUID to get the same effect.
Also, this partially reverts 622bcb0 by re-adding libuuid.a to the
build, since apparently some GUIDs (such as GUID_NULL) are not declared
in the source file, even when INITGUID is set.
Seems like this confused users quite often.
Instead of --profile=pseudo-gui, --player-operation-mode=pseudo-gui now
has to be used to invoke pseudo GUI mode. The old way still works, and
still behaves in the old way.
So client API users don't have to care about whether to set this before
or after mpv_initialize().
We still don't enable terminal at any point before mpv_initialize(),
because reasons.
This also subtly changes some behavior how terminal options are applied
while parsing. This essentially reverts the behavior as it was reported
in issue #2588. Originally, I was hoping to get rid of the pre-parse
option pass, but it seems this is absolutely not possible due to the way
config and command line parsing are entangled. Command line options take
priority over configfile options, so they have to be applied later - but
we also want to apply logging and terminal options as specified on the
command-line, but _before_ parsing the config files. It has to be this
way to see config file error messages on the terminal, or to hide them
if --no-terminal is used. libmpv considerations also factor into this.
Until now, the terminal thread always sent a quit command if the
terminal thread was torn down (whether it happened via terminal_uninit()
or a quit signal). This is not so good if we want to enable toggling
terminal use at runtime, since disabling the terminal would always make
the player quit. So we want terminal_uninit() not to send quit.
This can be easily fixed by using the "death byte" sent to the pipe used
for thread tear-down to indicate whether it was caused by a signal or
terminal_uninit().
This time it's emulation that's supposed to work (not just dummied out).
Unlike the previous emulation, no mpv code has to be disabled, and
everything should work (albeit possibly a bit slowly). On the other
hand, it's not possible to implement this kind of emulation without
compiler support. We use GNU statement expressions and __typeof__ in
this case.
This code is inactive if stdatomic.h is available.
Always require them, instead of just for some components which have hard
requirements on correct atomic semantics. They should be widely
available, and are supported by all recent gcc and clang compiler
versions. We even have the fallbacks builtins, which should keep this
working on very old gcc releases.
In particular, w32_common.c recently added a hard requirement on
atomics, but checking this properly in the build system would have been
messy. This commit makes sure it always works.
The fallback where weak atomic semantics are always fine is in theory
rather questionable as well.
Old-style commands using _ as separator (e.g. show_progress) were still
used in some places, including documentation and configuration files.
This commit updates all such instances to the new style (show-progress)
so that commands are easier to find in the manual.
For some reason, the lack of version info was preventing mpv from
appearing in the Default Programs dialog. Re-add it, but don't set the
string version numbers from version.h, because that's what was causing
trouble when the version info was removed. Like the binary version
numbers, these are now hardcoded to 2.0.0.0, which probably doesn't
matter.
The new version info block is also slightly different to the old one. It
fills out all the binary VERSIONINFO fields and makes better use of
macros. It also removes the \000 line terminators from the string
version info, since as far as I can tell, this was just cargo-culting
for an old broken version of the Microsoft resource compiler, and
binutils' windres terminates the strings properly without them.
For clang, it's enough to just put (void) around usages we are
intentionally ignoring the result of.
Since GCC does not seem to want to respect this decision, we are forced
to disable the warning globally.
SRW locks are available since Windows Vista. They work essentially like
Linux futexes. In particular, they can be statically initialized, and do
not require deinitialization. This makes them ideal for implementing
PTHREAD_MUTEX_INITIALIZER.
We still need CRITICAL_SECTION for recursive mutexes.
This file was rewritten from scratch in 0cef033, so it should be okay.
As mentioned in #730, it's a complete rewrite referencing only MSDN and
POSIX, rather than the original code.
This is useful in particular for GetLastError, unfortunately, it's stil pretty
dumb with regards to WASAPI or D3D specific errors, so keep the
hresult_to_string switch.
This covers source files which were added in mplayer2 and mpv times
only, and where all code is covered by LGPL relicensing agreements.
There are probably more files to which this applies, but I'm being
conservative here.
A file named ao_sdl.c exists in MPlayer too, but the mpv one is a
complete rewrite, and was added some time after the original ao_sdl.c
was removed. The same applies to vo_sdl.c, for which the SDL2 API is
radically different in addition (MPlayer supports SDL 1.2 only).
common.c contains only code written by me. But common.h is a strange
case: although it originally was named mp_common.h and exists in MPlayer
too, by now it contains only definitions written by uau and me. The
exceptions are the CONTROL_ defines - thus not changing the license of
common.h yet.
codec_tags.c contained once large tables generated from MPlayer's
codecs.conf, but all of these tables were removed.
From demux_playlist.c I'm removing a code fragment from someone who was
not asked; this probably could be done later (see commit 15dccc37).
misc.c is a bit complicated to reason about (it was split off mplayer.c
and thus contains random functions out of this file), but actually all
functions have been added post-MPlayer. Except get_relative_time(),
which was written by uau, but looks similar to 3 different versions of
something similar in each of the Unix/win32/OSX timer source files. I'm
not sure what that means in regards to copyright, so I've just moved it
into another still-GPL source file for now.
screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but
they're all gone.
Note that hresult_to_str() (coming from wasapi_explain_err()) is mostly
wasapi-specific, but since HRESULT error codes are unique, it can be
extended for any other use.
Windows definitely supports Unix-style fd inheritance. This mostly
worked when launched from mpv.exe, though mpv should change the file
mode to O_BINARY. When launched from mpv.com, the wrapper must pass the
list of handles (stored in the undocumented lpReserved2 and cbReserved2
fields) to the mpv process.
CSIDLs have been deprecated in Windows Vista and are not recommended for
use in new code. They have been replaced with Known Folder IDs, which
are pretty much the same thing, except they use GUIDs.
reopen_console_handle() was never properly tested because mpv overrides
printf in most source files. Turns out that when there's no console on
startup, the CRT sets the fds of stdout and stderr to -2, so the old
method of using dup2 to manipulate these fds didn't work. As far as I
can tell, the only way to give stdout and stderr valid fds is to use
freopen, so this uses freopen to set them both to the console output.
This also uses dup2 to change STDOUT_FILENO and STDERR_FILENO, so low-
level functions like isatty still work.
Note that this means fileno(stdout) != STDOUT_FILENO. I don't think this
will cause any problems.
This should fix MPV_LEAK_REPORT on the Windows console.
This puts in place the machinery to merely append dropped file to the playlist
instead of replacing the existing playlist. In this commit, all front-ends
set this to false preserving the existing behaviour.
The waf build system generates this already. No point in redoing it in
the header file.
The legacy build system (which we really should drop) didn't; fix it.
This was originally done for zsh; but zsh can manage the terminal state
correctly when foregrounding/backgrounding applications if you enable it
with "ttyctl -f". So I see no reason to wake up the mpv process once
every second anymore.
Revert "win32: more wchar_t -> WCHAR replacements"
Revert "win32: replace wchar_t with WCHAR"
Doing a "partial" port of this makes no sense anymore from my
perspective. Revert the changes, as they're confusing without
context, maintenance, and progress. These changes were a bit
premature anyway, and might actually cause other issues
(locale neutrality etc. as it was pointed out).
This was essentially missing from commit 0b52ac8a.
Since L"..." string literals have the type wchar_t[], we can't use them
for UTF-16 strings. Use C11 u"..." string literals instead. These have
the type char16_t[], but we simply assume char16_t is the same
underlying type as WCHAR. In practice, they're both unsigned short.
For this reason use -std=c11 on Windows. Since Windows is a "special"
environment (we require either MinGW or Cygwin), we don't need to worry
too much about compiler compatibility.
WCHAR is more portable. While at least MinGW, Cygwin, and MSVC actually
use 16 bit wchar_t, Midipix will have 32 bit wchar_t. In that context,
using WCHAR instead is more portable.
This affects only non-MinGW parts, so not all uses of wchar_t need to
be changed. For example, terminal-win.c won't be used on Midipix at
all. (Most of io.c won't either, so the search & replace here is more
than necessary, but also not harmful.)
(Midipix is not useable yet, so this is just preparation.)
We used double-checked locking on pthread_mutex_t.requires_init in order
to lazily initialize static mutexes (since CRITICAL_SECTION has no
native way to do this). This was kind of unclean: we relied on MSVC
semantics for volatile (which apparently means all accesses are weakly
atomic), which is not such a good idea since mpv can't even be compiled
with MSVC.
Since it's too much of a pain to get weak atomics, just use INIT_ONCE
for initializing the CRITICAL_SECTION. Microsoft most likely implemented
this in an extremely efficient way. Essentially, it provides a mechanism
for correct double-checked locking without having to deal with the
tricky details. We still use an extra flag to avoid calling it at all
for normal locks.
(To get weak atomics, we could have used stdatomic.h, which modern MinGW
provides just fine. But I don't want this wrapper depend on MinGW
specifics if possible.)
See manpage additions.
The main reason for adding this is that we can't guess whether the user
wants his config in his Windows profile or not. The user basically has
to tell mpv what should be done, and the "portable_config" directory
does this implicitly.
Fixes#2042 (approximately).
It's conceivable that the OS time source is subject to clock changes.
The time could jump back to before when mpv was started, which would
cause mp_time_us() to return values smaller than 1. This is unexpected
by the code and could trigger assertions. If there's no monotonic time
source there's not much we can do anyway, so just sanitize the return
value. It will cause strange behavior until the "lost" time offset has
passed, but if you make such huge changes to the system clock while
everything is running, you're asking for trouble anyway.
(Normally we try to get a monotonic time source, though. This problem
sometimes happened on Windows when compiled without winpthreads, when
the code was falling back to gettimeofday(). This was already fixed by
always using another method.)
clock_gettime is implemented in winpthreads, so it's unavailable when
mpv is compiled with its internal pthreads implementation. This makes
mp_raw_time_us fall back to gettimeofday(), which can cause an assert
failure in mp_add_timeout() when the system clock is changed. Use
QueryPerformanceCounter instead.
The clock_gettime(CLOCK_MONOTONIC) implementation in winpthreads uses
QueryPerformanceCounter anyway, so there shouldn't be any change in
behaviour.
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.
Makes all of overlay_add work on windows/mingw.
Since we now don't explicitly check for mmap() anymore (it's always
present), this also requires us to make af_export.c compile, but I
haven't tested it.
I noticed that the IPC code does not use MSG_NOSIGNAL or SO_NOSIGPIPE.
The former is "only" POSIX 2008 and also requires switching to sendto(),
while the latter is even less portable.
Not going to bother with this obsolete 80ies crap, just block SIGPIPE,
and instruct client API users to do the same.
This fixes using the mpv:// custom protocol on Yosemite were apparently
we receive an url which is automatically urlencoded by the system.
/cc mpv-player/stable
The subprocess code was already split into fairly general functions,
separate from the Lua code. It's getting pretty big though, especially
the Windows-specific parts, so move it into its own files.
