Bug 445346 - GStreamer with waylandsink in KDE Plasma Wayland session: Video doesn't update (works in GNOME or using Weston)
Summary: GStreamer with waylandsink in KDE Plasma Wayland session: Video doesn't updat...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: 5.23.2
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 448470 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-11-11 16:24 UTC by Michael Weghorn
Modified: 2022-02-01 15:12 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Screencast showing the differing behaviour between KWin in a Plasma Wayland session and in Weston (1.08 MB, video/x-matroska)
2021-11-11 16:24 UTC, Michael Weghorn
Details
Screencast showing differing behaviour between KWin in a Plasma Wayland session and in Weston (1.97 MB, video/x-matroska)
2021-11-11 17:02 UTC, Michael Weghorn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Weghorn 2021-11-11 16:24:42 UTC
Created attachment 143459 [details]
Screencast showing the differing behaviour between KWin in a Plasma Wayland session and in Weston

SUMMARY

When using GStreamer's "waylandsink" to play a video, the video does not update when run in a KDE Plasma Wayland session using KWin as Wayland compositor. It works fine in a GNOME session or when using a nested Weston instead.
(Audio is updated just fine, but the image seems "frozen"/stuck.)


STEPS TO REPRODUCE
1. make sure that gstreamer-plugins bad and the gst-launch-1.0 command are available
    * e.g. in Debian testing, packages "gstreamer1.0-tools" and "gstreamer1.0-plugins-bad" need to be installed
2. in a Plasma Wayland session, run this command:
    gst-launch-1.0 -v videotestsrc ! waylandsink
3. look at the video that is shown

OBSERVED RESULT

A test video shows up, but it looks like a static image, there are no visible updates.

EXPECTED RESULT

The rectangle at the bottom right should update, the "black and white dots" should be moving.


SOFTWARE/OS VERSIONS
Operating System: Debian GNU/Linux
KDE Plasma Version: 5.23.2
KDE Frameworks Version: 5.86.0
Qt Version: 5.15.2
Kernel Version: 5.14.0-2-amd64 (64-bit)
Graphics Platform: Wayland
Processors: 12 × Intel® Core™ i7-9850H CPU @ 2.60GHz
Memory: 62.4 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 630

ADDITIONAL INFORMATION

The expected behaviour can be seen e.g. by:
* running the same command inside Weston instead (screencast which shows both, KWin and Weston behaviour is attached)
* using "glimagesink" instead of "waylandsink", by running this command:
    gst-launch-1.0 videotestsrc ! glimagesink.

The actual/original use case where I came across this is LibreOffice, which also uses "waylandsink" for video Playback in Impress presentations (added in LibreOffice commit https://git.libreoffice.org/core/+/9d18bc40416b651340804f44ba5fae65f3bbbcfa%5E%21 for the gtk3 variant; I am currently looking at this for the qt5/kf5/qt6 variant, since the "qwidgetvideosink" which is currently used for the qt5/kf5 variants is no longer under development and will possibly not be ported to Qt 6).
Comment 1 Michael Weghorn 2021-11-11 17:02:15 UTC
Created attachment 143461 [details]
Screencast showing differing behaviour between KWin in a Plasma Wayland session and in Weston

This is an updated screencast, now actually running the same command in Weston as well, and showing that glimagesink works:

* first shows that waylandsink doesn't work as expected in "default" Plasma Wayland session
* then shows that waylandsink works in Weston
* then shows that glimagesink works in "default" Plasma Wayland session as well

(first version was using wrong command from bash history, sorry for that)
Comment 2 David Redondo 2021-11-12 11:05:30 UTC
Does not happen when using QPainter compositing
Comment 3 Bug Janitor Service 2021-11-12 15:22:19 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwayland-server/-/merge_requests/322
Comment 4 Vlad Zahorodnii 2021-11-16 07:27:56 UTC
Git commit 9aa436dc48f12e7ab4cb8fc9f9a06266b3ea1a1a by Vlad Zahorodnii.
Committed on 16/11/2021 at 07:24.
Pushed by vladz into branch 'master'.

Calculate correct surface-to-buffer matrix with only upscaled viewport

Currently, if a wp_viewport upscales the surface but doesn't set the
source rectangle, the surface-to-buffer matrix will be calculated
incorrectly.

If the source rect is not set, we need to calculate the source size
based on the buffer size and compare it with the destination size. If
the two are not the same, add a scale transform.

M  +11   -2    src/server/surface_interface.cpp

https://invent.kde.org/plasma/kwayland-server/commit/9aa436dc48f12e7ab4cb8fc9f9a06266b3ea1a1a
Comment 5 Michael Weghorn 2021-11-17 09:23:16 UTC
Thanks a lot for the quick fix!

(In reply to Michael Weghorn from comment #0)
> The actual/original use case where I came across this is LibreOffice, which
> also uses "waylandsink" for video Playback in Impress presentations (added
> in LibreOffice commit
> https://git.libreoffice.org/core/+/
> 9d18bc40416b651340804f44ba5fae65f3bbbcfa%5E%21 for the gtk3 variant; I am
> currently looking at this for the qt5/kf5/qt6 variant, since the
> "qwidgetvideosink" which is currently used for the qt5/kf5 variants is no
> longer under development and will possibly not be ported to Qt 6).

When retesting this, it turned out that the sample program as well as the LibreOffice case works now, but only when using the gtk3 variant of LibreOffice, not when using the Qt one, which looks like another issue somewhere in the KDE/Qt stack. I've created follow-up bug 445631 with a new sample program that still has issues, but works in Weston.
Comment 6 Vlad Zahorodnii 2022-01-19 14:03:31 UTC
*** Bug 448470 has been marked as a duplicate of this bug. ***
Comment 7 Robert Mader 2022-02-01 11:34:16 UTC
Just tested on 5.23.5 and unfortunately the fix is not yet backported. Would be very glad if it made it into 5.23.6 :)
Comment 8 Nate Graham 2022-02-01 14:35:35 UTC
There isn't going to be a 5.23.6 (non-LTS Plasma versions only get five bugfix releases). So unless your distro's packagers backport it, we'll have to wit until Plasma 5.24 in a week or so.
Comment 9 Robert Mader 2022-02-01 15:12:46 UTC
(In reply to Nate Graham from comment #8)
> There isn't going to be a 5.23.6 (non-LTS Plasma versions only get five
> bugfix releases). So unless your distro's packagers backport it, we'll have
> to wit until Plasma 5.24 in a week or so.

Thanks for pointing that out!