mirror/mpv
0
0
Fork 0
mirror of https://github.com/mpv-player/mpv.git synced 2024-09-20 20:03:10 +02:00
Code
a890d7be2a
mpv/video/out/vo_dmabuf_wayland.c

572 lines
16 KiB
C
Raw Normal View History

vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
/*
* This file is part of mpv.
*
* mpv is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* mpv is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
*/
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
#include <unistd.h>
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
#include "config.h"
vo_dmabuf_wayland: fix DRM builds with no VAAPI Building on DRM platform without VAAPI broke because of misuse of HAVE_VAAPI with #ifdef in place of #if. Also, the hwcontext_drm.h header is not required for VAAPI builds, only DRM builds.
2022-10-27 11:19:07 +02:00
#if HAVE_VAAPI
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
#include <va/va_drmcommon.h>
vo_dmabuf_wayland: fix DRM builds with no VAAPI Building on DRM platform without VAAPI broke because of misuse of HAVE_VAAPI with #ifdef in place of #if. Also, the hwcontext_drm.h header is not required for VAAPI builds, only DRM builds.
2022-10-27 11:19:07 +02:00
#endif
#if HAVE_DRM
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
#include <libavutil/hwcontext_drm.h>
#endif
#include "common/global.h"
#include "gpu/hwdec.h"
#include "gpu/video.h"
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
#include "mpv_talloc.h"
#include "present_sync.h"
#include "video/mp_image.h"
#include "vo.h"
#include "wayland_common.h"
#include "wldmabuf/ra_wldmabuf.h"
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
vo_dmabuf_wayland: fix DRM builds with no VAAPI Building on DRM platform without VAAPI broke because of misuse of HAVE_VAAPI with #ifdef in place of #if. Also, the hwcontext_drm.h header is not required for VAAPI builds, only DRM builds.
2022-10-27 11:19:07 +02:00
#if HAVE_VAAPI
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
#include "video/vaapi.h"
vo_dmabuf_wayland: fix DRM builds with no VAAPI Building on DRM platform without VAAPI broke because of misuse of HAVE_VAAPI with #ifdef in place of #if. Also, the hwcontext_drm.h header is not required for VAAPI builds, only DRM builds.
2022-10-27 11:19:07 +02:00
#endif
vo_dmabuf_wayland: use single-pixel-buffer-v1 The new single-pixel-buffer protocol is designed to optimize the case for using a solid color as an underlay wl_surface. It works the same as the wl_shm 1x1 pixel trick currently used, but it allows the compositor to make optimizations with more certainty than the wl_shm trick.
2022-11-16 02:52:56 +01:00
// Generated from wayland-protocols
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
#include "generated/wayland/linux-dmabuf-unstable-v1.h"
#include "generated/wayland/viewporter.h"
vo_dmabuf_wayland: use single-pixel-buffer-v1 The new single-pixel-buffer protocol is designed to optimize the case for using a solid color as an underlay wl_surface. It works the same as the wl_shm 1x1 pixel trick currently used, but it allows the compositor to make optimizations with more certainty than the wl_shm trick.
2022-11-16 02:52:56 +01:00
#if HAVE_WAYLAND_PROTOCOLS_1_27
#include "generated/wayland/single-pixel-buffer-v1.h"
#endif
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
// We need at least enough buffers to avoid a
// flickering artifact in certain formats.
vo_dmabuf_wayland: use a minimum of 15 buffers 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.
2023-06-14 19:00:23 +02:00
#define WL_BUFFERS_WANTED 15
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
enum hwdec_type {
HWDEC_NONE,
HWDEC_VAAPI,
HWDEC_DRMPRIME,
};
struct buffer {
struct vo *vo;
struct wl_buffer *buffer;
struct wl_list link;
struct mp_image *image;
uint32_t drm_format;
uintptr_t id;
};
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
struct priv {
struct mp_log *log;
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
struct mp_rect src;
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
struct mpv_global *global;
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
struct ra_ctx *ctx;
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
struct ra_hwdec_ctx hwdec_ctx;
struct wl_shm_pool *solid_buffer_pool;
struct wl_buffer *solid_buffer;
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
struct wl_list buffer_list;
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
bool destroy_buffers;
enum hwdec_type hwdec_type;
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
};
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
static void buffer_handle_release(void *data, struct wl_buffer *wl_buffer)
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
{
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
struct buffer *buf = data;
if (buf->image) {
mp_image_unrefp(&buf->image);
buf->image = NULL;
}
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
}
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
static const struct wl_buffer_listener buffer_listener = {
buffer_handle_release,
};
#if HAVE_VAAPI
vo_dmabuf_wayland: close file handles when surface export fails file handles may still be opened despite failure
2023-01-26 20:18:17 +01:00
static void close_file_descriptors(VADRMPRIMESurfaceDescriptor desc)
{
for (int i = 0; i < desc.num_objects; i++)
close(desc.objects[i].fd);
}
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
#endif
vo_dmabuf_wayland: close file handles when surface export fails file handles may still be opened despite failure
2023-01-26 20:18:17 +01:00
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
static uintptr_t vaapi_surface_id(struct mp_image *src)
{
uintptr_t id = 0;
#if HAVE_VAAPI
id = (uintptr_t)va_surface_id(src);
#endif
return id;
}
static void vaapi_dmabuf_importer(struct buffer *buf, struct mp_image *src,
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
struct zwp_linux_buffer_params_v1 *params)
{
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
#if HAVE_VAAPI
struct vo *vo = buf->vo;
struct priv *p = vo->priv;
VADRMPRIMESurfaceDescriptor desc = {0};
VADisplay display = ra_get_native_resource(p->ctx->ra, "VADisplay");
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
/* composed has single layer */
int layer_no = 0;
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
buf->id = vaapi_surface_id(src);
VAStatus status = vaExportSurfaceHandle(display, buf->id, VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME_2,
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
VA_EXPORT_SURFACE_COMPOSED_LAYERS | VA_EXPORT_SURFACE_READ_ONLY, &desc);
vo_dmabuf_wayland: improve error handling exporting VA surface 1. check for all error conditions when calling vaExportSurfaceHandle 2. only clean up valid descriptors
2022-11-01 15:51:50 +01:00
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
if (!CHECK_VA_STATUS(vo, "vaExportSurfaceHandle()")) {
vo_dmabuf_wayland: improve error handling exporting VA surface 1. check for all error conditions when calling vaExportSurfaceHandle 2. only clean up valid descriptors
2022-11-01 15:51:50 +01:00
/* invalid surface warning => composed layers not supported */
if (status == VA_STATUS_ERROR_INVALID_SURFACE)
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
MP_VERBOSE(vo, "vaExportSurfaceHandle: composed layers not supported.\n");
goto done;
vo_dmabuf_wayland: improve error handling exporting VA surface 1. check for all error conditions when calling vaExportSurfaceHandle 2. only clean up valid descriptors
2022-11-01 15:51:50 +01:00
}
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
buf->drm_format = desc.layers[layer_no].drm_format;
if (!ra_compatible_format(p->ctx->ra, buf->drm_format, desc.objects[0].drm_format_modifier)) {
MP_VERBOSE(vo, "%s(%016lx) is not supported.\n",
mp_tag_str(buf->drm_format), desc.objects[0].drm_format_modifier);
buf->drm_format = 0;
goto done;
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
}
vo_dmabuf_wayland: improve error handling exporting VA surface 1. check for all error conditions when calling vaExportSurfaceHandle 2. only clean up valid descriptors
2022-11-01 15:51:50 +01:00
for (int plane_no = 0; plane_no < desc.layers[layer_no].num_planes; ++plane_no) {
int object = desc.layers[layer_no].object_index[plane_no];
uint64_t modifier = desc.objects[object].drm_format_modifier;
zwp_linux_buffer_params_v1_add(params, desc.objects[object].fd, plane_no, desc.layers[layer_no].offset[plane_no],
desc.layers[layer_no].pitch[plane_no], modifier >> 32, modifier & 0xffffffff);
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
}
vo_dmabuf_wayland: improve error handling exporting VA surface 1. check for all error conditions when calling vaExportSurfaceHandle 2. only clean up valid descriptors
2022-11-01 15:51:50 +01:00
done:
vo_dmabuf_wayland: close file handles when surface export fails file handles may still be opened despite failure
2023-01-26 20:18:17 +01:00
close_file_descriptors(desc);
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
#endif
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
}
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
static uintptr_t drmprime_surface_id(struct mp_image *src)
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
{
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
uintptr_t id = 0;
#if HAVE_DRM
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
struct AVDRMFrameDescriptor *desc = (AVDRMFrameDescriptor *)src->planes[0];
AVDRMObjectDescriptor object = desc->objects[0];
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
id = (uintptr_t)object.fd;
#endif
return id;
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
}
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
static void drmprime_dmabuf_importer(struct buffer *buf, struct mp_image *src,
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
struct zwp_linux_buffer_params_v1 *params)
{
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
#if HAVE_DRM
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
int layer_no, plane_no;
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
int max_planes = 0;
const AVDRMFrameDescriptor *desc = (AVDRMFrameDescriptor *)src->planes[0];
if (!desc)
return;
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
buf->id = drmprime_surface_id(src);
for (layer_no = 0; layer_no < desc->nb_layers; layer_no++) {
AVDRMLayerDescriptor layer = desc->layers[layer_no];
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
buf->drm_format = layer.format;
max_planes = MPMAX(max_planes, layer.nb_planes);
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
for (plane_no = 0; plane_no < layer.nb_planes; ++plane_no) {
AVDRMPlaneDescriptor plane = layer.planes[plane_no];
int object_index = plane.object_index;
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
AVDRMObjectDescriptor object = desc->objects[object_index];
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
uint64_t modifier = object.format_modifier;
zwp_linux_buffer_params_v1_add(params, object.fd, plane_no, plane.offset,
plane.pitch, modifier >> 32, modifier & 0xffffffff);
}
}
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
#endif
}
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
static intptr_t surface_id(struct vo *vo, struct mp_image *src)
{
struct priv *p = vo->priv;
switch(p->hwdec_type) {
case HWDEC_VAAPI:
return vaapi_surface_id(src);
case HWDEC_DRMPRIME:
return drmprime_surface_id(src);
default:
return 0;
}
}
static struct buffer *buffer_check(struct vo *vo, struct mp_image *src)
{
struct priv *p = vo->priv;
/* Make more buffers if we're not at the desired amount yet. */
if (wl_list_length(&p->buffer_list) < WL_BUFFERS_WANTED)
goto done;
uintptr_t id = surface_id(vo, src);
struct buffer *buf;
wl_list_for_each(buf, &p->buffer_list, link) {
if (buf->id == id) {
vo_dmabuf_wayland: update the image of pending buffers 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.
2023-06-14 19:21:10 +02:00
if (buf->image)
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
mp_image_unrefp(&buf->image);
vo_dmabuf_wayland: update the image of pending buffers 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.
2023-06-14 19:21:10 +02:00
buf->image = src;
return buf;
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
}
}
done:
return NULL;
}
static struct buffer *buffer_create(struct vo *vo, struct mp_image *src)
{
struct vo_wayland_state *wl = vo->wl;
struct priv *p = vo->priv;
struct buffer *buf = talloc_zero(vo, struct buffer);
buf->vo = vo;
buf->image = src;
struct zwp_linux_buffer_params_v1 *params = zwp_linux_dmabuf_v1_create_params(wl->dmabuf);
switch(p->hwdec_type) {
case HWDEC_VAAPI:
vaapi_dmabuf_importer(buf, src, params);
break;
case HWDEC_DRMPRIME:
drmprime_dmabuf_importer(buf, src, params);
break;
}
if (!buf->drm_format) {
mp_image_unrefp(&buf->image);
talloc_free(buf);
zwp_linux_buffer_params_v1_destroy(params);
return NULL;
}
buf->buffer = zwp_linux_buffer_params_v1_create_immed(params, src->params.w, src->params.h,
buf->drm_format, 0);
zwp_linux_buffer_params_v1_destroy(params);
wl_buffer_add_listener(buf->buffer, &buffer_listener, buf);
wl_list_insert(&p->buffer_list, &buf->link);
return buf;
}
static struct buffer *buffer_get(struct vo *vo, struct mp_image *src)
{
/* Reuse existing buffer if possible. */
struct buffer *buf = buffer_check(vo, src);
if (buf) {
return buf;
} else {
return buffer_create(vo, src);
}
}
static void destroy_buffers(struct vo *vo)
{
struct priv *p = vo->priv;
struct buffer *buf, *tmp;
p->destroy_buffers = false;
wl_list_for_each_safe(buf, tmp, &p->buffer_list, link) {
wl_list_remove(&buf->link);
if (buf->image) {
mp_image_unrefp(&buf->image);
buf->image = NULL;
}
if (buf->buffer) {
wl_buffer_destroy(buf->buffer);
buf->buffer = NULL;
}
talloc_free(buf);
}
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
}
vo_dmabuf_wayland: support panscan and panning
2023-01-11 18:04:19 +01:00
static void set_viewport_source(struct vo *vo, struct mp_rect src) {
struct priv *p = vo->priv;
struct vo_wayland_state *wl = vo->wl;
if (wl->video_viewport && !mp_rect_equals(&p->src, &src)) {
wp_viewport_set_source(wl->video_viewport, src.x0 << 8,
src.y0 << 8, mp_rect_w(src) << 8,
mp_rect_h(src) << 8);
p->src = src;
}
}
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
static void resize(struct vo *vo)
{
struct vo_wayland_state *wl = vo->wl;
struct mp_rect src;
struct mp_rect dst;
struct mp_osd_res osd;
vo_dmabuf_wayland: support panscan and panning
2023-01-11 18:04:19 +01:00
struct mp_vo_opts *vo_opts = wl->vo_opts;
wayland: rewrite geometry and scaling handling This is in preparation for fractional scaling support. Basically, redo all the coordinates in wayland so that wl->geometry is equal exactly to what is being put out to the screen (no extra wl->scaling multiplication required). The wl->vdparams variable is also eliminated for simplicity. This changes mpv's behavior on wayland with hidpi scaling but that will be addressed in more detail with the next commit.
2023-01-23 00:06:15 +01:00
const int width = mp_rect_w(wl->geometry);
const int height = mp_rect_h(wl->geometry);
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
if (width == 0 || height == 0)
return;
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
wayland: use bool type for alpha framebuffer tracking ra_ctx_opts.want_alpha and vo_wayland_set_opaque_region's alpha argument are only used as bool but both are ints. Particularly for the function argument, passing a 0 or 1 is confusing - at first glance it looks like you're specifying an alpha value of 0 or 1. Since they're only used as bools, make them bools.
2023-02-27 12:12:09 +01:00
vo_wayland_set_opaque_region(wl, false);
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
vo->dwidth = width;
vo->dheight = height;
vo_dmabuf_wayland: support panscan and panning
2023-01-11 18:04:19 +01:00
// top level viewport is calculated with pan set to zero
vo->opts->pan_x = 0;
vo->opts->pan_y = 0;
vo_get_src_dst_rects(vo, &src, &dst, &osd);
vo_dmabuf_wayland: stop guarding viewport interfaces 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.
2023-07-02 03:36:22 +02:00
wp_viewport_set_destination(wl->viewport, 2 * dst.x0 + mp_rect_w(dst), 2 * dst.y0 + mp_rect_h(dst));
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
various: fix typos Found by codespell
2023-03-27 22:42:17 +02:00
//now we restore pan for video viewport calculation
vo_dmabuf_wayland: support panscan and panning
2023-01-11 18:04:19 +01:00
vo->opts->pan_x = vo_opts->pan_x;
vo->opts->pan_y = vo_opts->pan_y;
vo_get_src_dst_rects(vo, &src, &dst, &osd);
vo_dmabuf_wayland: stop guarding viewport interfaces 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.
2023-07-02 03:36:22 +02:00
wp_viewport_set_destination(wl->video_viewport, mp_rect_w(dst), mp_rect_h(dst));
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
wl_subsurface_set_position(wl->video_subsurface, dst.x0, dst.y0);
vo_dmabuf_wayland: support panscan and panning
2023-01-11 18:04:19 +01:00
set_viewport_source(vo, src);
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
}
static void draw_frame(struct vo *vo, struct vo_frame *frame)
{
struct priv *p = vo->priv;
struct vo_wayland_state *wl = vo->wl;
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
struct buffer *buf;
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
if (!vo_wayland_check_visible(vo) || !frame->current)
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
return;
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
if (p->destroy_buffers)
destroy_buffers(vo);
struct mp_image *src = mp_image_new_ref(frame->current);
buf = buffer_get(vo, src);
vo_dmabuf_wayland: only resize when a new frame is about to be drawn
2023-02-03 19:36:10 +01:00
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
if (buf && buf->image) {
wl_surface_attach(wl->video_surface, buf->buffer, 0, 0);
wl_surface_damage_buffer(wl->video_surface, 0, 0, buf->image->params.w,
buf->image->params.h);
}
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
}
static void flip_page(struct vo *vo)
{
struct vo_wayland_state *wl = vo->wl;
wl_surface_commit(wl->video_surface);
wl_surface_commit(wl->surface);
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
if (!wl->opts->disable_vsync)
vo_wayland_wait_frame(wl);
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
if (wl->use_present)
present_sync_swap(wl->present);
}
static void get_vsync(struct vo *vo, struct vo_vsync_info *info)
{
struct vo_wayland_state *wl = vo->wl;
if (wl->use_present)
present_sync_get_info(wl->present, info);
}
static bool is_supported_fmt(int fmt)
{
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
return (fmt == IMGFMT_DRMPRIME || fmt == IMGFMT_VAAPI);
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
}
static int query_format(struct vo *vo, int format)
{
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
return is_supported_fmt(format);
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
}
static int reconfig(struct vo *vo, struct mp_image_params *params)
{
if (!vo_wayland_reconfig(vo))
return VO_ERROR;
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
// Immediately destroy all buffers if params change.
destroy_buffers(vo);
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
return 0;
}
static void call_request_hwdec_api(void *ctx, struct hwdec_imgfmt_request *params)
{
// Roundabout way to run hwdec loading on the VO thread.
// Redirects to request_hwdec_api().
vo_control(ctx, VOCTRL_LOAD_HWDEC_API, params);
}
static int control(struct vo *vo, uint32_t request, void *data)
{
struct priv *p = vo->priv;
int events = 0;
int ret;
switch (request) {
case VOCTRL_LOAD_HWDEC_API:
vo: hwdec: Pass the ra_ctx to hwdecs instead of just the ra 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.
2022-03-12 19:54:23 +01:00
assert(p->hwdec_ctx.ra_ctx);
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
struct hwdec_imgfmt_request* req = (struct hwdec_imgfmt_request*)data;
if (!is_supported_fmt(req->imgfmt))
return 0;
ra_hwdec_ctx_load_fmt(&p->hwdec_ctx, vo->hwdec_devs, req);
return (p->hwdec_ctx.num_hwdecs > 0);
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
case VOCTRL_RESET:
p->destroy_buffers = true;
return VO_TRUE;
case VOCTRL_SET_PANSCAN:
resize(vo);
return VO_TRUE;
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
}
ret = vo_wayland_control(vo, &events, request, data);
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
if (events & VO_EVENT_RESIZE)
resize(vo);
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
if (events & VO_EVENT_EXPOSE)
vo->want_redraw = true;
vo_event(vo, events);
return ret;
}
static void uninit(struct vo *vo)
{
struct priv *p = vo->priv;
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
destroy_buffers(vo);
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
if (p->solid_buffer_pool)
wl_shm_pool_destroy(p->solid_buffer_pool);
if (p->solid_buffer)
wl_buffer_destroy(p->solid_buffer);
ra_hwdec_ctx_uninit(&p->hwdec_ctx);
if (vo->hwdec_devs) {
hwdec_devices_set_loader(vo->hwdec_devs, NULL, NULL);
hwdec_devices_destroy(vo->hwdec_devs);
}
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
vo_wayland_uninit(vo);
ra_ctx_destroy(&p->ctx);
}
static int preinit(struct vo *vo)
{
struct priv *p = vo->priv;
p->log = vo->log;
p->global = vo->global;
vo_dmabuf_wayland: use special ra_ctx_create_by_name vo_dmabuf_wayland has its own ra and context so it can handle all the different hwdec correctly. Unfortunately, this API was pretty clearly designed with vo_gpu/vo_gpu_next in mind and has a lot of concepts that don't make sense for vo_dmabuf_wayland. We still want to bolt on a ra_ctx, but instead let's rework the ra_ctx logic a little bit. First, this introduces a hidden bool within the ra_ctx_fns that is used to hide the wldmabuf context from users as an option (unlike the other usual contexts). We also want to make sure that hidden contexts wouldn't be autoprobed in the usual ra_ctx_create, so we be sure to skip those in that function. Additionally, let's create a new ra_ctx_create_by_name function which does exactly what says. It specifically selects a context based on a passed string. This function has no probing or option logic is simplified just for what vo_dmabuf_wayland needs. The api/context validations functions are modified just a little bit to make sure hidden contexts are skipped and the documentation is updated to remove this entries. Fixes #10793.
2022-10-27 06:23:49 +02:00
p->ctx = ra_ctx_create_by_name(vo, "wldmabuf");
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
if (!p->ctx)
vo_dmabuf_wayland: goto err instead of returning Returning early is clearly wrong. It should use to goto to cleanup after itself. Also renamed from error_out to err for purely comestic reasons.
2023-01-08 19:19:14 +01:00
goto err;
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
assert(p->ctx->ra);
wayland: error out if essential protocol support is missing Related issue: #10868. While most protocols are in theory optional, a small amount of them are absolutely essential and nothing will work without them. We should make sure to error out in those cases and not try to actually do anything. For wayland support in general, wl_compositor support is obviously required. If there is no wl_surface, you can't do anything. Additionally, vo_wlshm quite obviously requires wl_shm so mark that one as well. vo_dmabuf_wayland needs linux_dmabuf, viewporter, wl_shm, and wl_subcompositor. In practice, these are all very standard protocols and shouldn't be missing but the linked issue above is at least one example where a compositor was stuck on an ancient version of a wayland interface.
2022-11-15 02:06:14 +01:00
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
wl_list_init(&p->buffer_list);
vo_dmabuf_wayland: drop linux-dmabuf-v2 (again) 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.
2023-06-12 21:43:07 +02:00
if (!vo->wl->dmabuf || !vo->wl->dmabuf_feedback) {
MP_FATAL(vo->wl, "Compositor doesn't support the %s (ver. 4) protocol!\n",
wayland: error out if essential protocol support is missing Related issue: #10868. While most protocols are in theory optional, a small amount of them are absolutely essential and nothing will work without them. We should make sure to error out in those cases and not try to actually do anything. For wayland support in general, wl_compositor support is obviously required. If there is no wl_surface, you can't do anything. Additionally, vo_wlshm quite obviously requires wl_shm so mark that one as well. vo_dmabuf_wayland needs linux_dmabuf, viewporter, wl_shm, and wl_subcompositor. In practice, these are all very standard protocols and shouldn't be missing but the linked issue above is at least one example where a compositor was stuck on an ancient version of a wayland interface.
2022-11-15 02:06:14 +01:00
zwp_linux_dmabuf_v1_interface.name);
vo_dmabuf_wayland: goto err instead of returning Returning early is clearly wrong. It should use to goto to cleanup after itself. Also renamed from error_out to err for purely comestic reasons.
2023-01-08 19:19:14 +01:00
goto err;
wayland: error out if essential protocol support is missing Related issue: #10868. While most protocols are in theory optional, a small amount of them are absolutely essential and nothing will work without them. We should make sure to error out in those cases and not try to actually do anything. For wayland support in general, wl_compositor support is obviously required. If there is no wl_surface, you can't do anything. Additionally, vo_wlshm quite obviously requires wl_shm so mark that one as well. vo_dmabuf_wayland needs linux_dmabuf, viewporter, wl_shm, and wl_subcompositor. In practice, these are all very standard protocols and shouldn't be missing but the linked issue above is at least one example where a compositor was stuck on an ancient version of a wayland interface.
2022-11-15 02:06:14 +01:00
}
if (!vo->wl->shm) {
MP_FATAL(vo->wl, "Compositor doesn't support the %s protocol!\n",
wl_shm_interface.name);
vo_dmabuf_wayland: goto err instead of returning Returning early is clearly wrong. It should use to goto to cleanup after itself. Also renamed from error_out to err for purely comestic reasons.
2023-01-08 19:19:14 +01:00
goto err;
wayland: error out if essential protocol support is missing Related issue: #10868. While most protocols are in theory optional, a small amount of them are absolutely essential and nothing will work without them. We should make sure to error out in those cases and not try to actually do anything. For wayland support in general, wl_compositor support is obviously required. If there is no wl_surface, you can't do anything. Additionally, vo_wlshm quite obviously requires wl_shm so mark that one as well. vo_dmabuf_wayland needs linux_dmabuf, viewporter, wl_shm, and wl_subcompositor. In practice, these are all very standard protocols and shouldn't be missing but the linked issue above is at least one example where a compositor was stuck on an ancient version of a wayland interface.
2022-11-15 02:06:14 +01:00
}
if (!vo->wl->video_subsurface) {
MP_FATAL(vo->wl, "Compositor doesn't support the %s protocol!\n",
wl_subcompositor_interface.name);
vo_dmabuf_wayland: goto err instead of returning Returning early is clearly wrong. It should use to goto to cleanup after itself. Also renamed from error_out to err for purely comestic reasons.
2023-01-08 19:19:14 +01:00
goto err;
wayland: error out if essential protocol support is missing Related issue: #10868. While most protocols are in theory optional, a small amount of them are absolutely essential and nothing will work without them. We should make sure to error out in those cases and not try to actually do anything. For wayland support in general, wl_compositor support is obviously required. If there is no wl_surface, you can't do anything. Additionally, vo_wlshm quite obviously requires wl_shm so mark that one as well. vo_dmabuf_wayland needs linux_dmabuf, viewporter, wl_shm, and wl_subcompositor. In practice, these are all very standard protocols and shouldn't be missing but the linked issue above is at least one example where a compositor was stuck on an ancient version of a wayland interface.
2022-11-15 02:06:14 +01:00
}
if (!vo->wl->viewport) {
MP_FATAL(vo->wl, "Compositor doesn't support the %s protocol!\n",
wp_viewporter_interface.name);
vo_dmabuf_wayland: goto err instead of returning Returning early is clearly wrong. It should use to goto to cleanup after itself. Also renamed from error_out to err for purely comestic reasons.
2023-01-08 19:19:14 +01:00
goto err;
wayland: error out if essential protocol support is missing Related issue: #10868. While most protocols are in theory optional, a small amount of them are absolutely essential and nothing will work without them. We should make sure to error out in those cases and not try to actually do anything. For wayland support in general, wl_compositor support is obviously required. If there is no wl_surface, you can't do anything. Additionally, vo_wlshm quite obviously requires wl_shm so mark that one as well. vo_dmabuf_wayland needs linux_dmabuf, viewporter, wl_shm, and wl_subcompositor. In practice, these are all very standard protocols and shouldn't be missing but the linked issue above is at least one example where a compositor was stuck on an ancient version of a wayland interface.
2022-11-15 02:06:14 +01:00
}
vo_dmabuf_wayland: use single-pixel-buffer-v1 The new single-pixel-buffer protocol is designed to optimize the case for using a solid color as an underlay wl_surface. It works the same as the wl_shm 1x1 pixel trick currently used, but it allows the compositor to make optimizations with more certainty than the wl_shm trick.
2022-11-16 02:52:56 +01:00
if (vo->wl->single_pixel_manager) {
#if HAVE_WAYLAND_PROTOCOLS_1_27
p->solid_buffer = wp_single_pixel_buffer_manager_v1_create_u32_rgba_buffer(
vo->wl->single_pixel_manager, 0, 0, 0, UINT32_MAX); /* R, G, B, A */
#endif
} else {
int width = 1;
int height = 1;
int stride = MP_ALIGN_UP(width * 4, 16);
int fd = vo_wayland_allocate_memfd(vo, stride);
if (fd < 0)
vo_dmabuf_wayland: goto err instead of returning Returning early is clearly wrong. It should use to goto to cleanup after itself. Also renamed from error_out to err for purely comestic reasons.
2023-01-08 19:19:14 +01:00
goto err;
vo_dmabuf_wayland: use single-pixel-buffer-v1 The new single-pixel-buffer protocol is designed to optimize the case for using a solid color as an underlay wl_surface. It works the same as the wl_shm 1x1 pixel trick currently used, but it allows the compositor to make optimizations with more certainty than the wl_shm trick.
2022-11-16 02:52:56 +01:00
p->solid_buffer_pool = wl_shm_create_pool(vo->wl->shm, fd, height * stride);
vo_dmabuf_wayland: plug leaking file descriptor from solid buffer pool
2023-01-26 20:15:43 +01:00
close(fd);
vo_dmabuf_wayland: use single-pixel-buffer-v1 The new single-pixel-buffer protocol is designed to optimize the case for using a solid color as an underlay wl_surface. It works the same as the wl_shm 1x1 pixel trick currently used, but it allows the compositor to make optimizations with more certainty than the wl_shm trick.
2022-11-16 02:52:56 +01:00
if (!p->solid_buffer_pool)
vo_dmabuf_wayland: goto err instead of returning Returning early is clearly wrong. It should use to goto to cleanup after itself. Also renamed from error_out to err for purely comestic reasons.
2023-01-08 19:19:14 +01:00
goto err;
vo_dmabuf_wayland: use single-pixel-buffer-v1 The new single-pixel-buffer protocol is designed to optimize the case for using a solid color as an underlay wl_surface. It works the same as the wl_shm 1x1 pixel trick currently used, but it allows the compositor to make optimizations with more certainty than the wl_shm trick.
2022-11-16 02:52:56 +01:00
p->solid_buffer = wl_shm_pool_create_buffer(
p->solid_buffer_pool, 0, width, height, stride, WL_SHM_FORMAT_XRGB8888);
}
if (!p->solid_buffer)
vo_dmabuf_wayland: goto err instead of returning Returning early is clearly wrong. It should use to goto to cleanup after itself. Also renamed from error_out to err for purely comestic reasons.
2023-01-08 19:19:14 +01:00
goto err;
vo_dmabuf_wayland: use single-pixel-buffer-v1 The new single-pixel-buffer protocol is designed to optimize the case for using a solid color as an underlay wl_surface. It works the same as the wl_shm 1x1 pixel trick currently used, but it allows the compositor to make optimizations with more certainty than the wl_shm trick.
2022-11-16 02:52:56 +01:00
wl_surface_attach(vo->wl->surface, p->solid_buffer, 0, 0);
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
vo->hwdec_devs = hwdec_devices_create();
hwdec_devices_set_loader(vo->hwdec_devs, call_request_hwdec_api, vo);
vo: hwdec: Pass the ra_ctx to hwdecs instead of just the ra 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.
2022-03-12 19:54:23 +01:00
assert(!p->hwdec_ctx.ra_ctx);
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
p->hwdec_ctx = (struct ra_hwdec_ctx) {
.log = p->log,
.global = p->global,
vo: hwdec: Pass the ra_ctx to hwdecs instead of just the ra 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.
2022-03-12 19:54:23 +01:00
.ra_ctx = p->ctx,
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
};
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
vo_dmabuf_wayland: load all hwdecs in preinit vo_gpu and vo_gpu_next typically load hwdec interops on demand and vo_dmabuf_wayland naively copied this logic. This is actually wrong however since draw_frame in the VO always inherently relies on hwdec being fully loaded. This can lead to a race condition during startup which happens with --force-window=immediate. Avoid this by simply always loading all the interops. In the case of vo_dmabuf_wayland, this is not really a big deal since there's only vaapi and drmprime to load. Also fixes #10791 (the other half).
2022-10-27 05:21:26 +02:00
ra_hwdec_ctx_init(&p->hwdec_ctx, vo->hwdec_devs, NULL, true);
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
vo_dmabuf_wayland: rewrite around wl_list vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
2023-02-09 21:04:19 +01:00
for (int i = 0; i < p->hwdec_ctx.num_hwdecs; i++) {
struct ra_hwdec *hw = p->hwdec_ctx.hwdecs[i];
if (ra_get_native_resource(p->ctx->ra, "VADisplay")) {
p->hwdec_type = HWDEC_VAAPI;
} else if (strcmp(hw->driver->name, "drmprime") == 0) {
p->hwdec_type = HWDEC_DRMPRIME;
}
}
if (p->hwdec_type == HWDEC_NONE) {
MP_ERR(vo, "No valid hardware decoding driver could be loaded!");
goto err;
}
p->src = (struct mp_rect){0, 0, 0, 0};
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
return 0;
vo_dmabuf_wayland: goto err instead of returning Returning early is clearly wrong. It should use to goto to cleanup after itself. Also renamed from error_out to err for purely comestic reasons.
2023-01-08 19:19:14 +01:00
err:
uninit(vo);
return -1;
vo_dmabuf_wayland: wayland VO displaying dmabuf buffers Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
2022-09-27 18:12:54 +02:00
}
const struct vo_driver video_out_dmabuf_wayland = {
.description = "Wayland dmabuf video output",
.name = "dmabuf-wayland",
.preinit = preinit,
.query_format = query_format,
.reconfig = reconfig,
.control = control,
.draw_frame = draw_frame,
.flip_page = flip_page,
.get_vsync = get_vsync,
.wakeup = vo_wayland_wakeup,
.wait_events = vo_wayland_wait_events,
.uninit = uninit,
.priv_size = sizeof(struct priv),
};
Copy Permalink