c784820454 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.
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.
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.
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 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.
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.
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.
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
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.
