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.
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
