| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
This was never implemented so in cases where the compositor didn't have
support for the underlying format, the window would just be black and
quite unhelpful. Well it turns out that fixing this is actually really
easy because mpv has reconfig2 which returns the entire mp_image on
every reconfig. We can just use that mp_image to try and obtain the
format and modifier pair and then use that to check against what we know
the compositor supports. If there are any problems, error out
gracefully. Some code duplication with the vaapi/drmprime importers, but
it's probably better to keep these separate. Fixes #11198 and fixes #11664
|
|
|
|
|
|
|
| |
It makes more sense as an option at this point. Also libdrm is not
optional at all. You have to get a drm format and modifier for this to
even work (the VO will just fail without DRM). Just hard require it and
remove the guards. vaapi can remain optional.
|
|
|
|
|
|
|
|
|
| |
mpv has never used this because we never really seemed to need it, but
it actually has a purpose. This informs the compositor of the actual
dimensions of the mpv window and avoids errors with sizes not matching
(particularly with weston). It's a better way to fix the "maximizing
causing an error on weston" issue since it also works for dmabuf-wayland
(which always had this problem).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original reason for this commit was to prevent a compositor error on
weston when going into the maximized state. The configured dimensions of
mpv didn't match its actual size and Weston is super strict about this
so it threw a compositor error which is fatal. It only happened in
opengl and this seemed like an OK workaround, so I went with this.
However, there's actually a far easier way to solve this problem and we
don't need this anymore. This has the benefit of avoiding a harmless
warning message that appears with gpu-next on opengl. The next commit is
the proper solution. Closes #10324.
This reverts commit 661b5542de21d46d4d7c4693e564f4eec0526812.
|
|
|
|
| |
*sigh*
|
|
|
|
|
|
|
|
|
| |
The implementation was copied from vo_gpu/vo_gpu_next but fundamentally
it doesn't make sense for this VO. Hardware decoding is not optional in
vo_dmabuf_wayland. We should be sure to request and load all supported
formats in the preinit and fail if there are any problems. There should
be no functional change from before, but it's more conceptually correct
this way.
|
|
|
|
| |
Fixes a segfault with --force-window=immediate.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds osd support via shm buffers using a similar approach that the
normal buffers do, but it differs in a few key areas. One thing to note
is that sway and weston actually handle this extremely differently which
required all the abstractions here. In particular, weston does not cope
well with destroying the wl_buffer from shm outside of the release
handler at all (i.e. it segfaults). The workaround here is to simply
attach a NULL to the osd surface and do a surface commit before we
destroy the buffers. This is reasonable enough and seems to work well
although it's pretty weird. Sway is more straightforward although it
actually releases the osd buffer when the window goes out of sight.
Also, I found that it doesn't always release every buffer before you
close it unlike weston seems to do which is part of the reason all this
bookkeeping is required. I don't know if there's any other compositor
out there that can possibly handle vo_dmabuf_wayland right now, but
suffering through these two is good enough for now I think.
|
|
|
|
|
|
| |
Otherwise, we could fail and skip to uninit without initalizing this
which then will segfault because the list is null and accessed while
trying to destroy buffers.
|
|
|
|
|
|
| |
It's entirely pointless. Not having viewport is already a fatal error
for this VO as it cannot possibly work without that protocol. Just drop
all these redundant if's.
|
|
|
|
|
|
| |
make sure that fwrite is error checked. and if any data was still
remaining on the buffer, it will be flushed - and errors checked - via
the fclose() call below.
|
|
|
|
| |
regression from de7f4fb1e
|
|
|
|
| |
Fixes crash when compositors advertise xdg_toplevel version >= 5
|
|
|
|
|
|
|
| |
mpv already guesses when the window is hidden so plugging in a proper
event that actually tells us this is really trivial. Note that there's
some redundancy with setting wl->hidden in a few spots, but nothing can
really be done about that as long as the crappy hack is still in place.
|
|
|
|
|
|
| |
This protocol no longer requires us to draw a separate cursor surface
and all of that horrible stuff. We can just ask the compositor for the
default cursor instead since that's literally all mpv cares about.
|
|
|
|
|
|
|
|
|
|
| |
In case there are no packets from demuxer we cannot send EAGAIN, because
we will not proceed and get stuck with one frame in queue and never
output it. Just respect avcodec_receive_frame ret code and act
accordingly. The only case to care about is EOF when we have to drain
already queued frames.
Fixes playback of 1-2 frame videos.
|
|
|
|
|
|
| |
There is no reason to prefer dxva2. I believe it was mistake from
initial commit that added the hwdec list that has been propagated
through years.
|
|
|
|
|
|
|
| |
It can happen during initialization and of course nothing good will
happen if we let this go through (i.e. segfault). Return and wait for
geometry to finish setting up in the wayland stuff before doing the
initial resize.
|
|
|
|
|
|
|
|
|
| |
Very dumb. I can't remember if it was always like this or if I broke it
at some point, but clearly each wl_output should just be freed in
remove_output. Freeing it if it happens to be wl->current_output only
works for that one monitor, so remove that whole line. This has to
happen before we close the wayland connection so reorder the uninit a
little bit.
|
|
|
|
|
|
|
|
|
|
|
|
| |
--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).
|
|
|
|
|
|
|
|
|
|
|
| |
4502522a7aee093c923e79a65e4684ea2634af30 changed the way mpv handled and
saved cached files. In particular, it made a separate boolean option for
actually enabling cache and left the *-dir options as purely just a path
(i.e. having a dir set didn't mean you save cache). This technically
regressed people's configs, so let's just turn the cache on by default.
Linux users already expect random stuff in ~/.cache and well everyone
else can just live with some files possibly appearing in their config
directory.
|
|
|
|
| |
I goofed this up.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add an option for allowing pointer events to pass through the mpv
window. This could be useful in cases where a user wants to display
transparent images/video with mpv and interact with applications beneath
the window. This commit implements this functionality for x11 and
wayland. Note that whether or not this actually works likely depends on
your window manager and/or compositor. E.g. sway ignores pointer events
but the entire window becomes draggable when you float it (nothing under
the mpv window receives events). Weston behaves as expected however so
that is a compositor bug. Excuse the couple of completely unrelated
style fixes (both were originally done by me).
|
|
|
|
| |
VOCTRL is processed on VO thread.
|
|
|
|
|
| |
Instead copy the data on-demand when VOCTRL_PERFORMANCE_DATA is
requested.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Suggested by @sfan5. Naturally, "no" disables all drag and drop
behavior.
|
|
|
|
|
|
|
|
|
|
| |
Notes:
- converts the (image) write() api to filenames, because using avio
with FILE* is a pain.
- adds more debug logs for screenshots.
build: rename av1 dependency to avif_muxer
wscript: unify lavf dependency with meson
|
|
|
|
|
| |
I couldn't work out the correct syntax, but NRK0 pointed out an example
of where we'd done it elsewhere in the codebase.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Today, the only way to make mpv consider multiple hwdecs and pick the
first one that works is to use one of the `auto` modes. But the list
that is considered in those cases is hard-coded. If the user wants to
provide their own list, they are out of luck.
And I think that there is now a significant reason to support this -
the new Vulkan hwdec is definitely not ready to be in the auto list,
but if you want to use it by default, it will not work with many codecs
that are normally hardware decodable (only h.264, hevc and av1 if you
are very lucky). Everything else will fall back to software decoding.
Instead, what you really want to say is: use Vulkan for whatever it
supports, and fall back to my old hwdec for everything else.
One side-effect of this implementation is that you can freely mix
hwdec names and special values like `auto` and `no`. The behaviour will
be correct, so I didn't try and prohibit any combinations. However,
some combinations will be silly - eg: sticking any further values after
`no` will result in them being ignored. On the other hand, a
combination like `vulkan,auto` could be very useful as that will use
Vulkan if possible, and if not, run the normal auto routine.
Fixes #11797
|
|
|
|
| |
POLLERR is only returned in `.revents` and is ignored in `.events`
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
this changes mp_image_new_ref() to handle allocation failure itself
instead of doing it at its many call-sites (some of which never checked
for failure at all).
also remove MP_HANDLE_OOM() from the call sites since this is not
necessary anymore.
not all the call-sites have been touched, since some of the caller might
be relying on `mp_image_new_ref(NULL)` returning NULL.
Fixes: https://github.com/mpv-player/mpv/issues/11840
|
|
|
|
| |
mediacodec_embed is a `vo` and not a `hwdec`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when vo_drm_init() fails inside of preinit(), uninit() will be called as
part of cleanup with vo->drm being NULL and thus `drm->fd` would lead to
null dereference.
and since vo_drm_uninit() closes drm->fd, destroy_framebuffer() ends up
using a closed fd.
according to the drm-gem manpage [0]:
> If you close the DRM file-descriptor, all open dumb-buffers are
> automatically destroyed.
so remove the destroy_framebuffer() loop entirely, which fixes both the
issues.
[0]: https://www.systutorials.com/docs/linux/man/7-drm-gem/
|
| |
|
|
|
|
|
|
| |
Fixes crashes when hwdevice failed to create.
Fixes: #11769
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I originally left `drmprime_overlay` as higher priority because
`drmprime` was new, and because I didn't have any hardware where both
worked (only one or the other) so I couldn't compare relative
performance, and if only one worked, the priority didn't matter.
But with time and more usage, we've reached a point where we can say we
would recommend using `drmprime` in situations where both work, and
we've also been able to identify hardware where both do indeed work and
it seems that `drmprime` is more reliable.
So, let's flip them.
|
|
|
|
| |
For better or worse.
|
|
|
|
|
| |
Adds the missing upstream values that were exposed by the new gamut
mapping API.
|
|
|
|
|
|
| |
It was done once before but later reverted for testing reasons. This
time it's permanent though since I can test this VO on ARM and with an
up to date system.
|
|
|
|
|
| |
1.27 would have been nicer but ubuntu 22.04 is on 1.25 so we'll just
compromise.
|
|
|
|
| |
This lets us remove some ifdefs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using a display-* video-sync mode, it is possible for buffers with
a matching id to already have an image associated with them (i.e. the
compositor hasn't released it yet). Previously, it was thought that we
could just unref, return null, and make a new buffer but this eventually
leads to a fatal error that originates from libwayland itself which
stops playback. Admittedly, the reason for the error is a bit nebulous
but likely it seems to be some kind of mismatch between dmabuf params
and the associated image with the buffer.
However, we can simplify this process greatly. Instead when the
previously mentioned edge case happens, the old image can simply be
freed and we give the buffer the new image. This saves creating a new
buffer and also avoids that nasty libwayland error. A nice win-win all
around. Fixes #11773.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vo_dmabuf_wayland has a pool of wl_buffers that it cycles through when
drawing frame. There needs to be at least some minimum number otherwise
a flickering artifact occurs where old frames are mistakenly repeated.
When using display-resample and other similar modes, it seems more
buffers are required (more drawing happens so it makes sense) and the
current minimum of 8 isn't good enough. Let's just bump this to 15. It's
also a random ad hoc number, but as far as I know there's not really a
way to predict how many buffers a random video may need. From testing,
it works fine and overall 15 is still a tiny amount of objects to create
considering the lifetime of a video, so we'll just go with this.
|
|
|
|
|
|
|
|
|
|
|
| |
Some platforms (wayland) apparently have a lot of trouble with drag and
drop. The default behavior is still the same which is basically obeying
what we get from the window manager/compositor, but the --drag-and-drop
option allows forcibly overriding the drag and drop behavior. i.e. you
can force it to always replace the playlist or append at the end. This
only implements this in X11 and Wayland but in theory windows and macos
could find this option useful (both hardcode the shift key for
appending). Patches welcome.
|
|
|
|
|
|
|
|
| |
In data_offer_actions, it's possible to get the
WL_DATA_DEVICE_MANAGER_DND_ACTION_NONE action which would set
wl->dnd_action to DND_APPEND (did nothing in practice) but also log a
message which is confusing and misleading. Instead, just ignore and
don't do anything when we get this case.
|
|
|
|
|
|
| |
This is not technically necessary, because we never touch the fd again
after passing to cuda, but having it there could lead to future code
accidentally using it.
|
|
|
|
|
|
| |
All hwdecs should respect the probing flag and demote their lgoging to
verbose level, so that initialisation failures during probing do not
spam the user. I forgot to do this for the Vulkan hwdec.
|
|
|
|
|
|
|
|
|
|
|
| |
The dmabuf-wayland vo has a stub ra implementation that doesn't
have a swapchain. That means that it's currently not safe to call
ra_vk_ctx_get on that ra_ctx, but it must be safe to call on all ra
implementations as this is how we discover if it is a vulkan ra.
This hasn't been an issue before because no Vulkan code paths would be
triggered when using dmabuf-wayland, but with the new vulkan hwdec, it
becomes possible to trigger when hwdecs are probed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The libplacebo sync abstraction is deprecated and we should be using
the more explicit Vulkan semaphore helpers instead. This means that
more of the book keeping moves to our side, but it's not too bad.
There are two main things going on here:
1. After a lot of back and forth, I decided to write the new code with
timeline semaphores to streamline things, and that also means all
the variables are separate - which makes the #ifdefs easier to read.
Which is important because:
2. While pl_sync owned the exported fd/handle, pl_vulkan_sem does not,
so we are responsible for managing them. That means reversing the
previous logic - we now can pass an original fd to CUDA and never
think about it again, while we have to clean up a Win32 Handle
because CUDA will not take ownership.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
AV1 support in Vulkan is extremely bleeding edge - to the point that
the extension is not present in official Khronos releases, but it has
a reserved identifier and we can look it up with a string literal for
now.
This will be skipped and ignored if the driver doesn't support it, so
it's safe if/when the name changes later (it'll just never be activated
in that case).
|
|
|
|
| |
forgotten in 085f3e31a091daf7d6649508b162cfcde826702a
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I originally wrote this trying to avoid doing an explicit version check
on the headers, but it just makes things more confusing, and the
requirements harder to understand.
So, Vulkan interop now takes a dependency on the header release where
they finalised the video decode headers. VK_EXT_descriptor_buffer was
added in 1.3.235, so that's covered as well.
Along the way I fixed a bug in the waf build where it was depending
on libplacebo-next instead of libplacebo-decode.
|
|
|
|
| |
It is not needed at all.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|