Currently, all fopen uses in mpv do not set cloexec flag, resulting
in fd leak whenever mpv creates a process.
This makes mpv use mp_fopen on all platforms, and always set O_CLOEXEC
on the opened fd. This is required because the "e" flag for fopen is
nonstandard and UB in C11, and unsupported on macOS.
This had been done similarly in other projects. e.g.
https://gitlab.com/graphviz/graphviz/-/merge_requests/3797
The previous commit to dynamically load VapourSynth R74 would fail to work
for VapourSynth R73 and before on Linux due to load mode RTLD_LOCAL. To
make it work on all VapourSynth version, switch to use RTLD_GLOBAL mode.
This unifies --drag-and-drop handling to a single place. All platforms
currently only support normal drop (mapped to "replace") and shift click
drop (mapped to "append").
The previous commit to dynamically load VapourSynth R74 would fail to work
for VapourSynth R73 and before on Linux due to load mode RTLD_LOCAL. To
make it work on all VapourSynth version, switch to use RTLD_GLOBAL mode.
Add library handle closing in drv_vss_uninit for completeness.
VapourSynth R74 changed two things relevant to mpv build process:
1) VSScript no longer has static library to link to, and only support runtime loading.
This is reflected on the new VSScript example in VapourSynth SDK.
2) The VSScript library name is changed from libvapoursynth-script to libvsscript for Linux
and MacOS.
The new VSScript initialization code is modified from their SDK example to utilize
mpv's mechanisms. Build dependency is also updated accordingly.
The dynamic allocation of this strings is completelly pointless. It adds
complexity with mp_exec_once to init aexit() to free the string, which
was leaked anyway, because the structure is thread_local and atexit only
data from the main thread was freed.
Remove all this, and just use static buffer.
Move PathCchRemoveFileSpec after actually getting the file size. It must
have been swapped at some point by accident.
Also use correct unit for the size.
Fixes: #17375
The system preferred language is the language used during Windows
install. It doesn't have much purpose except that it is the backend
language for core Windows internals. All user facing dialogs and text
should follow the user preferred language, as this is what the user
selected and uses on daily basis.
It makes no sense to include system language in track selection.
Commit baf2fd2f28 fixed this for 2nd call
to GetSystemPreferredUILanguages(), but apparently regressed the 1st
call, duh.
To retrieve the size both buffer has to be NULL and size 0.
Memory has a lot of zeros, because it has been working quite
consistently on CI.
duration and position properties were observed as double which lead to a
lot of updates per second (high granularity). it is recommended to not
update the position of the touchbar too frequently, why we had a manual
1 second rate limit.
instead of manually rate limiting the property, just observe it as int64
which only updates every second. it also causes a bit less pressure for
our core.
duration and position properties were observed as double which lead to
a lot of updates per second (high granularity). it is recommended to not
update the position of the remote command center to frequently, why we
had a manual 1 second rate limit.
instead of manually rate limiting the property, just observe it as int64
which only updates every second. it also causes a bit less pressure for
our core.
since we have a mapping layer between vulkan and metal (MoltenVK) we
don't actually know which colorspace is used/mapped to.
log colorspace changes to actually see which colorspace was chosen.
since we have a mapping layer between vulkan and metal (MoltenVK) we
don't actually know which pixel format is used/mapped to.
log pixel format changes to actually see which format was chosen. only
those 9 formats are valid for a CAMetalLayer.
https://developer.apple.com/documentation/quartzcore/cametallayer/pixelformat
This ensures that we test format string for the actual impl that is
being used. Depending if UCRT is used and if __USE_MINGW_ANSI_STDIO is
defined the implementation capabilities may differ.
Note that we don't explicitly define __USE_MINGW_ANSI_STDIO anymore,
this is defined implicitly in mingw headers, if needed. We don't support
ancient mingw versions that does not define it correctly for c11.
Some protocols may not exist, add them so the mapping to url handler
works correctly. Note that protocols are not removed, only the handler
is. They will remain unassociated, after unregister.
Fixes: #16832
UniformTypeIdentifiers is only available since macOS 11.
added in 6b0e4f7 and #15859.
guard the allowedContentTypes UTType property of the NSOpenPanel and
add a dummy struct UTType and dummy allowedContentTypes property on
macOS versions that don't have those available.
currently we use the withLock function with NSCondition and NSLock,
which are not available on swift versions lower than 5.7. we only added
compatibility fallbacks for NSCondition though. introduced in 1364c80
and #14334.
instead of only adding the fallback to a specific class add it to the
whole protocol all the locking classes use, similar to the actual
implementation.
with commit 8d20b72 and PR #15442 we switched to the recommended swiftc
compiler for building our swift code. this lead to some
incompatibilities with swift versions prior to 5.8, where a new linker
was introduced.
work around that problem by using the old swift frontend build for older
swift versions. this can be removed when we remove the support for those
old versions.
Fixes#15591
On Linux, we have `mpv.desktop`, and on macOS, we have `osxbundle`, both
of which handle file associations and protocol registration in the
system environment.
On Windows, this information is stored in the registry, so this commit
adds support for it.
It registers the application, supported file types, and supported
protocols, and adds an uninstall entry so users can remove all
registrations via the control panel. Note that this does not remove the
binary itself.
The implementation is fully portable. There are no external installers,
as mpv handles everything automatically. This should improve usability
when moving binaries and so on.
- `mpv --register` registers mpv (see verbose output for a list of actions).
- `mpv --unregister` reverts all changes made during installation.
- `mpv --register-rpath <string>` allows specifying a string to be
prepended to `PATH` before running mpv. This is useful when using
external dependencies that shouldn't be added globally to `PATH`.
In reproducible builds, meson.current_source_dir() also leaks absolute paths, so it's better to use files() instead
ref: https://mesonbuild.com/Reference-manual_builtin_meson.html#mesoncurrent_source_dir
> You do not need to use this function!
> When passing files from the current source directory to a function since that is the default. Also, you can use the files() function to refer to files in the current or any other source directory instead of constructing paths manually with meson.current_source_dir().
xdg-user-dirs is basically the standard for defining user desktop
directories on linux/bsd. To account for locales and languages, we
basically have to parse the config file (~/.config/user-dirs.dirs)
directly. That or call xdg-user-dir. Either way, it's a little more
complicated than the others, but still doable enough.
Drop it to warning, even if -Werror is in effect. Interesting part is
that this makes this warning disappear completely. GCC diagnostics at
its finest.
C11 uses _Thread_local as the keyword, which thread_local macro
is defined to (inside of <threads.h>, which mpv doesn't use):
https://port70.net/~nsz/c/c11/n1570.html#7.26.1p3
C23 promotes thread_local to a keyword and marks _Thread_local
as obsolete and to be avoided in new code:
https://www.iso-9899.info/n3220.html#6.4.1p3
so just use thread_local directly, which is future-proof while
having a fallback define in osdep/threads.h for pre-C23 cases.
The buffer size were never set to 0, after first call. To retrive the
size both buffer has to be NULL and size 0. Otherwise it fails.
While at it refactor whole thing and use returned count as sanity limit.
After removal of `MP_MUTEX_RECURSIVE` from vdpau.c there are no more
clients of recursive mutex. Remove all the code related to it. This
commit can be reverted if in the future it is needed again. For now
let's not keep dead code.
It has been moved to the mpv core with additional security
considerations, including filtering unsafe protocols from being opened
via the URL handler.
While we are not aware of any active exploitation, naive protocol
handling could allow the use of niche protocols in FFmpeg, which, in
turn, might load native code. How such native code would be dropped on
the local machine is another question.
This remains theoretical, but it's better to be safe than sorry.
Fixes: 494d408583
nanahi