| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
| |
uses the same mechanic as for x11
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Unbelievably, mutter actually supports the idle inhibit protocol now
after many years of pain*. Let's remove this hacky warning.
*: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3145
|
|
|
|
| |
Also change a ta_free to talloc_free for consistency reasons.
|
|
|
|
| |
Gets rid of yet another mp_read_option_raw call.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Apparently removing WS_CAPTION disables some window animations. Instead
adjust non-client area to not draw title bar.
Note that we do not account for difference in real border size and
invisible one, but seems to work correctly.
|
| |
|
|
|
|
|
|
| |
I don't think in fullscreen mode it makes sense to enable rounded corners.
We can add another option if someone needs it, but for now `window_corners`
affects only the window as one would expect.
|
|
|
|
| |
Allows to set preference for window corners rounding for DWM.
|
|
|
|
| |
Fixes too small initial window size.
|
|
|
|
| |
DWM makes part of left, right and bottom border invisible.
|
|
|
|
| |
Fixes: #11432
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the addition of fractional scaling support, wl->scaling was
converted to a double. Some compositors (Plasma) can report values under
1 for fractional scaling, so this meant wl->scaling could be some
small fractional value. This is fine except that when using the legacy
code for drawing the mouse cursor (i.e. not the cursor-shape protocol),
it still uses the old integer scaling method in core wayland. The reason
for this is simply because fractionally scaling the mouse cursor surface
is nonsense and nobody even has cursor images for anything besides a
select few sizes anyways (32x32, 48x48, etc.). The existing integer
scaling sort of works but it's pretty bad too and you can get some weird
sizes anyway. This is why cursor-shape is preferred since it fixes this.
Anyways, since buffer scaling for the cursor only takes integers, there
could be truncation to 0 in the previously mentioned fractional scale
this. This naturally causes the compositor to send us an error and mpv
quits. The fix is to always make sure that the scale value used for the
cursor is at least 1. Anything less makes no sense. Fixes #12309.
|
|
|
|
|
| |
Fixes: #11610
Fixes: 9feeb324eddd9ed73ae667e10275f663d70f7544
|
|
|
|
|
| |
All SUBBITMAP_LIBASS are converted to sRGB beforehand, for the rest we
need to use video color space.
|
|
|
|
|
|
|
| |
There was assumption in the code that default settings are compatible
with dumb mode and are only one that should be used in this case.
Force bilinear if dumb mode is enabled.
|
|
|
|
|
| |
THis allows adding grain without debanding. libplacebo already supported
this, so no changes are required there.
|
|
|
|
|
|
| |
f56043759494dd584c8d82e7890f92fada18e34b deprecated this since the
--drm-device path option was added as a replacement. Drop the card
number selection logic.
|
|
|
|
| |
Easier to keep track of when we do want to remove it.
|
|
|
|
|
|
|
|
|
|
|
| |
A bit different from the OPT_REPLACED/OPT_REMOVED ones in that the
options still possibly do something but they have a deprecation
message. Most of these are old and have no real usage. The only
potentially controversial ones are the removal of --oaffset and
--ovoffset which were deprecated years ago and seemingly have no real
replacement. There's a cryptic message about --audio-delay but who
knows. The less encoding mode code we have, the better so just chuck
it.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've got an ungodly amount of OPT_REPLACED and OPT_REMOVED sitting
around in the code. This is harmless, but the vast majority of these are
ancient. 26f4f18c0629998a9b91e94722d166866d8b80a3 is the last commit
that touched the majority of these and of course that only changed how
options were declared so all of this stuff was deprecated even before
that. No use in keeping these, so just delete them all. As an aside,
there was actually a cocoa_opts but it had only a single option which
was replaced by something else and empty otherwise. So that entire thing
was just simply removed. OPT_REPLACED/OPT_REMOVED declarations that were
added in 0.35 or later were kept as is.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The osd support was originally written with the requirement that we have
actual frames getting delivered to the VO. This isn't always the case
though. If you force a window on a blank audio file for example, then
there will be no frame thus draw_frame did nothing. Since the previous
commit allows us to reliably detect this, we can rearrange the code
around a little bit to make this possible. A key change is to make the
osd_subsurface have wl->surface as the parent. This is seemingly
required otherwise the osd_surface buffers are never visible above the
empty video_surface when we have a black window. Also nuke the desync
call since it's completely pointless. Fixes #12429.
|
|
|
|
|
|
| |
It's useful for some VOs (dmabuf-wayland) to know if the image params
are actually real or fake ones sent by the core for the purpose of
force_window.
|
|
|
|
| |
Need to use correct adjusted dst.
|
|
|
|
|
|
|
|
|
| |
The defaults were awful and horribly regressed many files while also not
fixing banding on files that actually needed it, sometimes even
*increasing* banding due to the low threshold.
Fixes: 12ffce0f224056f91a20c9f0b197f4973931efbe
See-Also: haasn/libplacebo@e1e43376d16d5112ee1254534664b0b85110139b
|
|
|
|
|
|
|
|
|
| |
This probably makes `vo_gpu` tone mapping worse, or something, but who
cares. The status quo for a while now has been to use `vo_gpu_next` if
you care about HDR rendering at all.
See-Also: haasn/libplacebo@ec60dd156b82753a2e2d8a399899244605f4d1bf
See-Also: haasn/libplacebo@0903cbd05d7fc0391cbd99954924a39b855c8a1b
|
|
|
|
|
|
|
|
|
|
| |
This new filter is slightly sharper, and significantly faster, than
mitchell. It also tends to preserve detail better. All in all, there is
no reason not to use it by default, especially from a performance PoV.
(In vo_gpu_next, hermite is implemented efficiently using hardware
accelerated bilinear interpolation)
See-Also: https://code.videolan.org/videolan/libplacebo/-/commit/75b3947b2c07803456483ec6976c037bad91b5dd
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The goal is to provide simple to understand quality/performance level
profiles for the users.
Instead of default and gpu-hq profile. There main profiles were added:
- fast: can run on any hardware
- default: balanced profile between quality and performance
- high-quality: out of the box high quality experience. Intended
mostly for dGPU.
Summary of three profiles, including default one:
[fast]
scale=bilinear
cscale=bilinear (implicit)
dscale=bilinear
dither=no
correct-downscaling=no
linear-downscaling=no
sigmoid-upscaling=no
hdr-compute-peak=no
[default] (implicit mpv defaults)
scale=lanczos
cscale=lanczos
dscale=mitchell
dither-depth=auto
correct-downscaling=yes
linear-downscaling=yes
sigmoid-upscaling=yes
hdr-compute-peak=yes
[high-quality] (inherits default options)
scale=ewa_lanczossharp
cscale=ewa_lanczossharp (implicit)
hdr-peak-percentile=99.995
hdr-contrast-recovery=0.30
allow-delayed-peak-detect=no
deband=yes
scaler-lut-size=8
|
|
|
|
| |
Keep it sharp, let users opt-in more blurry result.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
296d40dc6f38401085d005bb4627f8afff46b041 changed how the vo handled
redraw requests in order to fix a race condition that can occur with
pausing. However, there was a slight oversight because a redraw request
that occurred while the core was unlocked and the video was still
playing would still be kept true (previously, this was always cleared).
That redraw is essential if mpv is paused otherwise the old issue comes
back, but if the video is playing it's unnecessary since the next loop
around will simply draw whatever we needed. The extra redraw could cause
a frame drop for some people in certain instances, so the solution is to
simply always clear redraw requests if !in->paused. This eliminates the
extra redraw but still keeps it when pausing.
Fixes #12426 and fixes #11579.
|
|
|
|
|
|
| |
After fixing the B and C params for bcspline, it ended up being the same
thing as bicubic. There's no reason to have two names for the same
filter, so remove bcspline and keep bicubic to match libplacebo.
|
|
|
|
|
| |
bcspline is defined as B=1, C=0 in ImageMagick (as CubicFilter) and
libplacebo, so we should match that.
|
|
|
|
| |
Matches HermiteFilter from Imagemagick (B=C=0, R=1)
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
All we have to do is set VO_CAP_ROTATE90 and then use buffer transform.
Maybe ideally we would rotate with vavpp instead if possible, but this
would be a convoluted mess that I'm not really interested in dealing
with right now.
|
|
|
|
| |
It is quite unnecessary to log every window move.
|
|
|
|
|
|
|
|
|
|
| |
No need for this since it's entirely redundant with just changing the
filter radius directly. In fact, that's the whole *point* of the filter
radius - it does not modify the filter, it modifies the scaling of the
window.
Of course, this does not work for non-resizable kernels. But, really,
who cares?
|
|
|
|
| |
Mainly for vo_gpu_next.
|
|
|
|
|
|
| |
Replaced by mathematically and numerically precise constants, the result
of exact computation. Also updates the description to provide more
explanation and motivation.
|
|
|
|
|
| |
For all filters. For consistency between vo_gpu and vo_gpu_next. Also
makes ewa_lanczossharp less special.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We currently always scaled the window to the size of the configured
radius. However, this is wrong - we should instead be scaling it to the
size of the sharpened/blurred kernel. Since the window is always
stretched to the configured size of the filter, we can accomplish this
easily by just multiplying the blur value into the filter radius
directly, and then using that adjusted radius in place of `f.radius`
everywhere.
On a side note, this gives a very minor performance boost to
ewa_lanczossharp for no downside.
|
|
|
|
| |
ewa_lanczos4sharpest, for example, overflows this buffer.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
And make it the default. In libplacebo, this uses internal heuristics to
pick a good size based on the actual ICC characteristics. This is
significantly less wasteful than always generating a 64x64x64 3DLUT (the
old status quo).
In vo_gpu, for simplicity, just default to 65x65x65. Note that this
provides slightly better accuracy than the old default of 64x64x64 for
technical reasons, and matches what libplacebo defaults to for typical
display profiles.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original OML sync implementation (which is where this calculation
originally comes from) made now_monotonic and ust_mp_time unsigned. This
is fine except it has the assumption that now_monotonic is always
greater than ust. This actually isn't always the case. In wayland, I
observed instances where the reported timestamp is in the future. Of
course, it's a valid question to wonder if this even makes sense but
these UST values are essentially opaque black boxes to us anyways. It's
entirely plausible that the gpu is expecting the actual presentation of
the last swap to be a bit in the future, the compositor gets this and
reports this to us. So we'll consider such stats as valid. Note that
xorg doesn't have this problem because it's roughly one swap buffer call
behind because of how the event loop works (honestly something that
should be fixed).
Of course, the problem with the unsigned type here is that it overflows
on the subtraction so make it signed and allow the appropriate negative
value to happen if it does. Note that this will simply result in a small
addition to mp_time_us() which is exactly what we want here (timestamp
slightly in the future). Some small style changes included just because.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While this resolves limitations of lavc decoder crop, it also introduces
artifacts with some of the source files or hwdec.
Depending on chroma sampler it is possible to sample outside the decoder
crop area, pulling dirty pixels into the image. Some decoders left them
zeroed, not black. To fix that we would need specifc solution during
mapping of avframes.
As most of the files require the crop only in bottom/right area, the
AVCodecContext::apply_cropping works ok for those.
For all other cases that require more fancy cropping like 1440x1080+240+0
user can manually set `--vd-apply-cropping=no`.
Limitations of the lavc crop are explained here:
https://ffmpeg.org/doxygen/trunk/structAVCodecContext.html#a4745c7455c317272c4e139d6f369936c
Fixes: 826ce82cad315f7a48f9c971d3a5fa005a9eab46
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So strangely enough, estimated_vsync_interval is stored as a double but
nominal_vsync_interval is not and neither is the vsync_interval. Those
are stored as int64_t. This loss of precision can matter even in common
cases. For instance, take a typical 60 Hz monitor. Instead of 16666.6666
(repeating) being calculated as the vsync interval, you would get 16666
since the decimals are truncated. This is not really good at all and
affects the calculated speed values you get when using display sync. For
consistency and better precision, these should all be doubles just like
estimated_vsync_interval. Technically this means that we won't be able
to store as high of an integer value but such values would be absurdly
huge and never actually needed. Also estimated_vsync_interval already
can't handle such a case anyway.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
Cropping by decoder has limitations with regards to aligment and hwdec.
It doesn't work to offset top left corner with hwdec and even with
software decoding it don't crop fully when resulting data would not be
aligned.
VO cropping is way more robust.
|
|
|
|
| |
This enabled cropping of container signaled rect.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We currently only allow specifying the Vulkan device to use by name. We
did this to avoid confusion around devices being enumerated in an
unpredictable order. However, there is a valid edge case where a system
may contain multiple devices of the same type - which means they will
have the same name, and so you can't control which one is used.
This change implements picking devices by UUID so that if names don't
work, you have some option available. |