Introduces stream_http, an internal libcurl-driven backend for http://
and https:// URLs. Runs all transfers on a dedicated curl multi thread
with a producer-side ring buffer, and exposes HTTP/2 multiplexing,
QUIC/HTTP/3 (when libcurl supports it), HSTS and TCP keep-alive.
Should generally be more stable and faster than FFmpeg HTTP/1.1 impl,
additionally connections are kept-alive between files open, so if you
open playlist of network files and navigate through them, it will re-use
the same connection.
Build is gated on the new 'libcurl' meson option (auto). When disabled
or unavailable, mpv silently falls back to FFmpeg's HTTP implementation.
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.
This allows using --licensedir. Meson then also generates and
installs a machine-readable manifest file at that location, which
would include the licenses of subprojects if we had any.
LLVM even in freestanding build required memset/memcpy/memmove to be
implemented. We don't use them directly but the calls are generated from
the code, which are later optimized away. Since this suppose to be small
utility application, we can always optimize it.
Fixes: #17664
This util function uses the generic libavutil hash API to hash any data
with the specified algorithm to a bstr. It deduplicates multiple hash
routines used in mpv.
This version contains critical fixes to swapchain selection, correct
mapping of sRGB TRC as well as fix for gpu hangs on anv. Bump the
minimum version because the mpv experience with previous version
shouldn't be endorsed or be considered acceptable by upstream.
The instanced API allows a lot of work to be offloaded to the GPU and
makes software rasterization tolerable performance-wise in most cases.
This is similar to sd_ass but there are some substantial differences:
- It uses a BGRA atlas to allow drawing bitmap emoji.
- De-duplicates images internally to significantly reduce atlas size by
reusing the same atlas image for different instances.
- Exploits bilinear interpolation to further reduce atlas size of some
primitives. For example this allows reducing background boxes to one
very stretched pixel.
Bumps subrandr requirement to `v1.1` since this API is not present in
earlier versions.
D3D11 only for now. Documentation says that only D3D11 and D3D12 is
supported, but it looks like Vulkan is possible too. But I realized this
after implementing this version. Vulan may be added later.
Fixes: #16613
subrandr is a subtitle rendering library which aims to render
SRV3 (YouTube) subtitles and WebVTT subtitles accurately.
Currently in mpv WebVTT subs are rendered via ffmpeg conversion to ASS
which throws away a lot of the style and completely disregards
the WebVTT non-region-cue positioning algorithm. Furthermore if
one wants to render some more complex SRV3 subtitles one has to
resort to external converters since it's not even supported by ffmpeg.
However subrandr is able to render SRV3 subtitles natively with support
for the most commonly used features. It can render ruby text without
relying on font metrics during conversion which is obviously fragile,
and it can perform correct scaling using the exact calculations used by
YouTube instead of making up ASS approximations. Similarly it follows
the WebVTT spec for the features of WebVTT that it supports (mostly).
It's not perfect of course and there's still many things it doesn't do
or does wrong but those are things that can be incrementally improved
outside of mpv.
in a13a674363 we set the default category
for the bundle to games, to get certain benefits like better rendering
timing, better bluetooth latency, better threading, etc (bundle only).
though this also prevents low power modes and wrongly categories the app
for spotlight search etc.
set the default category to video and add an option to set the category
to games if one wishes to.
osxbundle.py currently reads the version number from MPV_VERSION, while
Meson first tries git describe before falling back to MPV_VERSION.
Update osxbundle.py to try reading the version number from version.h
before falling back to MPV_VERSION. This ensures that the version number
in the bundle matches the output of mpv --version.
I previously tried to enable sdl2-gamepad by default and the CI turned all red.
In detail:
- SDL_config.h has macros that conflict with ours
- memory leaks caused the tests to fail
- main=SDL_main redefinition broke MSYS builds
The options remain disabled by default, but lets warn our users a bit.
it doesn't make sense to build the swift parts without cocoa because
the swift bridge would be missing and it's impossible to interact
with the swift parts from obj-c, swift depends on cocoa/appkit/etc, and
the cocoa main function/main loop is missing making anything
cocoa/appkit/GUI crash on use.
like this it is possible to build mpv on macOS without cocoa, it will
fallback to the unix main function and mpv can run in 'headless' mode,
eg you can use it from CLI, it won't spawn any App icon/menu/etc, and
you can use everything that isn't related to cocoa/appkit/GUI like audio
playback. anything other will make mpv segfault, for example sdl2 and
its vo, since it tries to spawn a window.
path-mac.c was not properly set as path_source for macOS. it didn't lead
to any errors because it was added to the normal source files. though
in the case of tests and for certain setups the mac path symbols were
not found.
to fix that properly add path-mac.c to path_source (additional to
path_darwin.c), remove it from the normal source files and don't
overwrite it later with the posix or darwin path.
this was overlooked in 9db8182 and #11374
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`.
fd4e3af740 originally started installing
it, and we've been doing it ever since then. The value of having all of
these encoding profiles predefined by default is pretty dubious since a
lot of them are pretty old ('MP4 for Nokia N900' being a shining
example) and mpv is not really a good encoding tool anyways. Let's treat
it like the other conf files in etc and install it in the data directory
for reference. If someone really uses these, they can copy the file over
locally to their mpv config directory and it'll still work fine.
video/out/gpu/d3d11_helpers.c requires it as well, and it's possible to
have egl-angle-win32 enabled without d3d11.
Signed-off-by: Christopher Degawa <ccom@randomderp.com>
We used to deal more directly with drm-specific things, but that has all
since been removed and is known to not be needed. We can relax the build
requirements some more since vo_dmabuf_wayland will simply error out if
no hwdec backend is available at init.
This is a bare runner for mpv.exe. There is no need for a stack
protector here and when it is forced to be added by -fno-stack-protector
it complains about missing symbols, because we don't link any standard
libs here.
Fixes:
undefined symbol: __stack_chk_fail
undefined symbol: __stack_chk_guard
We could define those, but mpv.com wrapper doesn't need it.
This is useful to run mpv from URL handler. Can be used to start mpv
from you web browser or anything that would trigger url handler for
given protocol. Only safe protocols are allowed.
Current solutions to run mpv in such context are to spawn IPC proxy and
run mpv when requested, but this is in most cases not necessary.
Currently the protocol is added in mpv.desktop. Windows related
registration will follow in future changes.