| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
it's unused and added automatically. we need to guard the deactivation
since it's a 10.12+ feature.
|
| |
|
|
| |
silence build warnings, clean up code style and remove unused code.
|
| |
|
|
|
| |
make the menu bar look more like a standard macOS menu bar, with all the
standard menu items like About, Help, Open, etc.
|
| | |
|
| |
|
|
|
|
|
|
| |
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 fc9695e63b5b, but it was reverted in
1b7ce759b1f4 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
|
| | |
|
| |
|
|
| |
This only ever waits on four handles at most anyway.
|
| |
|
|
|
|
|
|
| |
libmpv only. Some things are still missing.
Heavily reworked.
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
POSIX requires glob(), so no need to check for it. Together with the
fact that we can emulate glob() on Windows, glob() is always available.
|
| | |
|
| |
|
|
| |
All authors of the current code have agreed.
|
| |
|
|
| |
All authors agreed.
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit 2e81698d2809836d4cd7f754a78598e7bdf96c0b.
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 27a30e310e1. 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 0933f12d28e.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Might fix #4315.
|
| |
|
|
| |
_wgetcwd is apparently not available in all runtimes. Well, whatever.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Fixes #4204
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
What kind of bullshit forces you to do this every year anyway.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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
|
wm4
Akemi
Jan Ekström
James Ross-Gowan
Pedro Pombeiro
James Ross-Gowan