Bug 397594 - Kaffeine plays video in a separate window under Wayland
Summary: Kaffeine plays video in a separate window under Wayland
Status: CONFIRMED
Alias: None
Product: kaffeine
Classification: Applications
Component: general (show other bugs)
Version: 2.0.17
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Mauro Carvalho Chehab
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-18 18:42 UTC by Patrick Silva
Modified: 2024-05-19 21:12 UTC (History)
7 users (show)

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


Attachments
screenshot (1.11 MB, image/png)
2018-08-18 18:42 UTC, Patrick Silva
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Silva 2018-08-18 18:42:49 UTC
Created attachment 114480 [details]
screenshot

See the screenshot taken on Arch Linux please.
Comment 1 Mauro Carvalho Chehab 2018-08-19 11:59:58 UTC
Could you better describe it? What versions of Wayland, Kaffeine and libVLC you have installed? What distro? What window manager (gnome, KDE, other)? What window manager version?
Comment 2 Mauro Carvalho Chehab 2018-08-19 12:04:34 UTC
(In reply to Mauro Carvalho Chehab from comment #1)
> Could you better describe it? What versions of Wayland, Kaffeine and libVLC
> you have installed? What distro? What window manager (gnome, KDE, other)?
> What window manager version?

Btw, I wander if this is related to this VLC bug:
   https://trac.videolan.org/vlc/ticket/17910?cversion=0&cnum_hist=4
Comment 3 Patrick Silva 2018-08-19 12:21:28 UTC
wayland 1.15.0
kaffeime 2.0.15
vlc 3.0.3.r1
Arch Linux
KDE Plasma 5.13.4
Comment 4 Lukas Kahnert 2018-10-18 22:35:25 UTC
I'm affected by this bug too and looked at the source and try to fix myself.
The problem is (I think) libVLC's API doesn't provide embedding video output into wayland sufaces(I only found for X11,OSX and Windows).
In wayland sessions kaffeine runs with the wayland backend and tries to pass the wayland surface to libVLC(which of course fails) and the result is this bug.

Possible workround is running kaffeine with "-platform xcb" to force the X11 backend.

As an experiment I made an minimal mpv-backend(which uses OpenGL-surfaces) and it fixes the bug too.
Comment 5 Mauro Carvalho Chehab 2018-11-05 10:41:34 UTC
(In reply to Lukas Kahnert from comment #4)
> I'm affected by this bug too and looked at the source and try to fix myself.
> The problem is (I think) libVLC's API doesn't provide embedding video output
> into wayland sufaces(I only found for X11,OSX and Windows).
> In wayland sessions kaffeine runs with the wayland backend and tries to pass
> the wayland surface to libVLC(which of course fails) and the result is this
> bug.
> 
> Possible workround is running kaffeine with "-platform xcb" to force the X11
> backend.
> 
> As an experiment I made an minimal mpv-backend(which uses OpenGL-surfaces)
> and it fixes the bug too.

Could you please send the mpv-backend patches? It could be worth having a different backend on Kaffeine (although I think Gstreamer would likely give better results).
Comment 6 Lukas Kahnert 2018-11-05 12:01:07 UTC
(In reply to Mauro Carvalho Chehab from comment #5)
> (In reply to Lukas Kahnert from comment #4)
> > I'm affected by this bug too and looked at the source and try to fix myself.
> > The problem is (I think) libVLC's API doesn't provide embedding video output
> > into wayland sufaces(I only found for X11,OSX and Windows).
> > In wayland sessions kaffeine runs with the wayland backend and tries to pass
> > the wayland surface to libVLC(which of course fails) and the result is this
> > bug.
> > 
> > Possible workround is running kaffeine with "-platform xcb" to force the X11
> > backend.
> > 
> > As an experiment I made an minimal mpv-backend(which uses OpenGL-surfaces)
> > and it fixes the bug too.
> 
> Could you please send the mpv-backend patches? It could be worth having a
> different backend on Kaffeine (although I think Gstreamer would likely give
> better results).

As I said it's just minimal which only suppports play and stop. mpv has an qt example in their sources which I used for this.
Why a Gstreamer backend? Wouldn't be better to support (as KDE Project) Phonon as primary backend?
Comment 7 Mauro Carvalho Chehab 2018-11-05 15:49:23 UTC
(In reply to Lukas Kahnert from comment #6)
> (In reply to Mauro Carvalho Chehab from comment #5)
> > (In reply to Lukas Kahnert from comment #4)
> > > I'm affected by this bug too and looked at the source and try to fix myself.
> > > The problem is (I think) libVLC's API doesn't provide embedding video output
> > > into wayland sufaces(I only found for X11,OSX and Windows).
> > > In wayland sessions kaffeine runs with the wayland backend and tries to pass
> > > the wayland surface to libVLC(which of course fails) and the result is this
> > > bug.
> > > 
> > > Possible workround is running kaffeine with "-platform xcb" to force the X11
> > > backend.
> > > 
> > > As an experiment I made an minimal mpv-backend(which uses OpenGL-surfaces)
> > > and it fixes the bug too.
> > 
> > Could you please send the mpv-backend patches? It could be worth having a
> > different backend on Kaffeine (although I think Gstreamer would likely give
> > better results).
> 
> As I said it's just minimal which only suppports play and stop. mpv has an
> qt example in their sources which I used for this.
> Why a Gstreamer backend? Wouldn't be better to support (as KDE Project)
> Phonon as primary backend?

AFAIKT, Phonon is a GUI frontend, with supports two backends: libVLC and GStreamer. 

If we take the active projects that provide consistent media player libraries, I guess there are only 2 options nowadays: VLC or Gstreamer. Mplayer used to be very active in the past, but it seems that its development slowed down nowadays.

The advantage of GStreamer is that the project is focused on developing a backend for other applications. So, it allows deep control on what's happening behind the scenes. On the other hand, it adds some complexity to the backend. 

On the other hand, libVLC library is very simple, with makes the backend very simple too. However, its development is focused on VLC application, and only a handful functions are available to other applications. That makes harder (or impossible) to deal with some issues.

A libVLC application can't really select what GUI module will be used and if libva will be used or not, as (at least up to version 3), there are no functions to enumerate the display output interfacer or select between them. At max, it can pass a command line parameter that may or may not work.

On another example, I had to use only keys in order to handle DVD menus, as libVLC API doesn't allow an external application to pass mouse events (and newer versions of Qt want exclusive access to mouse events).
Comment 8 Mauro Carvalho Chehab 2019-05-03 19:27:58 UTC
I just re-checked it here on Fedora 30, with comes with:

vlc-core-3.0.7-0.1.fc30.x86_64
libwayland-server-1.17.0-1.fc30.x86_64
qt5-qtwayland-5.12.1-1.fc30.x86_64
qt5-qtbase-devel-5.12.1-2.fc30.x86_64

Was unable to reproduce this bug anymore. So, I guess this was already fixed.
Comment 9 Patrick Silva 2019-05-03 20:58:52 UTC
well, this bug persists on Arch Linux running kaffeine 2.0.17 + Wayland 1.17 + vlc 3.0.6 + Qt 5.13 beta3.
Comment 10 Mauro Carvalho Chehab 2019-05-03 21:19:31 UTC
(In reply to Patrick Silva from comment #9)
> well, this bug persists on Arch Linux running kaffeine 2.0.17 + Wayland 1.17
> + vlc 3.0.6 + Qt 5.13 beta3.

Thanks for checking it. Weird that it is not happening here on Fedora... Could this be due to some different packaging configuration?
Comment 11 Patrick Silva 2019-05-03 21:31:56 UTC
Unfortunately I do not know.
I could test Kaffeine on neon dev unstable installed on my laptop, but currently I can't start Wayland session on such system.
Comment 12 Patrick Silva 2019-05-16 17:38:44 UTC
This bug persists with kaffeine 2.0.17 + plasma 5.16 beta.

Operating System: Arch Linux 
KDE Plasma Version: 5.15.90
KDE Frameworks Version: 5.58.0
Qt Version: 5.13.0 beta3
Comment 13 Raul 2022-06-05 21:06:33 UTC
This bug persists in Ubuntu 22.04 LTS with QT_QPA_PLATFORM=wayland.

Kaffeine 2.0.18
GNOME 42.1
libVLC 3.0.16
Wayland 
Qt 5.15.3
Comment 14 Andrej Podzimek 2022-09-05 16:44:12 UTC
The title of this bug is quite an understatement; I think it should read "Kaffeine is unusable under Wayland".

On ArchLinux with plasma-desktop 5.25.4, plasma-framework 5.97.0 and kaffeine 2.0.18, video appears (indeed) in a separate "VLC Player" window and resizing / closing / manipulating that window is a recipe for an undefined state with random Kaffeine crashes.

Apart from the video window problem, the UI is broken to a point where one cannot (e.g.) select DVB-T channels, because the list of DVB-T channels flickers, does not seem to respond to scrolling, shows random items that mostly don't match the selected channel etc.

Someone suggested a "workaround" in the form of a different --platform, but none of those that I tried worked, some segfault and as for 'xcb', the most well-known one, that doesn't help either, because the UI looks disastrously bad on my 300% scaled high-DPI setup. Basically each pixel of UI widgets is stretched to 9 pixels (3x3) and, sadly enough, the same atrocious thing is done to HD videos, i.e. they are scaled down to 1/3 of Kaffeine's real window resolution.
Comment 15 Hunter 2023-02-14 01:02:43 UTC
This occurs on Void Linux glibc as well:

Kaffeine Version 2.0.18
KDE 5.26.3
Frameworks 5.101.0
Qt 5.15.7
Comment 16 Michael 2023-04-21 21:51:09 UTC
Unfortunately, Kaffeine does not work on Wayland.  An alternative is to install w_scan_cpp, an application which can produce channel listings, and compile a VLC playlist.  The ArchWiki explains how:

https://wiki.archlinux.org/title/DVB-T

It worked for me with my Haupaugge DVB-T tuner.
Comment 17 Michael 2024-05-19 21:12:58 UTC
I may have found a workaround.  KDE Bugs lists this issue:

Possible workround is running kaffeine with "-platform xcb" to force the X11
backend.