| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Also while at it respect target-peak option when ICC profile is used.
Fixes #11449
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds cache as a possible path for mpv to internally pick
(~/.cache/mpv for non-darwin unix-like systems, the usual config
directory for everyone else). For gpu shader cache and icc cache,
controlling whether or not to write such files is done with the new
--gpu-shader-cache and --icc-cache options respectively. Additionally,
--cache-on-disk no longer requires explicitly setting the --cache-dir
option. The old options, --cache-dir, --gpu-shader-cache-dir, and
--icc-cache-dir simply set an override for the directory to save cache
files. If unset, then the cache is saved in XDG_CACHE_HOME.
|
|
|
|
|
|
|
| |
Address of variables can't be used for constant initialization in C
language modes.
See https://github.com/llvm/llvm-project/commit/0c43d8077e605ab78d85180f0dcaa4df1ae37607
|
|
|
|
| |
Found by codespell
|
|
|
|
|
| |
We don't need these anymore now that we require PL_API_VER>=264 for
building libplacebo-next
|
|
|
|
|
|
|
|
| |
libplacebo v6.265.0 removed v4 deprecations. We already require
PL_API_VER >= 202, so we don't need to wrap
pl_tex_transfer_params.row_pitch around a conditional, which exists
since PL_API_VER >= 168. However, pl_source_frame.duration does not exist until
PL_API_VER >= 219, so we should use a conditional directive.
|
|
|
|
| |
This field was renamed/moved to a different params struct.
|
|
|
|
|
|
| |
Screenshots using the hardware renderer should now include color tags
that map directly from the libplacebo tags, so the if/else logic only
needs to be included once.
|
| |
|
|
|
|
| |
Fixes: #11339
|
|
|
|
|
|
| |
c78482045444c488bb7948305d583a55d17cd236 introduced a bool option type
as a replacement for the flag type, but didn't actually transition and
remove the flag type because it would have been too much mundane work.
|
| |
|
|
|
|
|
| |
Improves playback for Dolby Vision video files as the metadata can be
used instead of requiring `hdr-compute-peak=yes`.
|
|
|
|
|
| |
Useful for getting native screenshots of non-sRGB content, such as HDR
etc.
|
|
|
|
|
|
|
|
|
| |
When taking window screenshots with a colorspace override, tag them
appropriately, based on the best-known colorspace info. Note that this
is imperfect, we should ideally also attach the output ICC profile if
one exists. But this is better than nothing.
Also force 1:1 PAR in this case. In all other cases, default to sRGB.
|
|
|
|
|
|
|
|
|
|
| |
When taking an unscaled screenshot, always render to an unspecified
SDR-like space. (Subject to change) Apply output-specific options (ICC
profile, color space overrides, custom LUT) only in window screenshot
mode.
I decided to split this off from subsequent refactors because it is IMO
a bug fix deserving of its own commit.
|
|
|
|
|
|
| |
Screenshots are currently always RGB. Subject to change, but needs to be
communicated clearly if changed. This commit is not a functional change,
it's merely for code clarity.
|
| |
|
|
|
|
|
|
|
| |
Based on the new upstream helper function `pl_map_hdr_metadata` and the
existing AV_FRAME_DATA_DYNAMIC_HDR_PLUS. This allows us to use SMPTE
2094-40 dynamic HDR tonemapping in mpv, albeit with the limitation of
requiring `--tone-mapping=auto` in order to pick this curve upstream.
|
| |
|
| |
|
|
|
|
| |
For sufficiently new versions of libplacebo.
|
|
|
|
|
| |
This is a huge disgusting mess to thread through everywhere. Maybe I'm
stupid for attempting to solve the problem this way.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Flushing the cache is a hammer-for-a-screw operation, because it nukes
*all* renderer state, including the HDR peak detection state. When
enabling e.g. --hdr-compute-peak, or any other future methods of dynamic
tone mapping, this would lead to bad results (e.g. brightness
fluctuations) whenever the OSD state is updated.
Instead of flushing the cache to force an OSD re-render, instead just
update the frame signature directly whenever its osd_sync value changes.
This accomplishes effectively the same thing but without touching the
HDR state.
This is slightly violating the libplacebo abstraction in a way that
isn't publicly documented. To be on the safe side we could make a carbon
copy of the array before modifying it, but given that this is unlikely
to change upstream I'll probably just end up explicitly documenting it
instead of forcing the copy in mpv.
|
|
|
|
|
|
|
| |
When the alpha channel is the first component, this code block gets
skipped by the continue, meaning the check for c==0 never passes.
Fix it by explicitly keeping track of whether bits have been set.
|
|
|
|
|
|
|
|
|
|
|
| |
This is a very simple but easy way of doing it. Ideally, it would be
nice if we could also add some sort of introspection about shader
parameters at runtime, ideally exposing the entire list of parameters as
a custom property dict. But that is a lot of effort for dubious gain.
It's worth noting that, as currently implemented, re-setting
`glsl-shader-opts` to a new value doesn't reset back previously mutated
values to their defaults.
|
|
|
|
| |
Fixes: https://github.com/mpv-player/mpv/issues/10815
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This brings vo_gpu_next's behavior more in line with vo_gpu. Currently,
the status quo was that `vo_gpu_next` generated subtitles with the full
resolution of the dst crop, even though practical limitations of
libplacebo meant that such subtitles inevitably got cut off at the video
boundaries. This was actually a worse status quo than `vo_gpu`, which
simply constrained subtitles to the video dimensions to prevent these
issues.
With this change, the behavior is the same as `vo_gpu`, which has the
exact same problem w.r.t interpolation. Users are back to choosing
between --blend-subtitles=yes and not having subtitles in margins,
and using --blend-subtitles=no and not having subtitle interpolation.
There are different pros and cons to each approach, and I still
ultimately plan on allowing libplacebo to interpolate subtitles even in
the black bars, to solve this issue once and for all. But for now, let's
not let perfect be the enemy of good.
No attempt is made to implement `--blend-subs=video`, which I consider
deprecated.
Fixes: https://github.com/mpv-player/mpv/issues/10272
|
|
|
|
|
|
|
| |
I actually don't quite understand why this is needed, since in theory we
should already be doing the rotation as part of applying the crop. But I
guess that code doesn't quite work. This is the only way it works, so
it's probably correct. (And note that `vo_gpu` does the same internally)
|
|
|
|
| |
This is used in other places in the code, so it should be fine.
|
|
|
|
|
|
| |
This fixes an issue where blend stages with multiple passes got
overwritten by later passes, with only the final pass (typically the
overlayp pass) actually being shown.
|
|
|
|
| |
This was ignored as an oversight.
|
|
|
|
| |
One step closer to vo_gpu_next feature parity with vo_gpu!
|
|
|
|
|
| |
The current code also rejects e.g. rgb30, even though this format is
perfectly valid, because it only checks for alignment of the used bits.
|
|
|
|
|
|
|
| |
Relies on a new upstream API for adding save/load callbacks to the ICC
3DLUT generation parameters.
Closes: https://github.com/mpv-player/mpv/issues/10252
|
|
|
|
|
| |
`total_bits` may be less than the true pixel stride (`bpp`) for formats
which contain extra ignored components (e.g. rgb0).
|
| |
|
|
|
|
| |
Fixes https://github.com/mpv-player/mpv/issues/10594
|
|
|
|
|
| |
This check was wrong/outdated. PL_QUEUE_MORE does not imply an empty
frame mix, it can still contain partial frames.
|
|
|
|
| |
This path incorrectly assumes there is a current frame.
|
|
|
|
| |
Fixes #9451
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One downside of this approach is that it bypasses the mixer cache, but
while this is not ideal for performance reasons, the status quo is also
simply broken so I'd rather have a slower implementation that works than
a faster implementation that does not.
And as it turns out, updating the OSD state and invalidating the mixer
cache correctly is sufficiently nontrivial to do in a clean way, so I'd
rather have this code that I can be reasonably certain does the right
thing.
Fixes #9923 as discussed. Also fixes #9928.
|
|
|
|
|
|
|
|
|
|
|
| |
It is possible for vo_gpu_next to attempt a resize before the windowing
backend is fully initialized. In practice, this can happen on wayland
which means libplacebo attempts a 0x0 resize. Depending on the API, a
0x0 resize may be allowed (vulkan or d3d11), but libplacebo just returns
a 0 in this case which mpv doesn't do anything with anyway. In the case
of opengl, this usage is explictly forbidden and will result in a
warning which may confuse users. Solve this by just not trying a resize
if dwidth and dheight in the vo are not available. Fixes #10083.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes use of the new frame acquire/release callbacks to hold on to
hwdec images only as long as necessary. This should greatly improve the
smoothness/efficiency of hwdec interop, by not holding on to them for
longer than needed.
This also avoids the need to pool hwdec mappers altogether.
Should fix #10067 as well, since frames are now only mapped when we
actually use them.
|
| |
|
| |
|
|
|
|
|
|
| |
This reverts commit 1c2dde91d369987199782f4914f56019e5a2272c.
Fixes #10037
|
|
|
|
|
|
| |
Pulling in <libplacebo/utils/libav.h> in particular triggers the
notorious _av_vkfmt_from_pixfmt linking issue when FFmpeg is built
without Vulkan support.
|
|
|
|
|
|
|
|
|
| |
When I introduced the concept of lazy loading of hwdecs by img format,
I did not propagate the probing flag correctly, leading to the new
normal loading path not runnng with probing set, meaning that any
errors would show up, creating unnecessary noise.
This change fixes this regression.
|
|
|
|
| |
Fixes #9976
|
|
|
|
|
|
|
| |
This code fails if we have DR buffers, but none of them correspond to
the current frame. Normally only happens if e.g. changing the decoder at
runtime, since DR buffers are not properly reinit in that case.
(Arguably a separate bug)
|
|
|
|
|
|
|
| |
The current map_frame() code fails to clean up after itself on the
failure paths. But if map_frame returns false, no cleanup code is ever
attempted. Add the relevant calls to clean up state manually,
throughout.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So, turns out the approach in 7f67a553f doesn't work for all codecs. In
particular, sometimes lavc will internally allocate a new AVBuffer that
just points at the old AVBuffer but has a different opaque field for
some reason. In these cases, the DR metadata doesn't survive the
round-trip through libavcodec.
I explored several alternative ways of solving this problem, including
adding new mp_image fields, but in the end none of them survived the
round-trip through AVFrame and back. The `priv` and `opaque` fields
in respectively `mp_image` and `AVFrame` are also too heavily overloaded
to be of much help.
In the end, bite the bullet and use the same approach as done in
`vo_gpu`, which is to just keep track of a list of all allocations. This
is a really ugly way of doing things IMO, but ultimately, completely
safe.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some decoders, notably hevcdec, will unconditionally memset() the entire
AVBufferRef based on the AVBufferRef size. This is bad news for us,
since it also overwrites our `struct dr_buf`.
Rewrite this code to make it more robust - keep track of the DR buf
metadata in a separate allocation instead. Has the unfortunate downside
of technically being undefined behavior if `opaque` is not at least 64
bits in size, though, but avoids this issue.
Maybe there's a better way for us to unconditionally keep track of DR
allocation metadata. I could try adding it into the `mp_image` itself.
Maybe on a rainy day. For now, this works.
Fixes #9949
Might fix #9526
|
|
|
|
| |
This mostly copies the API used in the GL backend.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two major ways of going about this:
1. Expose the native ra_gl/ra_pl/ra_d3d11 objects to the pre-existing
hwdec mappers, and then add code in vo_gpu_next to rewrap those
ra_tex objects into pl_tex.
2. Wrap the underlying pl_opengl/pl_d3d11 into a ra_pl object and expose
it to the hwdec mappers, then directly use the resulting pl_tex.
I ultimately opted for approach 1 because it enables compatibility with
more hardware decoders, specifically including ones that use native
OpenGL calls currently. The second approach only really works with
cuda_vk and vaapi_pl.
|
|
|
|
|
|
| |
This avoids decoding/caching more frames in advance than necessary. In
particular, this is very important for hwdec, which generally can't have
too many decoded frames in a pool at the same time.
|
|
|
|
|
|
|
|
|
| |
libplacebo v198 fixed this properly by adding the ability to flip planes
directly, which is done automatically by the swapchain helpers.
As such, we no longer need to concern ourselves with hacky logic to flip
planes using the crop. This also removes the need for the OSD coordinate
hack on OpenGL.
|
|
|
|
| |
Fixes #9911
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Render subs at the output resolution, rather than the video resolution.
Uses the new APIs found in libplacebo 197+, to allow controlling the OSD
resolution even for image-attached overlays.
Also fixes an issue where the overlay state did not get correctly
updated while paused. To avoid regenerating the OSD / flushing the cache
constantly, we keep track of OSD changes and only regenerate the OSD
when the OSD state is expected to change in some way (e.g. resolution
change). This requires introducing a new VOCTRL to inform the VO when
the UPDATE_OSD-tagged options have changed.
Fixes #9744, #9524, #9399 and #9398.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an annoying special case only really needed because of the
`vflip` filter. mpv handles this by directly adjusting the plane
transform. The libplacebo API, unfortunately, does not allow passing the
required information for this to work smoothly.
Long-term I plan on adding support for plane flipping in libplacebo
directly, but for the meantime, we will have to work-around it by moving
the flipping to the whole-image `crop` instead. Not an ideal solution
but better than crashing.
Fixes #9855
|
|
|
|
|
| |
Failing to do this results in the shader cache not actually ever being
written, ergo no shader caching being done. Oops.
|
|
|
|
|
|
|
|
|
| |
The only way to fix the channel order here is to create the texture with
bgra format. Incidentally, there used to be a way to set the component
map for overlays directly |