| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
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. As Vulkan 1.1 is a hard
requirement for libplacebo, we can just use UUIDs without conditional
checks.
Fixes #10898
|
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are way too many preexisting scripts that rely on this behavior
for video panning, like for example scripts that allow you to use mpv as
an image viewer. If this behavior is desired then it may be better to
add a new option for panning relative to the destination instead.
The restriction of video-pan-x/y being clamped to {-3, 3} also results
in the video being impossible to pan if it was zoomed in beyond a
certain degree.
This reverts commit 7d6f9e37397ed57be0f1375afe8fddfc451aa152.
|
|
|
|
|
|
|
|
|
| |
`--vo=gpu-next` no longer uses this option, being replaced entirely by a
luminance-based approach internally. And even for `--vo=gpu`, the values
other than 'hybrid' are universally inferior in quality.
In the interest of gradually reducing the amount of option bloat here,
remove this mostly-pointless option.
|
|
|
|
| |
They are all available on Windows 7 and newer.
|
|
|
|
|
| |
Those structs in MinGW-w64 are correct. I compared to Windows SDK and
actually our version have not correct alignment.
|
|
|
|
|
|
| |
Just cropping by VO that works with hwdec.
Fixes: #12222
|
| |
|
|
|
|
| |
Rely on caller to set them.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Attaching a NULL buffer unmaps the surface, allowing compositors to skip
blending the empty buffer.
Closes #12236
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The last piece in the puzzle for doing hardware conversions
automatically is ensuring we only consider valid target formats for the
conversion. Although it is unintuitive, some vaapi drivers can expose a
different set of formats for uploads vs for conversions, and that is
the case on the Intel hardware I have here.
Before this change, we would use the upload target list, and our
selection algorithm would pick a format that doesn't work for
conversions, causing everything to fail. Whoops.
Successfully obtaining the conversion target format list is a bit of a
convoluted process, with only parts of it encapsulated by ffmpeg.
Specifically, ffmpeg understands the concept of hardware configurations
that can affect the constraints of a device, but does not define what
configurations are - that is left up to the specific hwdevice type.
In the case of vaapi, we need to create a config for the video
processing endpoint, and use that when querying for constraints.
I decided to encapsulate creation of the config as part of the hwdec
init process, so that the constraint query can be down in the
hwtransfer code in an opaque way. I don't know if any other hardware
will need this capability, but if so, we'll be able to account for it.
Then, when we look at probing, instead of checking for what formats
are supported for transfers, we use the results of the constraint query
with the conversion config. And as that config doesn't depend on the
source format, we only need to do it once.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Historically, we have not attempted to support hw->hw format conversion
in the autoconvert logic. If a user needed to do these kinds of
conversions, they needed to manually insert the hw format's conversion
filter manually (eg: scale_vaapi).
This was usually fine because the general rule is that any format
supported by the hardware can be used as well as any other. ie: You
would only need to do conversion if you have a specific goal in mind.
However, we now have two situations where we can find ourselves with a
hardware format being produced by a decoder that cannot be accepted by
a VO via hwdec-interop:
* dmabuf-wayland can only accept formats that the Wayland compositor
accepts. In the case of GNOME, it can only accept a handful of RGB
formats.
* When decoding via VAAPI on Intel hardware, some of the more unusual
video encodings (4:2:2, 10bit 4:4:4) lead to packed frame formats
which gpu-next cannot handle, causing rendering to fail.
In both these cases (at least when using VAAPI with dmabuf-wayland), if
we could detect the failure case and insert a `scale_vaapi` filter, we
could get successful output automatically. For `hwdec=drm`, there is
currently no conversion filter, so dmabuf-wayland is still out of luck
there.
The basic approach to implementing this is to detect the case where we
are evaluating a hardware format where the VO can accept the hardware
format itself, but may not accept the underlying sw format. In the
current code, we bypass autoconvert as soon as we see the hardware
format is compatible.
My first observation was that we actually have logic in autoconvert to
detect when the input sw format is not in the list of allowed sw
formats passed into the autoconverter. Unfortunately, we never populate
this list, and the way you would expect to do that is vo-query-format
returning sw format information, which it does not. We could define an
extended vo-query-format-2, but we'd still need to implement the
probing logic to fill it in.
On the other hand, we already have the probing logic in the hwupload
filter - and most recently I used that logic to implement conversion
on upload. So if we could leverage that, we could both detect when
hw->hw conversion is required, and pick the best target format.
This exercise is then primarily one of detecting when we are in this
case and letting that code run in a useful way. The hwupload filter is
a bit awkward to work with today, and so I refactored a bunch of the
set up code to actually make it more encapsulated. Now, instead of the
caller instantiating it and then triggering the probe, we probe on
creation and instantiate the correct underlying filter (hwupload vs
conversion) automatically.
|
|
|
|
|
|
|
|
| |
So far all the keypad keys except for `0` and `,` mapped to the same
MP_KEY_* independent of numlock state, even though different key codes
are received.
Now all the alternative functions map to appropriate MP_KEY_* defines,
with missing ones added.
|
|
|
|
|
| |
Fixes: 57ba77fc736f6976bc114974f5955c972139740f
Fixes: #12220
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These were the only keys missing to support mapping all keycodes on a
[popular RF Remote][1] used with Linux HTPC apps.
Note that X11/XWayland + xkbcomp still warns about keycodes > 255, due
to the 8-bit limit in Xorg but `mpv` on Wayland is able to handle these.
For X11 users, there are [a couple options][2]:
- [Gianni Ceccarelli's patched `xf86-input-evdev`][3]
- [Use udev hwdb to map scancodes to keycodes][4]
[1]: https://www.mythtv.org/wiki/Air_mouse_rf_remote
[2]: https://unix.stackexchange.com/a/436233/7688
[3]: https://www.thenautilus.net/SW/xf86-input-evdev/
[4]: https://wiki.archlinux.org/title/Map_scancodes_to_keycodes
|
| |
|
|
|
|
| |
Fixes: https://github.com/mpv-player/mpv/issues/12208
|
|
|
|
|
| |
This can happen under perfectly legitimate circumstances if no file is
loaded yet.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It makes it more usable to virtually move dst rect instead of scaled
src.
The issue with the latter is that it is affected by video-zoom
paramters. For example if we do `--video-pan-x=-0.5` in normal case it
will move video -50%, but if we apply video-zoom/scale the video will
float towards the middle in unintuitive way. Extreme case is when one do
--video-zoom-x=0.01, now it is impossible to move video unless you
specify huge video-pan-x value, but it is limited to [-3, 3]. So you
cannot do anything.
With this changes regardless of video scale/zoom, video-pan will keep
center of scaled video in one place.
|
|
|
|
|
|
|
| |
It doesn't make sense to have zero here and it breaks, logic below.
Width was still campled to 1, but with broken offset.
This fixes things like video-scale-x=0
|
|
|
|
| |
The convention is to use dashes.
|
|
|
|
|
| |
VAAPI is not the only hwdec that won't work when the render node
isn't available.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- uninit gl before the VO
- destroy EGL surface before context: reverse of the creation order.
I also checked other code which doesn't even call this and leaves
it up to eglTerminate, which frees everything anyway. But this
seems more correct since we're destroying the gbm surface afterwards.
- check against at EGL_NO_DISPLAY instead of 0: there is probably no
EGL implementation where this makes a difference, it is more correct
regardless
- remove pointless eglDestroyContext call
- check render_fd before close
|
| |
|
| |
|
|
|
|
|
|
| |
mpv was taking focus when being started with "--window-minimized=yes". This change stops mpv from taking focus when this option is used.
Resolves: #9641
|
|
|
|
|
|
| |
It's possible for systems to have multiple cards, and the first capable
card to not have a connected output. Skip such cards and continue
iterating until we find one with a connected output.
|
|
|
|
|
|
|
| |
Without doing this, --fs --fs-screen=1 wouldn't actually end up on the
desired screen since the sizehint was never sent. Also check the
screen-name variants for an empty string as well so the option can
properly "undo" itself (not sure if this has any practical effect).
|
|
|
|
|
|
|
|
|
|
|
| |
mpv mixes xinerama and randr usage together which gets kind of
confusing and is also pretty stupid. Xinerama is completely unneccesary
today since randr can do everything it can do and much more. Remove it.
This reworks a lot of the window/geometry handling stuff to be centered
completely around xrandr_display plus some other tweaks to the geometry
handling. An important concept is that current_icc_screen is changed
into current_screen and used more generously since it is useful for
things besides just icc profiles.
|
|
|
|
|
|
| |
There really is no reason to not just hard require randr 1.4. xorg added
1.4 support in 2012 and someone somehow using an xorg server older than
that today surely has several other problems.
|
|
|
|
|
|
|
| |
If we failed to create a gbm surface, we would call drm_egl_uninit
to free up any state we had allocated. However, we would segfault if we
tried to cleanup properties there were never initialized. Null checks
have been added to guard against this.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Now implied by the minimum libplacebo version.
|
|
|
|
| |
LIBPLACEBO_NEXT is now implied by libplacebo being available
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This completely disables all smoothing. Despite what the manual claims,
a decay rate of 1.0 does *not*.
It's worth pointing out that this depends on the following commit to
work properly in --vo=gpu-next, but I don't think working around such a
minor detail is worth the trouble, considering people building nightly
mpv are probably also building nightly libplacebo it should just work
(tm).
See-Also: https://github.com/haasn/libplacebo/commit/1c464baaf4c6228dcfac87f19db1dafc22e328c8
See-Also: https://github.com/haasn/libplacebo/commit/83af2d4ebd5086a56f7b1a2f86628ada3612ee7c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libplacebo doesn't like it when the queue_params PTS is less than the
actual PTS of the frame for the first frame and skips mixing it during
interpolation. This can happen if you seek while paused because mpv will
always keep the vsync_offset value as if it was still playing. So in
some cases, this can be a negative value and thus the PTS will end up
decreasing and libplacebo interprets this frame as a first frame. This
skips mixing the frame and thus you get a black screen. To fix this
this, just realize that vsync timings are completely meaninglessly in
while paused. If you are not actively pushing frames, there's no reason
to care about vsync_offset. So just clear it and make it zero when the
VO's internal state is paused and we're trying to render a frame. Makes
libplacebo happy and fixes #11958.
|