Could also be set to unknown, but let's keep it center, so any fallbacks
in other places wouldn't trigger. In practice it shouldn't be used for
non-subsampled formats.
We currently force PQ output when target_csp() is not available, to
preserve compatibility with backends that do not support it and to
enable HDR on them. However, for SDR transfers we can safely skip this
and simply use the source mode instead.
Ultimately, this "force PQ" mode needs to be removed, but target_csp()
is still not implemented for all relevant backends.
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.
BT.1886 is mostly limited to TV production which is almost exclusively
limited range. sRGB for full range is better guess, if no better
information is available.
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
It's enough to not wait for the flip and start with next frame and in
the same time minimized latency which helps display-sync modes, that are
not aware about swapchain depth.
Allows to not wait for flip. Instead of forcing depth for display-sync
modes we will reduce default value instead.
This reverts commit d7495e4ea6.
Fixes: #16823
Those are controlled by the `--swapchain-depth` option and is already
set to 3 by default. There is no need to add hardcoded hidden frame of
"slack". Users can adjust depth by changing the config.
All the math and interpolation assumes immediate presentation of the
frame. VO is driven by VSYNC and it is expected that current frame that
we render will be displayed on current present call, without delay.
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`.
Let us fallback fully to software decoder. There is an issue in ffmpeg
where if we return software format here for hwdec threading context it
will be assumed to be usable, but not accelerated, which would be fine,
but later it causes assertion failure when copying avctx context
between decoding threads in ffmpeg.
Avoid this issue, but returing NONE format after we failed.
No reason to not enable threads if lavc supports them, same as for
software decoding. Might help with pipelining of decoding and filtering.
Performance difference may vary, but in my testing everything is working
as expected and I didn't notice any regressions.
Set to 2 threads by default as conservative value that should resolve
stalling issue, while also not spawn too many cpu threads, which won't
help with hwdec anyway and only can cause too deep queue of hardware
surfaces.
Fixes: #16578
When using more than one threads, the callback can be called from
different thread from sibling avctx, we cannot use our main one to query
codec/hw_frames paramters.
Use context provided in callback arg to fix that.
When ICC profile is applied, use it also in hint to ensure correct
target colorspace configuration. ICC profile takes precedence over
anything else, to make sure libplacebo internally interpret it the same.
Fixes: #16646
We don't know which colorspace the profile were created from. We could
set hint to ICC target colorspace, but it would be ambiguous, because it
doesn't say which colorspace were configured in practice.
Additionally on Wayland with all the color management the client side
ICC correction is not supported, because we cannot set pass-through
mode.
Conceptually we should use VK_COLOR_SPACE_PASS_THROUGH_EXT to get
"direct" access to display response, but while this may work on macOS,
on Wayland it means "don't configure csp", instead of "configure to
pass-through", which means colorspace would have to be configured
externally, which is also not possible, see [1].
You can also see [2] for more discussion on the topic.
For now let's not hint any colospace and leave libplacebo in default
selection. Which restores previous status quo. This can be improved in
future, but for now this fixes use of ICC profiles in default mpv
config.
[1] https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/27
[2] https://github.com/haasn/libplacebo/issues/324Fixes: #16646
It uses a more sophisticated heuristic for title selection. It not only
selects the longest title but also considers quality and chapters. Refer
to the libbluray source for details.
No documentation change, "longest" option will still look for the
longest, just may work better now.
Fixes selection of title on some discs.
Allows to specify custom fontconfig sysroot. Useful for fuzzing
environments where we might use specific config, font or the system wide
config is not available.
We want to add padding around the whole bitmap, not within it. Smaller
parts are rendered onto bigger bitmap. Remove leftover padding code.
Fixes: e2fc75434e
This ensures that we don't mix maxCLL if target already has max_luma.
This can be opt-in with mode=source and manual target-peak override. No
need to merge to much things.
We wait for timeout and stop fuzzing, but if there are events spammed
this timeout never fire, so instead limit the number of events after
playback reset.
This is raw option passed to lavf and can be used to inject complex
filters and so on, avoid this for fuzzing as it more fuzzing ffmpeg side
anyway and causes issues with timeouts for some big processing.
Useful for demux_edl where it is possible to have huge nested tree of
demuxers and they are added recursively, which causes stack overflow in
some cases.
Found by OSS-Fuzz.
Also cache last dxgi output, to avoid enumerating outputs, this is done
on every frame and we want to minimize impact of it.
While at it refactor and split loading libraries.
Instead of using IDXGISwapChain::GetContainingOutput create new DXGI
interface on each query. This may not be as efficient, but it solves the
issue where metadata is not updated after changing display settings.
DXGI caches parameters on swapchain creation and never updates it.
Also refactor it so it can be used from other contexts.
Note that DXGI is not D3D11, it's mixed in mpv code, may be cleaned in
the future.
If color space hint is enabled respect configured parameters of
swapchain. When color space hint is disabled, override output freely.
This fixes possible fallback or other decisions about output made during
the swapchain color space negotiation.
When targeting SDR on display with enabled HDR, compositor will have to
convert SDR to HDR transfer before sending this to display. Resulting in
most certainly wrong output.
To avoid this always convert SDR to target transfer function when
hinting, this way, we do the conversion in mpv and not defer it down the
pipeline.
Unfortunately it's not very portable to detect if we have HDR display
output and "guess" if what we send to display will be correctly
interpreted or not. But we do this when we can.
Also don't force target_peak value from auto detection, use value from
libplacebo.
While testing larger inputs can be useful for uncovering bugs related to
processing large data or inefficiencies in memory allocation, it also
makes the fuzzing process slower and more fragile.
Beyond the obvious slowdown, there are OOM issues and even in libFuzzer.
Specifically, in fuzzer::InputCorpus::AddToCorpus, after a few hours of
fuzzing, we accumulate so many inputs that memory usage exceeds our
quota. This could be mitigated in other ways, such as dumping data early
or shortening the fuzzing run duration. However, in practice, these huge
inputs are often not very useful.
This change will also encourage the fuzzer to mutate existing data
rather than continually adding more bytes to input, because it give
higher coverage. Which in turn will produce higher quality corpus.
The 100 KiB limit could be reduced further. It's still quite large, let's
see how it performs. I believe even 10 KiB might be sufficient or less.
This issue is especially noticeable in the Matroska fuzzer, because we
add input data there, which is bigger and sets max_len high in fuzzer
itself.
In a perfect world, we wouldn't need to impose such limits, but in
reality, we face constraints in both memory and compute resources.
I'll monitor coverage and fuzzing results after this change and adjust
as needed. Unfortunately, this will discard all existing corpus entries
larger than the limit, but that's expected.
Most users of this function doesn't expect it to return NULL, with
exception of Stereo-3D video mode. Which is a list directly linked to
Matroska specification, and used as value check in demux_mkv and also
when printing format.
There already was a MP_STEREO3D_NAME_DEF macro, so just promote this to
more generic function.
Fixes assert on invalid value found by OSS-Fuzz.
Fixes double evaluation in MP_STEREO3D_NAME_DEF macro.
Rendering OSD on every frame draw is quite heavy, even if some of the
rendering parts are cached, it still takes significant amount of time,
depending of payload can take 8-10 ms just to do the text shaping.
Instead render only when we need it.
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.
sizeof(AVPacket) being part of an ABI is deprecated. This was the last
remaining stack usage, missed in previous related change.
Note that we still use sizeof(AVPacket) and sizeof(AVBufferRef) in
demux_packet_estimate_total_size(). But it's safe, the worse that can
happen is that we underestimate the size on mismatch.
Fixes: cb15bc4324
Fixes excessive memory usage with avdevice input. After [1] packets
returned from avdevice contains wrapped AVFrame. mpv estimates packet
size to limit how many of them are cached. The size were not correctly
calculated, because packed contained only AVFrame* and not the actual
data in buffer. Fix this by calculating wrapped size and add it to our
size estimation.
[1] https://github.com/FFmpeg/FFmpeg/commit/6ca43a9675d651d7ea47c7ba2fafb1bf831c4d0b
Disables perf graphs from stats.lua. They are relatively expensive to
render, causes a lot of memory to be used for caches which are never
reused because graph is rarely the same. And most importantly those
graphs are not that useful beyond quick visual inspection of jitter.
Can be enable in script-opt if needed. Cache graph is left enabled,
because it shows if cache readhead grows or not nicely.
Kacper Michajłow