| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This seems stable enough to use. Change the default, and remove it from
the sw-fast profile.
|
|
|
|
|
|
|
|
|
|
| |
As suggested by the zimg author: active_region is not supported on
outputs (and the API returns an error), so instead scale to the "full"
surface, but adjust the source rectangle such that the cropped output
image happens to cover the correct region.
Does this even work? Since Balmer Peak doesn't work, I can't really say,
but it seems to look correct.
|
|
|
|
|
|
| |
Also remove the "o" case, which was never implemented (probably was an
idea to output alpha formats, now obsoleted by zimg's full alpha
support).
|
|
|
|
| |
(But does anyone even read --vo=help output?)
|
|
|
|
|
|
| |
X11 is in fact beautiful and superior to Wayland. Instead, just state
what the problem is in most cases: software scaling. (We have
accelerated X11 rendering in vo_gpu and others.)
|
|
|
|
| |
Some pngs are paletted, so this is vaguely interesting.
|
|
|
|
| |
For the next commit.
|
|
|
|
|
|
|
|
|
| |
This was a confusing name, because 1. there's also a z_planes[] field,
and 2. it was not specific to zimg indexes.
Possibly there used to be an idea involved about supporting alpha to
non-alpha formats by discarding the alpha plane, but zimg does this now
(and zimg will correctly blend the alpha component too).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The special thing about this format is
1. mpv assigns the component ID 4 to alpha, and component IDs 2 and 3
are not present, which causes some messy details.
2. zimg always wants the alpha plane as plane 3, and plane 1 and 2 are
not present, while FFmpeg/mpv put the alpha plane as plane 1.
In theory, 2. could be avoided, since FFmpeg actually doesn't have a any
2 plane formats (alpha is either packed, or plane 3). But having to skip
"empty" planes would break expectations.
zplanes is not equivalent to the mpv plane count (actually it was always
used this way), while zimg does not really have a plane count, but does,
in this case, only use plane 0 and 3, while 2 and 3 are unused and
unset. z_planes[] (not zplanes) is now always valid for all 4 array
entries (because it uses zimg indexes), but a -1 entry means it's an
unused plane.
I wonder if these conventions taken by mpv/zimg are not just causing
extra work. Maybe component IDs should just be indexes by the "natural"
order (e.g. R-G-B-A, Y-U-V-A, Y-A), and alpha should be represented as a
field that specifies the component ID for it, or just strictly assume
that 2/4 component formats always use the last component for alpha.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We reorder the planes between mpv and zimg conventions. It turns out the
code still confused when which convention was used.
So the way it actually works is that the _only_ place where zimg order
is used is the zimg_image_buffer.plane[] array. plane_aligned[] and
zmask[] were accessed incorrectly, although I guess it rarely had a
reason to fail (plane reordering is mostly for RGB, which has planes of
all the same size).
Adjust some comments accordingly too.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The zimg wrapper "needs" these formats as intermediary when repacking
the normal gray/alpha packed format. The packed format is used by the
png decoder and encoder, and is thus interesting.
Unfortunately, mpv-only formats are a mess right now, because all the
existing code is focused around using the FFmpeg metadata for pixel
formats. This should be improved, but not now, so make the mess worse.
This commit doesn't add support for it to the zimg wrapper yet.
|
|
|
|
|
|
|
|
|
|
|
| |
libzimg recently added direct alpha support and new API for it. (The API
change is rather minimal, and it turns out we can easily support old and
new zimg versions.)
This does not support _all_ alpha formats. For example, gray + alpha is
not supported yet, because my stupid design in the zimg wrapper would
require a planar gray + alpha format, while ffmpeg provides only a
packed one.
|
| |
|
|
|
|
| |
Yes, this thing became vf_scale through the back door.
|
|
|
|
|
| |
returning a nil value only works when build with a +10.14 SDK otherwise
we need to fallback to the old mechanism.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for reasons unknown to me the NSCursor (un)hide functions can be
completely unreliable and the cursor can have an unknown state. this
only happens on some system and wasn't able to reproduce this. it's
probably some dumb race condition that might be possible to work around,
though because of the lack of reproducibility on my end it's hard to
test.
i decided to rework the cursor hiding code yet again and make it a lot
less greedy. the cursor will now always unhide when moved and there
will never be a situation again the cursor can't be unhidden again.
on the other hand there might be edge cases now where the cursor won't
hide immediately and you have to move it slightly to make it disappear
again. this should be an acceptable tradeoff.
Fixes #6886
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Wayland uses vo_wayland_wait_frame plus some polling with a timeout for
blocking on vsync. Here are a couple of changes that seem to be
improvements. First, the poll time is always rounded up instead of
truncated. When rendering frames longer than the standard 16.666 ms
timeout, it seems that truncating the poll time slightly early may cause
some vsync jitter spikes. Waiting longer, even if it's too long, appears
to behave better.
The second change is to use wl_display_roundtrip instead of
wl_display_dispatch_pending. wl_display_dispatch_pending dispatches all
events immediately. This is good to avoid blocking, but it's not
guaranteed to wait long enough for all events to be processed on the
display fd. The preceding wl_display_read_events routine ensures that
all events on the display fd are queued. We just need a semi-blocking
routine to dispatch them for the most reliable vsync.
wl_display_roundtrip will dispatch any events for us, but also wait for
a reply from the display server. This makes it ideal for this role. If
the compositor doesn't reply to the client something else is probably
horribly broken and wrong anyway. It's also not a permanently blocking
call like wl_display_dispatch. If there's no frame callback (i.e. the
window is hidden), then it does not dispatch any events and returns
immediately.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were a couple of erroneous things in the handle_toplevel_config
function. Firstly, looping through the different states was not handled
correctly. Launching a window as maximized (can happen in sway for
example) was always stuck on true and would never be set to false. Fix
this by always checking if XDG_TOPLEVEL_STATE_MAXIMIZED is found or not.
Also do a similar thing for the fullscreen state.
Additionally, there were some issues with resizing windows and
window-scale going back to old sizes. The root of this problem is that
the width and height arguments of handle_toplevel_config aren't actually
guarenteed to be the actual width and height of the surface. There are
times when mpv will set the surface size on its own (like with
window-scale) which will be unknown to the toplevel listener. To
complicate matters, there are times when we do want to use the width and
height arguments (like when resizing with the mouse).
Fix this by checking if the width and height arguments reported by
handle_toplevel_config changed from the previous call of the function.
If the value is different, then we go ahead and use them when setting
mpv's geometry. If not, then we just ignore it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On some platforms the ZPOS property might exist, but be immutable.
This is at least the case on Intel Sandy Bridge since Linux kernel
5.5.0. Trying to set an immutable property will cause.
drmModeAtomicCommit to fail with -EINVAL.
On other platforms we might want to set ZPOS to tweak the layering of
planes.
To reconcile these two, simply have drm_object_set_property check if a
property is immutable before attempting to add it to the atomic
commit, instead returning an error code (which is, as previously,
ignored in the case of ZPOS as we don't strictly need it)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This originally existed as a hack for weston. In certain scenarios, a
frame taking too long to render would cause vo_wayland_wait_frame to
timeout which would result in a ton of dropped frames. The naive
solution was to just to add a slight delay to the time value. If a
frame took too long, it would likely to fall under the timeout value and
all was well. This was exposed to the user since the default delay
(1000) was completely arbitrary.
However with presentation time, this doesn't appear to be neccesary.
Fresh frames that take longer than the display's refresh rate (16.666 ms
in most cases) behave well in Weston. In the other two main compositors
without presentation time (GNOME and Plasma), they also do not
experience any ill effects. It's better not to overcomplicate things, so
this "feature" can be removed now.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for setting window-minimized and window-maximized in
Windows. The minimized and maximized state can be set independently.
When the window is minimized, the value of window-maximized will
determine whether the window is restored to the maximized state or not.
Changing state is done with ShowWindow(), which has commands that change
the window state and activate it (eg. SW_RESTORE) and commands that
change the window state without activating it (eg. SW_SHOWNOACTIVATE.)
It would be nice if we could use commands that don't activate the
window, so scripts could change the window state in the backrgound
without bringing it to the foreground, but there are some problems with
that. There is no command to maximize a window without activating it, so
SW_MAXIMIZE is used instead. Also, restoring a window from minimize
without activating it seems buggy. On my Windows 10 1909 PC, it always
moves the window to the back of the z-order. SW_RESTORE is used instead
of SW_SHOWNOACTIVATE because of this.
This also changes the way the window is initially shown. Previously, the
window was made visible as a consequence of the SWP_SHOWWINDOW flag in
the first call to SetWindowPos. In order to set the initial minimized or
maximized state of the window, the window is shown with the ShowWindow
function instead, where the ShowWindow command is determined by whether
the window should be initially maximized or minimized.
Even when showing the window normally, we should still call ShowWindow
with the SW_SHOW command instead of using SetWindowPos, since the first
call a process makes to ShowWindow(SW_SHOW) has special behaviour
where it uses the show command in the process' STARTUPINFO instead of
the command passed to the function, which should fix #5724.
Note: While changes to window-minimized while in fullscreen mode should
work as expected, changing window-maximized while in fullscreen does not
work and won't result in the window changing state, even after leaving
fullscreen. For this to work correctly, the fullscreen logic needs to be
changed to apply the new maximized state on leaving fullscreen.
Fixes: #5724
Fixes: #7351
|
|
|
|
|
|
|
| |
the event returns a delta ratio so we can just add it to the current
window-scale.
Adds support for #3214
|
|
|
|
| |
this prevents a vanishing window if the size is set too small.
|
|
|
|
|
|
| |
it was possible for mouse events to be triggered when the core was
already being shut down. to prevent this properly close and remove the
window and additional remove the reference to MPVHelper object.
|
|
|
|
|
|
|
|
| |
this deprecates the old cocoa backend only option and moves it to the
general macos ones. add support for the new option in the cocoa-cb
layer creation and use the new option in the olde cocoa backend.
Fixes #7272
|
|
|
|
|
|
|
|
|
| |
due to the bundle config the icon is set automatically via the bundle
system mechanisms. this also makes it possible to set the icon to a
custom one with the standard macOS copy paste method via the file info
dialogue.
Fixes #6874
|
|
|
|
|
|
|
| |
As documented on struct mp_hwdec_ctx, hw_imgfmt specifies the hardware
surface wrapper format for which supported_formats is valid. If this was
not set, f_hwtransfer ignored supported_formats, and assumed all formats
were supported.
|
|
|
|
|
|
|
| |
Allow the --window-maximized and --window-minimized flags to actually
work when the player is started on wayland. If the compositor doesn't
support maximization or minimization, then these options just do
nothing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #7345
There was a multitude of issues with cursor handling in wayland and
behavior seemed to vary for strange reasons across compositors and also
bad things were being done in wayland_common. The problem is complicated
and involved fullscreen states being set incorrectly under certain
instances and so on. The best solution is to just remove most of the
extra cruft. In handle_toplevel_config, instead of automatically
assuming is_fullscreen and is_maximized are false, we should use
whatever value is currently set vo_opts which matters when we initially
launch the window.
|
|
|
|
|
| |
Try to exclude mostly uninteresting information from verbose logging,
but still include it in debug logging.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
hwdec_vaapi tries to probe all available surface formats in advance. For
that, we iterate over _all_ profiles in an attempt to collect possible
surface formats. This means we try profiles we normally wouldn't use for
decoding or filtering, and which could be "unrelated" services.
It seems some drivers report at least one profile, for which
vaQueryConfigEntrypoints() fails (because the profile is not supported;
not sure why it lists it, then). So turn the error message into a
verbose message to avoid confusing output.
Fixes: #7347
|
|
|
|
|
|
|
|
|
|
|
| |
This shouldn't really matter, but it's probably best to avoid.
vo_wayland_control would execute set_cursor_visibility while wl->pointer
existed but it didn't check if wl->pointer_id existed. So
wl_pointer_set_cursor would be set to a null surface with an id of 0.
Instead, just wait until we have an actual, non-zero pointer id so that
the cursor is set with the correct, actual id and not a fictious 0 id.
This ensures that the pointer isn't set until it enters the wl_surface
which is what we want.
|
|
|
|
| |
Fixes #7195
|
|
|
|
|
|
|
|
| |
at the time of the initial dpi query the window is not instantiated yet.
we use a proper fallback in that case, eg the target configured screen
or the main screen if none is set.
also change some weird oversight and a small optimisation.
|
|
|
|
|
| |
Follow up to commit a58585d5e063. It turned out that the OSX backend
needs this.
|
|
|
|
|
|
|
| |
Theoretically possible (and quite unlikely due to the small texture
size). The code was originally written with the assumption that texture
allocations can't fail, and it was never updated out of laziness.
Untested.
|
|
|
|
|
| |
More than one option may change at the same time so don't break out of
this loop.
|
|
|
|
|
|
|
|
|
| |
It turns out that gnome wayland still has very serious issues that make
it unusable for playback with mpv. Other compositors mostly behave fine
(Plasma is just missing feature but it's not seriously broken), so GNOME
gets the special honor of having a warning printed out. The only
solution for GNOME users at this time of writing is to either use the
Xorg session or use another wayland compositor.
|
|
|
|
| |
This reverts commit a6d8e9b7ff0166ee6db69c41c0cfc319e03f4c80.
|
|
|
|
|
|
|
| |
I'm sick of mpv being accused of not doing it right.
You can't do it right on Wayland? Long live X11.
Fixes: #7307
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the distant past, the cuviddec backed copy hwaccel could be
configured directly using lavc options. However, since that time,
we gained support for automatic hw ctx creation which ended up
bypassing the lavc options.
Rather than trying to find a way to pass those options again, a
better idea is to make the 'cuda-decode-device' option, used by
the interop hwaccels, work for the copy hwaccels too.
And that's pretty simple: we have to add a create function that
checks the option and passes it on to ffmpeg.
Note that this does require a slight re-jig to the configuration
flags, as we now have a scenario where we want to build with support
for the cuda copy hwaccels but not the interop ones. So we need
a distinct configuration flag for that combination.
Fixes #7295.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In vaapi 1.1.0 (which confusingly is libva release 2.1.0), they
introduced a new surface export API that is more efficient, and
we've been supporting that and the old API ever since (Feb 2018).
If we drop support for the old API, we can do some fairly nice cleanup
of the code.
Note that the pkgconfig entries are explicitly versioned by the API
version and not the library version. I confirmed the upstream pkgconfig
files.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As we are less and less interested in vpdpau, with nvdec and vaapi
being better choices in general on nvidia and AMD respectively, we
might consider removing direct_mode, where we bypass the vdpau
mixer and work directly with yuv textures. Normally, working with
yuv textures would be great, but vdpau built in an assumption that
all frames are delivered as separate fields, causing us to have
to re-interleave them.
nvidia then introduces a new OpenGL extension that can return the
yuv frames as frames, but we can't just unconditionally switch to
that as we'd want to keep supporting older hardware where the drivers
are no longer getting new features. The end result is that we
wouldn't be able to get rid of the old code paths.
Removing direct_mode means we always use the mixer, and work with
rgba frame textures. There are some theoretical limitations to
this, but in practice they probably don't matter much - unsupported
colourspaces don't matter because without 10bit decoding support,
we can't use them anyway, and apparently we're not doing separate
chroma scaling these days, so scaling the rbga doesn't really lose
anything (and the vdpau hq scaling option remains available).
|
|
|
|
|
|
| |
GCC 9.2 warns about this. It was always a bit sketchy, so get rid of it.
VK_F10 generates WM_SYSKEYDOWN, so it only needs to be handled in the
WM_SYSKEYDOWN case.
|
|
|
|
|
|
|
|
|
| |
in certain circumstances the video was not redrawn even when the size
or the backing scale factor changed. this could lead to a lower
resolution output than intended.
now it redraws the video when screen properties or the window size
changes.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add an "auto-safe" mode, mostly triggered by Ubuntu's nonsense to force
hwdec=vaapi in the global config file in their mpv package. But to be
honest it's probably something more people want.
This is implemented as explicit whitelist. On Windows, HEVC/Intel is
sometimes broken, but it's still whitelisted, and in theory we'd need a
detailed whitelist of device names etc. (like for example browsers tend
to do). On OSX, videotoolbox is a pretty bad choice, but unfortunately
the only one, so it's whitelisted too. There may be a larger number of
hwdec wrappers that work anyway, and I'm for example ignoring Android.
|
|
|
|
|
| |
This was added in libplacebo v1.29.0 and allows making resizes slightly
smoother for clients that already handle resize events (such as mpv).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently there are two different options for controlling which
screen an mpv window goes onto: --fs-screen and --screen. The former
explicitly only controls which scree |