| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
While the video playing, it's not actually needed and can cause
unnecessary redraws. Fixes #12623.
|
|
|
|
|
|
|
|
|
|
|
|
| |
In many cases, this is purely cosmetic because poll still only accepts
microseconds. There's still a gain here however since
pthread_cond_timedwait can take a realtime ts now.
Additionally, 37d6604d70c8c594de2817db26356c4c950ac0fd changed the value
added to timeout_ms in X11 and Wayland to ensure that it would never be
0 and rounded up. This was both incomplete, several other parts of the
player have this same problem like drm, and not really needed. Instead
the MPCLAMP is just adjusted to have a min of 1.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fbe154831a8addfc18a4f81e1c4b9284c31acace added a new VOCTRL to signal
when the OSD changed for gpu-next's handling of subtitles, but this is
both not necessary and actually incomplete. The VOCTRL would signal OSD
changes, but not all subtitle changes (like selecting another
non-external sub track for example). VOCTRL_OSD_CHANGED was used to
increment p->osd_sync which would then redraw the blended subtitles if
the player was paused.
But there's already a VOCTRL_PAUSE and VOCTRL_RESUME. Plus, the
sub_bitmap_list object will have items in it if it changed in any way,
so we don't need the VOCTRL_OSD_CHANGED method at all. That can be
removed.
The check that fp->osd_sync < p->osd_sync stays in place since that's an
optimization while the video is playing, but we also check the pause
state as well since the VO can know this. If we're paused, then always
do update_overlays since core must be signalling a redraw to us if we
get a draw_frame call here. Additionally in update_overlays itself, the
p->osd_sync counter is incremented if we have any items since the frame
signature will need that. As for the actual bug that is fixed, changing
subtitle tracks while paused with blended subtitles now correctly works.
Previously, it was never updated so the old subtitle stayed there
forever until you deselected it (since VOCTRL_OSD_CHANGED triggered
there).
Also include some cosmetic code fixes that were noticed.
|
|
|
|
|
|
|
| |
Pointless bloat option, hard-coded as 256 now in libplacebo and no
reason not to also hard-code in mpv.
See-Also: haasn/libplacebo@64d7c5aab06766a9492d3cfffd35333792052cd9
|
|
|
|
|
|
|
| |
Pointless bloat option, hard-coded as 1e-3 now in libplacebo and no
reason not to also hard-code in mpv.
See-Also: haasn/libplacebo@64d7c5aab06766a9492d3cfffd35333792052cd9
|
|
|
|
|
| |
All SUBBITMAP_LIBASS are converted to sRGB beforehand, for the rest we
need to use video color space.
|
|
|
|
| |
Need to use correct adjusted dst.
|
| |
|
|
|
|
|
| |
This would always apply the config blur and taper values to the kernel,
even if it was zero because the user didn't specify any.
|
|
|
|
|
|
|
| |
Upstream finally caved in to peer pressure and added this filter. Of
course, this also removes the fallback for people on older versions of
libplacebo, but people using mpv git master are probably using
libplacebo git master anyway. It's time to debloat this code.
|
|
|
|
|
|
|
|
|
| |
Upstream has moved from passing struct pl_icc_profile to directly
attaching a managed pl_icc_object, plus providing a new function
pl_icc_update to update the ICC profile object parameters (if needed).
To facilitate this move, pull our ICC params back out of pl_options and
update the target ICC object directly.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Interrim solution, forwards compatible with new and backwards compatible
with old API. Eventually, we will want to discontinue the use of
deprecated pl_icc_params.save/load and pl_renderer_save/load, but that
requires minimum version bump.
|
|
|
|
|
|
|
|
|
|
| |
Causes bad performance with interpolation because the changing hue angle
invalidates the mixing cache, as a result of libplacebo implementations
(specifically, the fact that this graph is drawn during the color
management process, instead of as a separate overlay).
Fix it by just hard-coding a particular, relatively interesting plane
(pi/4 approximately maps onto the red-blue axis).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pick a smarter rect, limit it to right half of screen (to allow more
easily using it simultaneously with stats), and also auto-rotate through
the hue plane by default (wrapping once every 10 seconds of playback).
I briefly considered making it based on wallclock time instead of pts,
but this has the rather unfortunate downside of only being updated
sporadically as the user moves the mouse over OSC elements. (Of course,
we could also forcibly redraw the screen continously to avoid it, but
I'd rather not make such an invasive change for no real reason)
This design also allows you to pause and focus on (via framestepping)
individual parts of the hue graph that you're interested in.
|
| |
|
|
|
|
|
|
| |
Somehow this overrode max_luma instead of min_luma...
Fixes: 347fbd6fa357e854cfb0bc6d3c9b3d12994d5c0c
|
|
|
|
|
| |
Gives the correct queue size value for the subsequent pl_queue_update()
calls, which avoids a bit of unnecessary overhead.
|
|
|
|
|
| |
Avoids some unnecessary #ifdef and allows us to isolate the shim to a
single location.
|
|
|
|
| |
Also avoids 80col violation.
|
|
|
|
|
|
|
| |
This was incorrectly adapted from the old options system, we forgot to
ever actually assign p->frame_mixer to params.frame_mixer.
Fixes: d2082841df8bc39c585fc9d4be6498d1a296fed8
|
|
|
|
|
|
|
|
| |
This actually fixes a bug that was present in this code even before the
new pl_options system, which is that `video_screenshot` would
permanently leave `peak_detect_params.allow_delayed` as false, until
something else forced options re-application due to options cache
change.
|
|
|
|
|
|
|
| |
Instead, take a stack copy of the relevant struct. Avoids leaving
temporary state dangling after this function returns.
Fixes: 40b6afcfca81a30c29531a49b6368b53ad5d501f
|
| |
|
|
|
|
| |
Fixes: https://github.com/mpv-player/mpv/issues/12208
|
|
|
|
|
| |
This can happen under perfectly legitimate circumstances if no file is
loaded yet.
|
|
|
|
|
|
|
|
| |
Before d208284, this was implicitly reset back to 0 at the start of
every update_options(). But we no longer explicitly reset par->params,
so we need to do it manually here for the hooks.
Fixes: https://github.com/mpv-player/mpv/issues/12203
|
|
|
|
|
|
|
| |
Undefined behavior (bad initializer). Somehow didn't trigger a warning
on my end...
Fixes: a8192eda6cfc909fc9f5f62e36523b53c0300eff
|
|
|
|
| |
To help test not-yet-exposed options, and for debugging purposes.
|
|
|
|
| |
This is already set by map_scaler, just disable it if unwanted.
|
|
|
|
| |
No need to override this so late in the general (non-screenshot) code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With a backwards compatibility shim for older versions of libplacebo in
which we simply define the relevant subset of this struct ourselves and
initialize it to known-good values, to be able to continue using our
options assigning code.
It's worth pointing out that our use of scalers deviates from how
pl_options was intended to be used, as a consequence of backwards
compatibility with pre-308 versions of libplacebo. But this should work
fine in practice, since we don't care about serializing these custom
scalers correctly. Users can still override them using the built-in
pl_options scalers when loading custom scalers via --libplacebo-options.
(To be added in the next commit)
|
|
|
|
|
|
| |
This was already correctly freed when acquiring a new profile, but never
freed on uninit. Fix by reparenting the profile onto `p`, which is what
vo_gpu also does.
|
|
|
|
|
| |
This header is installed unconditionally starting with libplacebo
v4.208.0, so we are safe to remove the check.
|
|
|
|
|
| |
Instead copy the data on-demand when VOCTRL_PERFORMANCE_DATA is
requested.
|
|
|
|
| |
v6.292 implied by minimum dependency.
|
|
|
|
|
|
|
|
|
|
|
| |
983e8f0100b98bd8aed48e5fe86dd5682174b04e resulted in the correct
dimensions, but it was not actually right because vo_gpu_next still had
the src and dst rects the same. This just needs to work like how vo_gpu
does where the src is the image params and the dst is desired output. So
basically, just copy that code over here. Fixes #12108 and as a bonus,
overriding the aspect ratio now results in correct screenshots
(previously didn't work at now and then with the above commit it had
correct dimensions but still incorrect output).
|
|
|
|
|
|
| |
Using the width and height params directly doesn't actually work if PAR
is something other than 1. Instead, use mp_image_params_get_dsize and
calculate the correct dimensions which matches the vo_gpu behavior.
|
|
|
|
| |
Closes: https://github.com/mpv-player/mpv/issues/12093
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1 is not enough to prevent PL_QUEUE_MORE, because the pl_queue is
designed to always know the next frame (in addition to the current).
Before haasn/libplacebo@112bb886, this was was (wrongly) silently
omitted by the pl_queue code, but that fix exposed this.
While it's technically API misuse on mpv side, due to the mpv vo code
having its own internal queueing and timing control, it shouldn't
actually make any difference in practice (and likely, the error message
showing up is the only meaningful bug here - the issue is entirely
cosmetic).
Fixes: https://github.com/mpv-player/mpv/issues/12101
|
|
|
|
|
|
|
|
|
|
| |
Configuration of filter parameters was moved from pl_filter_function (of
which the user had to make a copy) to pl_filter_config, with the
pl_filter_function remaining immutable.
Implement this new logic in a way that can reasonably exist side-by-side
with the old configuration API. Once we drop support for PL_API_VER
below 303, we can drastically simplify this code.
|
|
|
|
|
|
|
|
|
| |
The manual currently says that if dscale is unset, --scale will be
applied. However, this only works at init time. If you change the dscale
filter to be empty later, vo_gpu will segfault and vo_gpu_next will
throw an error and refuse the changes. That's because when the option is
unset at runtime, the value becomes "" not NULL and the vo's never
accounted for this. Fixes #12031.
|
| |
|
|
|
|
|
|
|
| |
This code failed to handle the case of the swapchain submission being
skipped because the window was invisible.
Fixes: f9dc695b580c394bf4f9833d36e91b7fcbe009ea
|
|
|
|
| |
Presents frames at the correct time when DS is disabled.
|
|
|
|
|
|
|
|
| |
We wanted to preserve the libplacebo v5.264.0 requirement for gpu_next
for this release, since this is the what most Linux distributions are shipping.
The VLC 3 <-> libplacebo v6 situation is an additional reason distros are not
likely to ship the newest libplacebo release soon.
This reverts commit b73d96776cfee61f88bf60b27315baab32a2115d.
|
|
|
|
| |
New upstream feature. Disabled by default.
|
|
|
|
| |
For better control over target display levels.
|
|
|
|
|
|
|
|
|
|
|
|
| |
--no-config should prevent loading user files of any type: configs,
cache, etc. For cache files, this case wasn't properly handled and it
was assumed they would always get something. vo_gpu's shader cache
actually already handles this, so it was left untouched. In theory,
demuxer cache should never have this issue because saving it to disk is
disabled by default (and likely that will never change), but go ahead
and change it for consistency's sake. Fixes some segfaults with
--no-config and various combinations of settings (particularly
--vo=gpu-next).
|
|
|
|
| |
VOCTRL is processed on VO thread.
|
|
|
|
|
| |
Instead copy the data on-demand when VOCTRL_PERFORMANCE_DATA is
requested.
|
|
|
|
| |
For better or worse.
|
|
|
|
|
| |
Adds the missing upstream values that were exposed by the new gamut
mapping API.
|
|
|
|
|
|
| |
We will need the full ra_ctx to be able to look up all the state
required to initialise an ffmpeg vulkan hwcontext, so pass let's
pass the ra_ctx instead of just the ra.
|
|
|
|
|
| |
Address of variables can't be used for constant initialization in C
language modes.
|
|
|
|
|
|
|
| |
It was unsafe to return pointer to memory that was freed on another
thread, just copy the string to caller owned sturcture.
Fixes crashes when displaying passes stats with gpu-next.
|
|
|
|
|
| |
This shouldn't happen as the array sizes are the same, but guard against
it in case libplacebo do something naughty.
|
|
|
|
|
| |
info_callback is fired quite often and from different thread than any
accesses to this structure.
|
|
|
|
| |
Fixes invalid memory writes.
|
|
|
|
|
|
| |
Introduced by, of all things, a rebase...
Fixes: a5da8b2c87dc3ace0038ccb5dc8f221df7f52206
|
|
|
|
|
|
|
|
| |
This just replaces the API calls to get rid of deprecation warnings, it
doesn't yet expand the enum, nor replace them by the proper options.
The translation from tone map modes to hybrid mix parameters is taken
from the libplacebo source code.
|
|
|
|
| |
Removed upstream, to be replaced by constant 0.04.
|
|
|
|
|
|
| |
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.
|
|
|
| |