mpv
mpv copied to clipboard
mpv-player
Distorted subtitles in full screen while using vo=dmabuf-wayland
Important Information
Provide following Information:
- mpv version: 0.38.0
- Linux Distribution and Version: Arch Linux (with KDE Plasma)
- Source of the mpv binary: official distro repository
- Window Manager and version: Kwin 6.0.4
- GPU model, driver and version: Intel HD520, Mesa 24.0.5
- Possible screenshot or video of visual glitches:
Reproduction steps
On Linux w/ Wayland play video file with subtitles (tried .ass and .srt) with --vo=dmabuf-wayland parameter. Enter full screen, don't move your mouse nor have any OSC elements displayed (like console). Wait for subtitles to appear.
Expected behavior
Subtitles should be displayed correctly.
Actual behavior
Subtitles are distorted and unreadable as seen on the screenshot above. Happens only when no OSC is present on screen, meaning subtitles are temporarily corrected instantaneously whenever mouse is moved or key pressed. Does not happen at all when windowed.
Log file
I'm not able to reproduce. Do you have a sample file?
I tried various video and subtitle files from different sources and problem occurs with all of them for me, so files certainly are not to blame here but something with my configuration.
Do you use Plasma 6 as well?
Can you try running Kwin without direct scan out? Idk how to achieve that but running with a software cursor should implicitly disable direct scan out. Set KWIN_FORCE_SW_CURSOR=1 in your environment before launching Kwin
Can confirm, on fedora 40/plasma 6.
Things I noticed on two devices, one intel the other ryzen:
- Happens more often at odds horizontal resolutions or window sizes, as in resolution that ends on a odd number.
- Full screen at a 1080p display is safe, but full screen at 768p is not.
- OSD elements are affected.
- The distortion only appears on the first 'sample' text, the subsequent text is rendered properly. If there's a pause on dialogue and there's no text for a few seconds the next text on screen will be affected.
- Resizing the window will show the distortion rotating until is straight once again.
Can either of you confirm if it happens on another compositor like mutter or weston? I don't have a 768p screen.
Gnome46/Mutter seems unaffected. And to clarify it also happens on 1080p displays at lower window sizes, its just that 1080p at fullscreen is safe, tested with autofit=1335. For reference, 1305 is safe.
KWIN_FORCE_SW_CURSOR=1
That didn't change anything.
And it is in fact 768p screen.
@meelten: What if you try without aligning stride to 16?
diff --git a/video/out/vo_dmabuf_wayland.c b/video/out/vo_dmabuf_wayland.c
index 35a4dac464..f34762c78e 100644
--- a/video/out/vo_dmabuf_wayland.c
+++ b/video/out/vo_dmabuf_wayland.c
@@ -455,7 +455,7 @@ static void create_shm_pool(struct vo *vo)
struct vo_wayland_state *wl = vo->wl;
struct priv *p = vo->priv;
- int stride = MP_ALIGN_UP(vo->dwidth * 4, 16);
+ int stride = vo->dwidth * 4;
size_t size = vo->dheight * stride;
int fd = vo_wayland_allocate_memfd(vo, size);
if (fd < 0)
From image you posted it is clear that stride is ignored.
EDIT:
Is this new issue? There were some changes in this area, but quite some time ago. https://invent.kde.org/plasma/kwin/-/merge_requests/4219
- int stride = MP_ALIGN_UP(vo->dwidth * 4, 16);
- int stride = vo->dwidth * 4;
Don't really understand what this change means, but it did fix the distortion or at the very least can't reproduce it anymore.
That align was cargoculted from wlshm. Does --vo=wlshm have the same problem by any chance?
With --vo=wlshm I can't find any distortion during playback at any resolution. Curiously, a very similar distortion is visible in both the text and the video while resizing the window with the mouse.
Just a wild guess, but does anything change if we use the actual correct number for the align?
diff --git a/video/out/vo_dmabuf_wayland.c b/video/out/vo_dmabuf_wayland.c
index be8b0f1272..ae2cbab940 100644
--- a/video/out/vo_dmabuf_wayland.c
+++ b/video/out/vo_dmabuf_wayland.c
@@ -455,7 +455,7 @@ static void create_shm_pool(struct vo *vo)
struct vo_wayland_state *wl = vo->wl;
struct priv *p = vo->priv;
- int stride = MP_ALIGN_UP(vo->dwidth * 4, 16);
+ int stride = MP_ALIGN_UP(vo->dwidth * 4, MP_IMAGE_BYTE_ALIGN);
size_t size = vo->dheight * stride;
int fd = vo_wayland_allocate_memfd(vo, size);
if (fd < 0)
diff --git a/video/out/vo_wlshm.c b/video/out/vo_wlshm.c
index 0b63426a23..a0d5ba1dd4 100644
--- a/video/out/vo_wlshm.c
+++ b/video/out/vo_wlshm.c
@@ -85,7 +85,7 @@ static struct buffer *buffer_create(struct vo *vo, int width, int height)
uint8_t *data;
struct buffer *buf;
- stride = MP_ALIGN_UP(width * 4, 16);
+ stride = MP_ALIGN_UP(width * 4, MP_IMAGE_BYTE_ALIGN);
size = height * stride;
fd = vo_wayland_allocate_memfd(vo, size);
if (fd < 0)
If not, we could try removing it all together. dmabuf-wayland shouldn't need it since AFAIK, the align is for use with swscale (which dmabuf-wayland doesn't use).
Do I need re-compile to check this?
Also confirm that there is no issue with wlshm.
Dudemanguy removed the down-upstream:plasma label
Why? I don't see anything wrong in mpv. kwin is ignoring stride set by wl_shm_pool_create_buffer. Indeed stride could be set to w*4 to avoid this bug in kwin, but it should be reported and fixed upstream anyway.
the actual correct number for the align
I don't think this is "correct" number in case of OSD.
I'm not sure if it makes sense to align the stride in the first place for shm buffers though.
Fair, doesn't change the fact it is upstream bug and we are wasting resources by even diagnosing it. mpv did nothing wrong.
Yeah I guess it would be best if someone reported this to kwin regardless.