libdrm unfortunately doesn't give us what is actually supported by the
connector in question. To do that, we would have to parse the edid blob.
Use libdisplay-info to do this and make it required for drm support.
Using what we get back from the library, we can do a bit of sanity
checking for hdr metadata to make sure that the display in question can
handle it before we try setting the metadata. Strictly speaking,
libdisplay-info has stuff for dynamic metadata that we could potentially
use, but as a first pass and for simplicity, only static is considered
for now.
Running cross-compiled binaries may be possible, but the runtime
environment must be configured correctly. In some configurations, an
exe_wrapper needs to be used, and in all cases, the library path must be
set correctly for the given binary. Fortunately, Meson handles all of
this if cross-compilation is configured correctly.
Fix this by having Meson run the mpv binary directly, instead of as a
subprocess of a Python script. This ensures that the environment is
properly set for running host binaries, if possible.
Fixes: #15075
Fixes: 056b03f9ed
Add 4 stage trie to lookup unicode codepoint width and grapheme join
rules.
Generated by GraphemeTableGen from Microsoft Terminal (MIT Licence):
a7e47b711a/src/tools/GraphemeTableGen/Program.cs
With minor adjustment to use it in C codebase.
- Replaced constexpr with static
- Replaced auto with explicit types
Generated from Unicode 16.0.0:
ucd.nounihan.grouped.xml: sha256(b11c2d23673bae660fff8ddcd3c1de4d54bdf6c60188a07696b010282f515fcf)
This essentially obsoletes the console wrapper (mpv.com), which is no
longer needed. The console is attached depending on the context in which
mpv.exe is run.
Add an option to control which subsystem is targeted. Keep the GUI
application as the default to preserve compatibility with Windows
versions prior to 24H2.
For more information about the new console handling, see:
4386bf07fd/doc/specs/%237335%20-%20Console%20Allocation%20Policy.md
without swift mpv as a standalone app is unusable on macOS, since the
cocoa main main loop doesn't exists. furthermore most of the other
needed functionalities like video outputs, contexts, platform features,
etc are also missing.
without swift mpv is really only usable as libmpv.
Newer meson versions added support for features that mpv has been using
for a long time. Annoying fallbacks were left in place to not break old
versions but ideally everyone should be using the newer build features.
Both the latest ubuntu LTS and debian stable (in backports) have 1.5.0
in their repos, so go ahead and bump the version so we can drop some old
code and let developers use newer meson features if applicable.
It makes sense to only descend into the subdirectory meson build file on
windows, but we should always make sure HAVE_WIN32_SMTC is 0 for other
platforms. Otherwise, it gets unneccesarily awkward to work with.
Even Debian stable has them, so no need to keep compatible with ancient
versions.
Note that this does not change runtime version requirement for Vulkan.
Fixes: https://github.com/mpv-player/mpv-build/issues/234
Vulkan dependency implies only vulkan loader, but some distributions
split vulkan-loader and vulkan-headers, so check if the headers are
actually there.
VapourSynth introduced their version 4 API in R55, 3 years ago. mpv is
still using the deprecated version 3. I think it is good to migrate
before VapourSynth completely removes it.
The most impacted area is the video format. Previously we have a fixed
table of supported formats, each represented by an integer. In v4, the
integer is replaced by pointer to the full struct of the format.
Second, the way to create video filter is changed. Previously caller
needs to supply a "initialization" callback to `createFilter()`, which
sets up video info etc. In v4, video info is prepared first, passed to
the `createVideoFilter2()` and we get back the node.
Also, previously mpv was using the `fmSerial` filter mode, which means
VapourSynth 1) can only request one frame from mpv at a time, and 2) the
order of frames requested must be sequential. I propose to change it to
the parallel request mode, which requests multiple frames at a time in
semi random order. The reasons are, for 1), the get frame function,
`infiltGetFrame()`, unlocks the mutex during output image generation,
thus can benefit from parallel requests. For 2) thanks to the frame
buffer, unordered frame requests are acceptable. Just make sure the
buffer is large enough.
Third, the way VapourSynth scripting environment works change. In v4,
the scripting API is operated through struct pointer, much like the
exist `vsapi` pointer. The "finalize" function is also no longer needed.
Some were duplicated between GCC and Clange. Others were missing in
Clang case. Instead test all the flags and don't make assumptions that
will get invalid over time. Testing flags is almost free.
If we can run the built mpv binary, then it is possible to use a custom
target that reads the protocols we have available in mpv and write the
mpv.desktop file based on the output. For cases where this is not
possible (e.g. cross compiling), then just install the unmodified
mpv.desktop file like before. Fixes#8731 and fixes#14124.
Statically linking, especially with LTO can use a lot of memory. Limit
to 16 jobs by default, which is more than enough. Only fuzzers are
affected as we don't produce that much binaries otherwise.
The stream layer is just not the right place to make this change
since it's also used for completely unrelated purposes such as reading
configs.
This reverts commit bb7a485c09.
```
dd if=/dev/zero of=/tmp/10g.empty bs=1 seek=10G count=0
dd if=/dev/zero of=/tmp/10m.empty bs=1 seek=10M count=0
time mpv /tmp/10{g,m}.empty
```
I keep files with the name format `${name}-${hash}.${ext}.empty`
around, where the original is removed, and a sparse file with
the size of the original is created instead.
A lot of time is wasted on such files when going through
playlists/directories that include some of them.
This admittedly may not be that common of a use-case.
Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
by default utilises the color space of the screen on which the window is
located. if a specific value is defined, it will instead be utilised.
depending on the chosen color space the macOS EDR (HDR) support is
activated and that OS's transformation (tone mapping) is used.
Fixes#7341
Dudemanguy
nanahi
Kacper Michajłow
Misaki Kasumi
der richter
Brad Smith
llyyr
Crend King
sfan5
Mohammad AlSaleh