The union member is only valid for SUBBITMAP_LIBASS. The resulting data
is only read for PL_OVERLAY_MONOCHROME, so there was no risk of using
garbage data, but we can make it explicit.
x2bgr10/x2rgb10 are packed formats that do not automatically get mapped by the
existing ra_pl logic. They are more useful than other non-byte-aligned packed
formats because they show up when dealing with > 8bit RGB content, which is
more common in an HDR context.
In practice, x2bgr10 is probably the only one that's going to get used, but
I figured there's no harm in supporting both.
After ANGLE commit 56663dbfa780 EGL_EXT_device_query is listed in the
client extension string instead of the display one. The display string
check always failed, silently disabling native d3d11va interop.
This fixes `hwdec` with `gpu-context=angle`.
VOs can hold more frames than the requested lookahead. vo_gpu_next's
pl_queue retains past frames for the interpolation mixing window. Let
VOs declare the total number of frames they may reference at the same
time, so fixed hwdec surface pools can be sized accordingly.
Up until now, we have not bothered to propagate queue creation flags when
setting up the ffmpeg device context, but with libplacebo setting flags like
VK_DEVICE_QUEUE_CREATE_INTERNALLY_SYNCHRONIZED_BIT_KHR and newer nvidia drivers
actually supporting this feature, I've now managed to run into this. If the
flags aren't put into the context, ffmpeg code can end up calling
vkGetDeviceQueue2 with the wrong flags, and the driver will return a NULL
queue instead.
I suspect we got this far without hitting this because the only filter that
can currently end up calling vkGetDeviceQueue2 is vf_libplacebo and then only
with the new `inherit_device=1` where the device we set up _from_ libplacebo
goes back to libplacebo. The oroborus is complete.
Instead of using zero initialized value. Otherwise an early init failure
calls close(0), a descriptor we don't own, breaking whatever else
happens to hold it.
This is bit defensive, but I want to init those just after allocation,
so we don't have to trace whether they are initalized correctly or not.
Instead of using zero initialized value. Otherwise an early init failure
calls close(0), a descriptor we don't own, breaking whatever else
happens to hold it.
Also add missing check before close() call.
Instead of using zero initialized value. Otherwise an early init failure
calls close(0), a descriptor we don't own, breaking whatever else
happens to hold it.
This is bit defensive, but I want to init those just after allocation,
so we don't have to trace whether they are initalized correctly or not.
The software renderer backend is not capable of using any of the VO
capabilities set globally by vo_libmpv. This can lead to assertion
errors when trying to render a video with 90 degree rotation metadata.
Instead use the ctx->renderer->driver_caps value so the source frame
doesn't have its params rotated when it's not desired.
This is mostly useful for SDR mode where previously we would output 203
nits, which on Windows is considered HDR, because reference white is
fixed at 80 nits in SDR mode. Which in turn causes additional
tone-mapping when using scRGB output.
Note that for SDR transfers this doesn't change the luminance, but
instead causes more aggressive tone-mapping, might not be fully
expected. But maybe we should follow system setting for better of for
worse.
Fixes: https://github.com/mpv-player/mpv/issues/17850
Not fully, because when ICC profile is embeded in content, libplacebo
will override our luminance, this will be fixed separately.
Replace the static format whitelist with a device-probed table and add
4:4:4 (VUYX/XV30/XV36/XV48) and 4:2:0 12/16-bit (P012/P016) surfaces to
both the zero-copy and copy mapper paths. The packed YUV formats can't be
decomposed by ra_get_imgfmt_desc(), so they are viewed as a single RGBA
texture and the swizzle is recovered from the imgfmt descriptor, which
only works with --vo=gpu-next.
Ideally we would properly log this with mp_log but the plumbing for that
was deemed too ugly and not really worth it for just this one mysterious
edge case. So instead, drop the fprintf business since we really
shouldn't be doing that.
After
https://github.com/mm2/Little-CMS/commit/bb60a46e9c50e9d3d18cf6dd81869240e4ebe618
cmsDetectBlackPoint can output nonzero X and Z values, which can end up
slightly negative due to rounding errors.
Bound the resulting src_black values by 0 below to ensure that raising
them to the power of 1 / gamma does not result in NaN, which would
result in a broken video profile.
Fixes#17439.
This is another file where the slopbot identified a problem, but I was
surprised to see it fix it in a poor way and also miss an adjacement
problem.
`mapper_map` calls `mapper_unmap` with the intention of using it to clean
up partial failure after some planes are wrapped and released while others
are not. But the current code would actually segfault in that situation.
There are two fixes required:
* Ensure `p->vkf` is set by `mapper_map` early so that its available to
`mapper_unmap` in the error path
* Don't call `vkfc->unlock_frame` in the `mapper_map` error path, as
this will be called by `mapper_unmap`
Fixes#17977
The slopbot spam did find valid issues in the error paths in this code, and as
part of verifying them, I have additional fixes.
* ensure that the return value -1 from `cuda_init()` if `ext_init()` fails
* zero alloc the `ext_vk` and `ext_gl` structs so that we have a known initial
state
* explicitly initialise the `sem_handle.fd` to -1 to ensure we don't
accidentally close stdin in the error path. But also don't do this on
windows as an invalid Handle is 0.
* Don't do a double `cuCtxPopCurrent()` in the `ext_gl` init failure path
Fixes#17976, #17988, #17989
Note that when the video params don't change, the check in
player/video.c does not call vo_reconfig2 and the _NET_ACTIVE_WINDOW
message is not sent. As far as I can tell, the same limitation is true
for the macOS implementation, but I can't test that.
Kacper Michajłow