Created attachment 150480 [details] 2 first screenshots - Haruna, 2nd two - SMPlayer SUMMARY hardware decoding seems not working. only `auto` option (default) seems to have some effect, but even in this case it seems some GL/shaders fallback is used (according to CPU/GPU load, details are below). any other options definitely falling back to software decoding, because CPU usage grows insanely. hardware decoding works fine in another mpv-based player (SMPlayer), but it directly uses `mpv` rather than `libmpv` and just somehow embeds its output into UI. using vaapi as h/w decoding engine in it. I don't think that this may be an issue, `libmpv` definitely must have the same capabilities. there are some comparisons between playing the same video in Haruna and SMPlayer. first 2 screenshots are taken when Haruna played the video, another 2 - SMPlayer played the same video (`vaapi` is used as h/w decoding backend). STEPS TO REPRODUCE 1. open settings, enable h/w decoding (doesn't matter which option, even default `auto` is fine) 2. open any pretty heavy h.264 or h.265 encoded video 3. observe CPU and GPU load 4. compare results with some other player (SMPlayer for example) with h/w decoding enabled OBSERVED RESULT any options expect `auto` have no effect at all (result is the same as for disabled h/w decoding), software decoding is used (very high CPU load and almost no GPU load). `auto` value seems to fallback to some generic GL/shaders implementation, because it causes significant CPU load decrease and pretty high GPU load (see attached screenshots, the first two) EXPECTED RESULT H/W decoding works, special modules on GPU used for it, no significant CPU load, not so big GPU load SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian Unstable / KDE Plasma on X11 KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.4 ADDITIONAL INFORMATION hardware used for testing: - laptop: RedmiBook Pro 14S - CPU: AMD Ryzen 5 5500U with Radeon Graphics - GPU: AMD Radeon Graphics (Lucienne), integrated into CPU, no discrete graphics available - RAM: 16GB DDR4 - Display: 14", 2560x1600, 100% sRGB (aka 72% NTSC) video used in testing - Sony Aquarium 4K Demo.mp4 : 3840x2160 (aka 4k), 60 FPS, h.265 (~80 Mb/s), 8bit `amdgpu` proprietary firmware required by GPU drivers is installed, user-space (mesa and so on) libraries required for H/W decoding (both `vaapi` and `vdpau`) are installed too, otherwise h/w decoding would be impossible. h/w decoding is known to work in several players (based on different libraries) and even in different ways (aka using `vaapi` and `vdpau` variations). SMPlayer was chosen for comparison because it is also based on `mpv`.
Create a log by creating the following startup custom commands in settings: ``` set terminal yes set msg-level all=v set log-file "/path/to/log/file.txt" ``` And attach it here.
Created attachment 150481 [details] using `auto` option added log when using `auto` option
Created attachment 150482 [details] using `vaapi` option added log when using `vaapi` option (known to work in other player)
used the same video as for initial testing, video played ~30 seconds
When using auto mpv settles on hevc-vaapi-copy ``` [ 0.226][v][libmpv_render] Loading hwdec driver 'vaapi-egl' [ 0.226][v][libmpv_render/vaapi-egl] VAAPI hwdec only works with OpenGL or Vulkan backends. [ 0.226][v][libmpv_render] Loading failed. [ 0.226][v][libmpv_render] Loading hwdec driver 'cuda-nvdec' [ 0.227][v][libmpv_render/cuda-nvdec] Failed to load CUDA symbols [ 0.227][v][libmpv_render] Loading failed. [ 0.227][v][libmpv_render] Loading hwdec driver 'drmprime-drm' [ 0.227][v][libmpv_render/drmprime-drm] Failed to retrieve DRM fd from native display. [ 0.227][v][libmpv_render] Loading failed. ... [ 3.979][v][vd] Looking at hwdec hevc-nvdec... [ 3.979][v][vd] Could not create device. [ 3.979][v][vd] Looking at hwdec hevc-vaapi... [ 3.979][v][vd] Could not create device. [ 3.979][v][vd] Looking at hwdec hevc-vdpau... [ 3.979][v][vd] Could not create device. [ 3.979][v][vd] Looking at hwdec hevc-nvdec-copy... [ 3.980][e][ffmpeg] AVHWDeviceContext: Cannot load libcuda.so.1 [ 3.980][e][ffmpeg] AVHWDeviceContext: Could not dynamically load CUDA [ 3.980][v][vd] Could not create device. [ 3.980][v][vd] Looking at hwdec hevc-vaapi-copy... [ 3.980][d][vaapi] libva: VA-API version 1.15.0 ``` But when you set `vaapi` it uses software decoding. ``` [ 0.230][v][libmpv_render] Loading hwdec driver 'vaapi-egl' [ 0.230][v][libmpv_render/vaapi-egl] VAAPI hwdec only works with OpenGL or Vulkan backends. [ 0.230][v][libmpv_render] Loading failed. [ 0.230][v][libmpv_render] Loading hwdec driver 'cuda-nvdec' [ 0.230][v][libmpv_render/cuda-nvdec] Failed to load CUDA symbols [ 0.230][v][libmpv_render] Loading failed. [ 0.230][v][libmpv_render] Loading hwdec driver 'drmprime-drm' [ 0.230][v][libmpv_render/drmprime-drm] Failed to retrieve DRM fd from native display. [ 0.230][v][libmpv_render] Loading failed. ... [ 4.016][v][vd] Looking at hwdec hevc-vaapi... [ 4.016][v][vd] Could not create device. [ 4.016][v][vd] No hardware decoding available for this codec. [ 4.016][v][vd] Using software decoding. ``` Why it does this I don't know. The documentation says that vaapi "requires --vo=gpu or --vo=vaapi", but if I set `vo` to anything other than `libmpv` the video plays in in another window or it won't play. Also there are differences between using libmpv and embedding mpv (like smplayer), like this https://github.com/mpv-player/mpv/issues/9417 Try logging mpv and see which hwdec mpv uses for auto and vaapi.
Created attachment 150483 [details] mpv logs in 3 cases attached logs in archive: - mpv with no any options - mpv with vaapi h/w decoder - mpv log from smplayer (which uses vaapi)
small update: occasionally found another `libmpv`-based player called Celluloid and decided to try. and hardware decoding (using `vaapi`) works in it, no difference in CPU/GPU load comparing with SMPlayer using the same test video. sources of mentioned player can be found here https://github.com/celluloid-player/celluloid , it is GTK-based. its configuration dialog is very simple, but have very convenient field "Extra MPV options", where I supplied the most important options copied from SMPlayer mpv command line `hwdec=vaapi vo=gpu sub-auto=fuzzy icc-profile-auto audio-file-auto=fuzzy` (just removed '--' like it was in some example I found). regardless of this field, comparing to SMPlayer, this player doesn't run `mpv` executable (checked with `ps ax | grep mpv`) and it is definitely linked to `libmpv` (checked with `ldd /usr/bin/celluloid | grep mpv`). don't know how, but it passes given options to some `libmpv` internals... so, the problem with H/W decoding somewhere on application side...
Not much I can do https://github.com/mpv-player/mpv/issues/10424, at least on X11, on Wayland it seems to work.
as I understood from the last comment on GitHub, the problem somewhere in OpenGL context type which you get from Qt and pass to libmpv, very sad... from my experience, it looks like Qt even may use OpenGL ES 2.0 (like on mobiles!) even on desktop, but I can be wrong... I almost don't have experience with OpenGL, just "touched" it due to work. also tried to run Haruna on Wayland - situation the same: any option except auto seems to use software decoding (very high CPU usage), auto option very likely uses the same generic GL/shaders implementation (CPU load is pretty low, but more than twice higher comparing when vaapi is used, GPU load is also pretty high, about twice more comparing to vaapi). so it is also doesn't work on Wayland too... for the sake of experiment, tried already mentioned SMPlayer (Qt, mpv-based) and Celluloid (GTK3, libmpv-based) on Wayland. so, SMPlayer is unusable on Wayland - in most cases video plays in separate window or hardware decoding doesn't work (when I got video in the same window) or just no video at all. from other side, Celluloid works fine, even with exactly the same options what was set in X11 environment, and vaapi seems to work correctly (almost no CPU usage, and GPU usage is comparable to SMPlayer in X11 environment). looks like GTK has much better support/integration with Linux rather than Qt... so, as so this bug seems not related to application side (unfortunately Qt may be the reason of it), feel free to close it.
It doesn't works on Wayland for you most likely because you're missing this patch https://invent.kde.org/multimedia/haruna/-/commit/b89361b050d165c0a47a592e6a8b13ad59fb679f
confirmed, compiled from master branch - vaapi works on Wayland, behavior is the same as in SMPlayer on X11. thanks! but unfortunately, Wayland is not an option for me - some necessary apps have significant issues on it, also some parts (don't know exactly which) have issues (artifacts around "minimize/maximize/close" button hints, around some but not all context menus), and many icons are blurry when scaling (200%) is enabled even fonts in the same places look fine (in many cases the same icons are fine on X11). thank you for your work!
I got h/w decoding (vaapi in particular case) working on X11! but mentioned change seems to be vital in any case, "display" variable must be passed as one of mpv initialization parameters. all I did - just set environment variable `QT_XCB_GL_INTEGRATION` to "xcb_egl": ``` export QT_XCB_GL_INTEGRATION="xcb_egl" ``` this was based on comment on GitHub you pointed (it says that EGL context is required for mpv) and this particular piece of Qt code https://github.com/qt/qtbase/blob/231d3670981a33ec42b91ad1cb33c1fc50551066/src/plugins/platforms/xcb/qxcbconnection.cpp#L1079-L1104 first of all I viewed which GL libraries are loaded by application. I was surprised to see both 'libGLX.so' and 'libEGL.so'. but when looked closer (and analyzed 'SMPlayer'+'mpv') found the difference - Qt applications also load 'libGLX_mesa.so' (very likely real OpenGL implementation) and mpv loads 'libEGL_mesa.so' instead. I already knew that Qt on X11 uses so-called 'xcb' platform plugin and it has something called "GL integration", and 2 "backends" are provided for that (exactly GLX and EGL), which very likely can be switched on runtime somehow. I just went deep into Qt sources starting from `QQuickFramebufferObject::Renderer::createFramebufferObject()` found in your code. P.S> please don't think that I know OpenGL specific on Linux, Qt Open GL integration on something specific to mpv - I know neither of those! I just familiar with Qt sources and its build process/dependencies on Linux and just used information you provided. so, I think issue can be marked as solved :) waiting new release in Debian unstable repo :)
Thanks for looking into this. I'll leave the report open untill I'll add something in the application for setting this up correctly.
Can you post a log of your working x11 instance. I can't get it to work on my intel pc.
Created attachment 150866 [details] Haruna vaapi QT_XCB_GL_INTEGRATION="xcb_egl" log attached
Just wanted to note that QT_XCB_GL_INTEGRATION="xcb_egl" works perfectly for me on discrete graphics (AMD Radeon RX 6700 XT). Without this variable, Haruna falls back to suboptimal "vaapi-copy" driver instead of proper "vaapi".
I was trying to get this to work so that it would use vaapi instead of vaapi-copy on this AMD APU 0405. I set the environment variable in the /etc/environment file as well as the other ways like export, etc. I had no success with the flatpak version. It continues to use vaapi-copy. mpv flatpak can use vaapi however. I wonder if an environment variable like this needs to be set inside the flatpak, or if mpv does something different compared to libmpv?
PS. Environment is x.org on this device. I don't have the option of using wayland as it is not available.
The Haruna flatpak can be launched with vaapi decoding from the terminal with: "QT_XCB_GL_INTEGRATION="xcb_egl" org.kde.haruna" Now the next challenge is figuring out how to edit the GUI so that the terminal isn't needed.
I've been trying to edit the org.kde.haruna.desktop file where this line is: Exec=/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=haruna --file-forwarding org.kde.haruna @@u %u @@ No matter what I try, I can't get it to stick.. --env doesn't work, etc.
Try Exec=QT_XCB_GL_INTEGRATION=xcb_egl <default command>
(In reply to george fb from comment #21) > Try > Exec=QT_XCB_GL_INTEGRATION=xcb_egl <default command> More progress made.. doing this in the desktop file (both quotes and no quotes worked) when double-clicking on that file and selecting execute.. but then a new problem.. why doesn't it work when selected from the launcher menu? It's the exact same file that the properties say points-to. Time to figure this out.. On the Application tab, it looks weird.. Program: QT_XCB_GL_INTEGRATION=xcb_egl Arguments: /usr/bin/flatpak run --branch=stable --arch=x86_64 --command=haruna --file-forwarding org.kde.haruna @@u %u @@ But trying to edit it in file properties is a problem.. I get a dialog.. "Could not save properties due to insufficient write access" The edited file in question is fine if I execute it directly from Dolphin, but there seems to be some sort of glitch with the kde launcher.. Then I get the idea.. to put part of it in quotes.. displays properly in properties.. but trying to execute the file now says "could not find the program run" so quotes won't work (unless I did it wrong). Is there a string or operator I can add so that the kde menu launcher parses the entire desktop exec entry as a single line instead of breaking it into two pieces? It looks like what it's trying to do is take the environment variable as the program, and everything else as an argument, and I want it to not do that so that it will work properly.
I don't understand this.. If I change the Exec line to be: Exec=/usr/bin/flatpak run --env=QT_XCB_GL_INTEGRATION=xcb_egl --branch=stable --arch=x86_64 --command=haruna --file-forwarding org.kde.haruna @@u %u @@ Then the string will display /usr/bin/flatpak correctly in the Programs section of the application tab properties, with all the rest in the Arguments section. But it doesn't work as expected.. if you double-click the desktop file in dolphin and select "execute" then vaapi will work. If you launch it from the kde launcher, it will instead say vaapi-copy.. but it's pointing to the same desktop file!! Why doesn't it just work from the kde launcher menu?
Solved for the launcher. I don't like this solution but it works.. In the console type: "sudo flatpak override --env=QT_XCB_GL_INTEGRATION=xcb_egl org.kde.haruna" This will save the override in the system. Now the question becomes.. why is an override necessary? In my previous comment I observed that if one executes the .desktop file from dolphin with the env variable present, it selects vaapi correctly.. but not when one executes it from the KDE launcher.
It works for me, though I copy the desktop file to ~/.local/share/applications and add QT_XCB_GL_INTEGRATION=xcb_egl to the exec entry `Exec=QT_XCB_GL_INTEGRATION=xcb_egl /usr/bin/flatpak run --branch=stable --arch=x86_64 --command=haruna --file-forwarding org.kde.haruna @@u %u @@` And it works when launching from the default start menu/launcher, task bar or opening a file from dolphin.
I test it by creating a custom command triggered by keyboard, command field I put a dot and in osd field hwdec: ${hwdec-current} this way you can check the current hwdec. With QT_XCB_GL_INTEGRATION=xcb_egl set I get vaapi and without it vaapi-copy.
(In reply to george fb from comment #25) > ~/.local/share/applications and add QT_XCB_GL_INTEGRATION=xcb_egl to the > exec entry `Exec=QT_XCB_GL_INTEGRATION=xcb_egl /usr/bin/flatpak run Cleaner to do it the way I identified, as an argument variable --env=QT_XCB_GL_INTEGRATION=xcb_egl because it will display correctly in the launcher's edit properties. Without it, it will display an argument as a program. > And it works when launching from the default start menu/launcher, task bar > or opening a file from dolphin. That's the thing I can't figure out. Without setting a flatpak override the launcher ignores the variable for me.. but it works just fine if one manually launches the file.. This is what I have in the .local folder, a symlink: lrwxrwxrwx 1 deck deck 99 Dec 11 16:52 org.kde.haruna.desktop -> /var/lib/flatpak/app/org.kde.haruna/current/active/export/share/applications/org.kde.haruna.desktop And this is what I have at the destination: -rwxr-xr-x 1 root root 3277 Dec 12 21:20 org.kde.haruna.desktop I am wondering if it's the user/user symlinking to root/root thing that is causing an issue with the launcher. In anycase, do you have the ability to have haruna itself set the environment variable internally instead of needing end-users to figure out a flatpak override or set variables on their own so that it just works for everyone?