Testing Linux EGL

One aspect of the Linux app which has plagued PMP and HTPC is getting zero-copy hardware decoding working properly. The issue is that EGL is required to get zero-copy playback but enabling this requires that Qt be rendered using EGL. This is normally not a problem but in some configurations enabling this can cause the UI to be rendered as nothing more than a black screen.

PMP had a detection mechanism to try and detect this circumstance but due to licensing issues we cannot use this code going forward. Additionally we saw some complaining of when it failed to work. Obviously we can’t make this a preference because if you get a black screen then you have no UI from which to clear the pref.

So, we are asking all Linux users of HTPC to test out setting an environment variable and launching HTPC. Try this and report your experiences:

  1. Install HTPC if not already installed (see the first post Plex HTPC feedback for link and install instructions).
  2. Quit HTPC (if already running)
  3. Open a terminal window and execute snap run plex-htpc
  4. Enable hardware decoding (if not already so) and play a video file which will hardware decode (H.264, H.265 are good examples)
  5. Bring up the debug overlay (ctrl-shft-d)
  6. The Hardware decoding (middle of the right column) should report vaapi-copy (this may report no on Nvidia GPUs)
  7. Quit HTPC
  8. Execute QT_XCB_GL_INTEGRATION=xcb_egl snap run plex-htpc
  9. Play the file again and bring up the debug overlay again
  10. Hardware decoding should report vaapi (vaapi-egl)

I would like everyone on Linux to test this and report the following:

  1. What GPU are you using?
  2. Which drivers (particularly those with Nvidia GPUs and whether they are the proprietary or OSS drivers)?
  3. When you launched with the environment variable set, did the UI display and work?
  4. Did playback work (both cases)?
  5. Did you get the expected values for the hardware decoding?

Hopefully this can help us to add in a more robust detection mechanism.

Would you like us report our results in this thread or in the Plex HTPC feeback thread?

  1. Nvidia GTX 1050 TI
  2. 510.54
  3. I got a black screen in the window and errors in the console on repeat:
[28764:28797:0216/180432.819621:ERROR:gl_context_egl.cc(214)] eglCreateContext failed with error EGL_BAD_CONTEXT
[28764:28797:0216/180432.819626:ERROR:gpu_channel_manager.cc(692)] ContextResult::kFatalFailure: Failed to create shared context for virtualization.
[28764:28797:0216/180432.819628:ERROR:shared_image_stub.cc(418)] SharedImageStub: unable to create context
[28764:28797:0216/180432.819634:ERROR:gpu_channel.cc(441)] GpuChannel: Failed to create SharedImageStub

I can still interact with UI but I don’t see it. If I click to enter a few times I can actually get it to play, but I still only hear audio with a black screen.

  1. Only without environment variable
  2. No, I got ā€œno (?)ā€. I tried both H.264 and H.265.

I may be doing something wrong but HW decoding does not show in debug overlay for me. By ā€œEnable hardware decodingā€ I presume you mean in HTPC app settings so I got that enabled.

I should add: we expect that the black screen will occur for those using the env on Nvidia GPUs. We don’t know if this includes those using the OSS drivers for these GPUs though. In reading the material surrounding this area, it appears that Nvidia is alone in not supporting EGL on Linux (which gives me more understanding to Linus flipping the bird to Nvidia).

This thread

Was this the proprietary drivers or the OSS drivers?

Hardware decoding may not work on Nvidia GPUs on Linux. I don’t recall for certain though.

Yes, that is what I meant.

I use proprietary drivers.

  1. What GPU are you using?

Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)

  1. Which drivers (particularly those with Nvidia GPUs and whether they are the proprietary or OSS drivers)?

i915

  1. When you launched with the environment variable set, did the UI display and work?

Yes.

  1. Did playback work (both cases)?

Yes.

  1. Did you get the expected values for the hardware decoding?

No. First time was vaapi-copy (?), with environment variable set vaapi-copy (?) again.

Thank you for a Linux release. It looks very impressive! Great job devs.

That is interesting that you didn’t get the vaapi-copy. Maybe it’s not supported on your particular GPU but I wouldn’t expect that.

Bugs and issues unrelated to EGL

(This is not related to this thread though so if you want a detailed bug report elsewhere let me know)

  • The app does not run on wayland at all. (needs DISABLE_WAYLAND=1)
  • Text and UI around the app looks a bit blurry. (My DE runs at native resolution with 100% scaling, so that’s not affecting it). Might be related to Wayland issues?
EDIT: Wayland debugging information here

I don’t use (or like) snaps so I don’t have much experience debugging them, but I followed the steps in their docs as best I could.

Checking any policy violations, I get a SECCOMP violation when running normally. Here is the kernel log when running the snap:

 Feb 18 09:58:32 xps-hoz audit: BPF prog-id=64 op=LOAD
Feb 18 09:58:32 xps-hoz audit[14292]: SYSCALL arch=c000003e syscall=321 success=yes exit=9 a0=5 a1=7ffcf7c522b0 a2=80 a3=1000 items=0 ppid=5714 pid=14292 auid=1000 uid=1000 gid=984 euid=0 suid=0 fsuid=0 egid=0 sgid=984 fsgid=0 tty=pts1 ses=4 comm="snap-confine" exe="/usr/lib/snapd/snap-confine" key=(null)
Feb 18 09:58:32 xps-hoz audit: PROCTITLE proctitle=2F7573722F6C69622F736E6170642F736E61702D636F6E66696E65002D2D6261736500636F7265323000736E61702E706C65782D687470632E706C65782D68747063002F7573722F6C69622F736E6170642F736E61702D6578656300706C65782D68747063
Feb 18 09:58:32 xps-hoz kernel: audit: type=1334 audit(1645174712.597:363): prog-id=64 op=LOAD
Feb 18 09:58:32 xps-hoz kernel: audit: type=1300 audit(1645174712.597:363): arch=c000003e syscall=321 success=yes exit=9 a0=5 a1=7ffcf7c522b0 a2=80 a3=1000 items=0 ppid=5714 pid=14292 auid=1000 uid=1000 gid=984 euid=0 suid=0 fsuid=0 egid=0 sgid=984 fsgid=0 tty=pts1 ses=4 comm="snap-confine" exe="/usr/lib/snapd/snap-confine" key=(null)
Feb 18 09:58:32 xps-hoz kernel: audit: type=1327 audit(1645174712.597:363): proctitle=2F7573722F6C69622F736E6170642F736E61702D636F6E66696E65002D2D6261736500636F7265323000736E61702E706C65782D687470632E706C65782D68747063002F7573722F6C69622F736E6170642F736E61702D6578656300706C65782D68747063
Feb 18 09:58:32 xps-hoz audit[14292]: SECCOMP auid=1000 uid=1000 gid=984 ses=4 pid=14292 comm="snap-exec" exe="/usr/lib/snapd/snap-exec" sig=0 arch=c000003e syscall=334 compat=0 ip=0x5df350 code=0x50000
Feb 18 09:58:32 xps-hoz kernel: audit: type=1326 audit(1645174712.603:364): auid=1000 uid=1000 gid=984 ses=4 pid=14292 comm="snap-exec" exe="/usr/lib/snapd/snap-exec" sig=0 arch=c000003e syscall=334 compat=0 ip=0x5df350 code=0x50000
Feb 18 09:58:32 xps-hoz audit[14337]: SECCOMP auid=1000 uid=1000 gid=984 ses=4 pid=14337 comm="snapctl" exe="/usr/lib/snapd/snapctl" sig=0 arch=c000003e syscall=334 compat=0 ip=0x71fd90 code=0x50000
Feb 18 09:58:32 xps-hoz kernel: audit: type=1326 audit(1645174712.610:365): auid=1000 uid=1000 gid=984 ses=4 pid=14337 comm="snapctl" exe="/usr/lib/snapd/snapctl" sig=0 arch=c000003e syscall=334 compat=0 ip=0x71fd90 code=0x50000
Feb 18 09:58:32 xps-hoz audit[14416]: ANOM_ABEND auid=1000 uid=1000 gid=984 ses=4 pid=14416 comm="Plex" exe="/snap/plex-htpc/x3/bin/Plex" sig=6 res=1
Feb 18 09:58:32 xps-hoz kernel: audit: type=1701 audit(1645174712.670:366): auid=1000 uid=1000 gid=984 ses=4 pid=14416 comm="Plex" exe="/snap/plex-htpc/x3/bin/Plex" sig=6 res=1
Feb 18 09:58:32 xps-hoz audit: BPF prog-id=65 op=LOAD
Feb 18 09:58:32 xps-hoz audit: BPF prog-id=66 op=LOAD
Feb 18 09:58:32 xps-hoz audit: BPF prog-id=67 op=LOAD
Feb 18 09:58:32 xps-hoz audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@6-14418-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 18 09:58:32 xps-hoz kernel: audit: type=1334 audit(1645174712.717:367): prog-id=65 op=LOAD
Feb 18 09:58:32 xps-hoz kernel: audit: type=1334 audit(1645174712.717:368): prog-id=66 op=LOAD
Feb 18 09:58:32 xps-hoz kernel: audit: type=1334 audit(1645174712.717:369): prog-id=67 op=LOAD
Feb 18 09:58:32 xps-hoz kernel: audit: type=1130 audit(1645174712.717:370): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@6-14418-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 18 09:58:32 xps-hoz kernel: audit: type=1131 audit(1645174712.790:371): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@6-14418-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 18 09:58:32 xps-hoz audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@6-14418-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 18 09:58:32 xps-hoz audit: BPF prog-id=0 op=UNLOAD
Feb 18 09:58:32 xps-hoz kernel: audit: type=1334 audit(1645174712.807:372): prog-id=0 op=UNLOAD
Feb 18 09:58:32 xps-hoz audit: BPF prog-id=0 op=UNLOAD
Feb 18 09:58:32 xps-hoz audit: BPF prog-id=0 op=UNLOAD
Feb 18 09:58:32 xps-hoz audit: BPF prog-id=0 op=UNLOAD
Feb 18 09:58:32 xps-hoz kernel: audit: type=1334 audit(1645174712.943:373): prog-id=0 op=UNLOAD
Feb 18 09:58:32 xps-hoz kernel: audit: type=1334 audit(1645174712.943:374): prog-id=0 op=UNLOAD
Feb 18 09:58:32 xps-hoz kernel: audit: type=1334 audit(1645174712.943:375): prog-id=0 op=UNLOAD

It seems these syscalls are the culprits:

Feb 18 09:58:32 xps-hoz audit[14292]: SECCOMP auid=1000 uid=1000 gid=984 ses=4 pid=14292 comm="snap-exec" exe="/usr/lib/snapd/snap-exec" sig=0 arch=c000003e syscall=334 compat=0 ip=0x5df350 code=0x50000
Feb 18 09:58:32 xps-hoz kernel: audit: type=1326 audit(1645174712.603:364): auid=1000 uid=1000 gid=984 ses=4 pid=14292 comm="snap-exec" exe="/usr/lib/snapd/snap-exec" sig=0 arch=c000003e syscall=334 compat=0 ip=0x5df350 code=0x50000
Feb 18 09:58:32 xps-hoz audit[14337]: SECCOMP auid=1000 uid=1000 gid=984 ses=4 pid=14337 comm="snapctl" exe="/usr/lib/snapd/snapctl" sig=0 arch=c000003e syscall=334 compat=0 ip=0x71fd90 code=0x50000

Checking the syscall 334 on my system is rseq.

Running snappy-debug yielded the same results.

Otherwise the app looks amazing! I love the UI and the interface in general with all the options. Awesome job guys. Props to the whole team for pushing through and finally pulling this off!

Main setup (Intel Graphics on gnome wayland)

  1. What GPU are you using?
    Device: Intel Corporation CometLake-H GT2 [UHD Graphics]

  2. Which drivers (particularly those with Nvidia GPUs and whether they are the proprietary or OSS drivers)?
    Drivers: mesa-21.3.5 linux-firmware-20220209.6342082-1

  3. When you launched with the environment variable set, did the UI display and work?
    No. Running the snap yielded Aborted (core dumped)
    Setting WAYLAND_DISABLE=1 fixed it and the app runs as expected (on the XWayland socket). So it seems the app does not work on wayland by default.

  4. Did playback work (both cases)?
    Yes

  5. Did you get the expected values for the hardware decoding?
    No. With or without the env var the value for hardware decoding is vaapi-copy (?)

NVIDIA (Gnome wayland) with prime render offloading

  1. What GPU are you using?
    Device: NVIDIA GeForce GTX 1650 Ti Mobile

  2. Which drivers (particularly those with Nvidia GPUs and whether they are the proprietary or OSS drivers)?
    Drivers: nvidia-510.54 (proprietary)

  3. When you launched with the environment variable set, did the UI display and work?
    No. Again it does not work on wayland.
    Launched with: prime-run env DISABLE_WAYLAND=1 env QT_XCB_GL_INTEGRATION=xcb_egl snap run plex-htpc then it works.

  4. Did playback work (both cases)?
    Yes.

  5. Did you get the expected values for the hardware decoding?
    No. In both cases the value is vaapi-copy (?)

Something that’s strange though is that without the environment variable, plex seems to run on the GPU as expected with prime-run (nvidia-smi reports plex as a running GPU process) but when setting the env var, it’s not anymore? So it seems the EGL env var overrides prime render offloading and runs the process on the Intel GPU instead.

In any case, as far as I know, nvidia drivers as of 495 has GBM support and as such mutter (gnome-shell compositor) will run on the GBM backend as of nvidia-495 and gnome-shell-41. I’m not sure if it’s related or how Qt does this internally and if it just uses the EGL backend directly?, but essentially there is no part in the graphics pipeline that runs on EGLStreams if that helps.

NVIDIA (Gnome on X.Org) through prime render offloading

I would never run on this configuration personally.

  1. What GPU are you using?
    Device: NVIDIA GeForce GTX 1650 Ti Mobile

  2. Which drivers (particularly those with Nvidia GPUs and whether they are the proprietary or OSS drivers)?
    Drivers: nvidia-510.54 (proprietary)

  3. When you launched with the environment variable set, did the UI display and work?
    Launched with: prime-run env QT_XCB_GL_INTEGRATION=xcb_egl snap run plex-htpc
    Yes.

  4. Did playback work (both cases)?
    Yes.

  5. Did you get the expected values for the hardware decoding?
    Yes. In this instance the value is vaapi (vaapi-egl) and the egl backend seems to work properly

  1. What GPU are you using?
    Device: NVIDIA GeForce GTX 1050 Ti
  2. Which drivers (particularly those with Nvidia GPUs and whether they are the proprietary or OSS drivers)?
    Drivers: nvidia-510.47.03 (proprietary)
  3. When you launched with the environment variable set, did the UI display and work?
    Launched with: QT_XCB_GL_INTEGRATION=xcb_egl snap run plex-htpc
    No.
[73695:73730:0218/015209.403805:ERROR:gl_context_egl.cc(214)] eglCreateContext failed with error EGL_BAD_CONTEXT
[73695:73730:0218/015209.403853:ERROR:gpu_channel_manager.cc(692)] ContextResult::kFatalFailure: Failed to create shared context for virtualization.
[73695:73730:0218/015209.403868:ERROR:shared_image_stub.cc(418)] SharedImageStub: unable to create context
[73695:73730:0218/015209.403885:ERROR:gpu_channel.cc(441)] GpuChannel: Failed to create SharedImageStub
  1. Did playback work (both cases)?
  • QT_XCB_GL_INTEGRATION=xcb_egl, give a black screen

  • without EGL, yes i can play video

  1. Did you get the expected values for the hardware decoding?
    No, even without EGL, the hardware decoding is: No (?)
    i know that my system is normally hardware decoding in MPV if set the mpv.conf with hwdec=auto or hwdec=nvdec-copy, but even if i set those mpv configuration in the mpv.conf of plex-htpc hardware decoding is not working :confused:

Not surprising. The old PMP didn’t either and aside from updating Qt no effort has been made in this regard. Likely the issue is in Qt’s support for wayland.

I had not heard of prime-run before and it appears interesting. I’m not surprised that with the env set that it renders the UI on the Intel GPU since it really looks like EGL is broken in Nvidia’s proprietary drivers. So it moving it to the Intel GPU yields something that works.

I believe this mpv is compiled without nvdec which is likely the issue here.

First of all, thank you very much for releasing Plex HTPC for Linux!!

I tried it today on my AMD Linux machine

  1. What GPU are you using?
    Device: [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] (rev c8) - AMD Ryzen 3 2200G / AMD Vega 8

  2. Which drivers (particularly those with Nvidia GPUs and whether they are the proprietary or OSS drivers)?
    Drivers: Mesa-21.3.6 from ARCH repo / (RAVEN, DRM 3.44.0, 5.16.10-arch1-1, LLVM 13.0.1
    Interestingly the driver is different in the PlexHTPC.log → there it shows as
    Mesa 21.2.6 / (RAVEN, DRM 3.44.0, 5.16.10-arch1-1, LLVM 12.0.0) (maybe through the mesa-core20 snap?)

  3. When you launched with the environment variable set, did the UI display and work?
    Yes, with and without QT_XCB_GL_INTEGRATION=xcb_egl the UI was shown correctly and I could navigate as expected.

  4. Did playback work (both cases)?
    Yes

  5. Did you get the expected values for the hardware decoding?
    No, no hardware decoding at all.

The log also just showed

DEBUG - [MPVEngine/mpv] libmpv_render: No advanced processing required. Enabling dumb mode.
DEBUG - [MPVEngine/mpv] libmpv_render: Loading hwdec driver ā€˜vaapi-egl’
DEBUG - [MPVEngine/mpv] libmpv_render/vaapi-egl: using VAAPI EGL interop
DEBUG - [MPVEngine/mpv] libmpv_render/vaapi-egl: Trying to open a x11 VA display…
DEBUG - [MPVEngine/mpv] libmpv_render: Loading failed.

I created a mpv.conf with log-file=
There I found the culprit, libva is trying to open /snap/plex-htpc/lib/dri/radeonsi_drv_video.so but it is not there, returning in [libmpv_render/vaapi-egl/vaapi] libva: va_openDriver() returns -1
The radeonsi_drv_video.so lib is not shipped with the snap and therefore it cannot make use of the AMD GPU for decoding. Would be awesome if this could be fixed!!

1 Like

Not surprising. The old PMP didn’t either and aside from updating Qt no effort has been made in this regard. Likely the issue is in Qt’s support for wayland.

I’m sorry what? I guess that’s okay, but considering Wayland is default on Ubuntu since 21.04 and Fedora 36 I believe, Wayland support should be a top priority. In any case it should at least work on XWayand by default (which PMP does).

The XWayland problem seems to be an issue with snap though, not plex. I did some digging, and it seems the fix is already in master for snap. The relevant PR is here: interfaces/seccomp: Add rseq to base seccomp template by alexmurray Ā· Pull Request #11357 Ā· snapcore/snapd Ā· GitHub. This makes sense, considering arch just updated glibc, and I updated my system just a couple days ago, so this issue hasn’t reached other distros yet.
Again, I’m not sure how snap works, do you need to update something to make it work, or is this issue just on snap’s side? I’m pretty sure the relevant fix is in the version of snapd in my system (2.54.3). Sorry, I see now that 2.54.3 was tagged after the relevant commit, but didn’t include it. I guess this will prob be fixed in the next patch version of snapd.

Also, as far as I can tell you’re using Qt5?, which has decent support for Wayland1. X11 is considered legacy and has been for a while. The transition to Wayland is long in the works (and hopefully soon complete). If you have a supported Qt version, it should be plug and play as long as you don’t have any X11 specific code.

I know Qt6 has examples using EGL with the wayland-egl backend, I’m not sure about Qt5 though. Anyways, having the app run at all is better than nothing.

I had not heard of prime-run before and it appears interesting. I’m not surprised that with the env set that it renders the UI on the Intel GPU since it really looks like EGL is broken in Nvidia’s proprietary drivers. So it moving it to the Intel GPU yields something that works.

I think this needs more investigation, but I yeah EGL is still in early stages in the nvidia driver, but I know that firefox uses hardware decoding with EGL on wayland working perfectly fine since firefox-94 and nvidia-495. So I was under the impression that EGL support in the newer nvidia drivers was really starting to mature. In any case, it should hard crash if what you say is true, not just ignore the nvidia GPU. Running the compositor directly on the GPU (instead of render offloading) should show what’s what though.

1 Like

Good catch.

All of the window handling code and interaction with X in contained within Qt (except for how MPV interacts in regard to hardware decoding).

I was looking this up right as you edited your comment. The relevant commits to that version are Commits Ā· snapcore/snapd Ā· GitHub and the commit in the PR you linked is not present.

5.15.2 currently. Qt has made updating this very painful but we are looking at what’s necessary to do so.

We do not. Some deps might (like maybe MPV) but less likely.

FWIW, the compositor in X is what’s limiting Linux from getting a proper layering treatment like Mac/Win got. It would not composite child windows within a parent window. There is however some hope from a PR I read in MPV’s repo that it may be possible in wayland. Now if only Wayland would add refresh-rate switching it wouldn’t be a regression from X (pulldown really annoys me)

5.15.2 currently

you don’t have any X11 specific code.

We do not. Some deps might (like maybe MPV) but less likely.

Nice! Then QtWayland should work :tm: (MPV should work fine unless you’re bundling an ancient version). I’ll try it out as soon as snapd is fixed. Although I couldn’t find the QtWayland platform plugin bundled in the snap, so you might need to include it? ref: QtWayland

EDIT: Yep, you definitely need to bundle the QtWayland plugin to make this work (god I miss just using my system libs)

EDIT: Oh and by the way, VRR is already supported for intel and AMD GPUs (nvidia support in the works) on KDE (and sway) :wink: Variable refresh rate - ArchWiki (Gnome is still lagging a bit behind…)

  1. Integrated Intel HD 620
  2. i915
  3. yes
  4. yes
  5. In both cases it reported vaapi-copy ( ? )

I note in the logs it reports:

eb 21, 2022 21:24:40.333 [0x7f90a2ffd700] DEBUG - [MPVEngine/mpv] libmpv_render: GL_VERSION='4.6 (Compatibility Profile) Mesa 21.2.6'
Feb 21, 2022 21:24:40.333 [0x7f90a2ffd700] DEBUG - [MPVEngine/mpv] libmpv_render: Detected desktop OpenGL 4.6.
Feb 21, 2022 21:24:40.333 [0x7f90a2ffd700] DEBUG - [MPVEngine/mpv] libmpv_render: GL_VENDOR='Intel'
Feb 21, 2022 21:24:40.333 [0x7f90a2ffd700] DEBUG - [MPVEngine/mpv] libmpv_render: GL_RENDERER='Mesa Intel(R) HD Graphics 620 (KBL GT2)'
Feb 21, 2022 21:24:40.333 [0x7f90a2ffd700] DEBUG - [MPVEngine/mpv] libmpv_render: GL_SHADING_LANGUAGE_VERSION='4.60'
Feb 21, 2022 21:24:40.334 [0x7f90a2ffd700] DEBUG - [MPVEngine/mpv] libmpv_render: GL_*_swap_control extension missing.
Feb 21, 2022 21:24:40.335 [0x7f90a2ffd700] DEBUG - [MPVEngine/mpv] libmpv_render: Testing FBO format rgba16f
Feb 21, 2022 21:24:40.335 [0x7f90a2ffd700] DEBUG - [MPVEngine/mpv] libmpv_render: Using FBO format rgba16f.
Feb 21, 2022 21:24:40.335 [0x7f90a2ffd700] DEBUG - [MPVEngine/mpv] libmpv_render: No advanced processing required. Enabling dumb mode.
Feb 21, 2022 21:24:40.335 [0x7f90a2ffd700] DEBUG - [MPVEngine/mpv] libmpv_render: Loading hwdec driver 'vaapi-egl'
Feb 21, 2022 21:24:40.335 [0x7f90a2ffd700] DEBUG - [MPVEngine/mpv] libmpv_render/vaapi-egl: VAAPI hwdec only works with OpenGL or Vulkan backends.
Feb 21, 2022 21:24:40.335 [0x7f90a2ffd700] DEBUG - [MPVEngine/mpv] libmpv_render: Loading failed.
Feb 21, 2022 21:24:40.335 [0x7f90a2ffd700] DEBUG - [MPVEngine/mpv] libmpv_render: Loading hwdec driver 'drmprime-drm'
Feb 21, 2022 21:24:40.335 [0x7f90a2ffd700] DEBUG - [MPVEngine/mpv] libmpv_render/drmprime-drm: Failed to retrieve DRM fd from native display.
Feb 21, 2022 21:24:40.335 [0x7f90a2ffd700] DEBUG - [MPVEngine/mpv] libmpv_render: Loading failed.

Is vaapi-copy good or bad exactly, does it mean HW decoding, difficult to find a lot of info about it - and what about the question mark ?

This is a kaby lake processor (7th generation), right? I find this odd that you didn’t get vaapi-egl with the env set because I have personally verified it works on 4th and 8th generation processors with integrated Intel graphics running Linux.

It does mean it is using hardware decoding but the decoded picture is copied from the GPU to the CPU after it has been decoded and then the CPU copies it back to the GPU to display. The vaapi-egl bypasses this copy-back and the decoded picture remains in the GPU.

That means the hwdec-interop property had no value which would be the case with vaapi-copy.

Yes, Core i3-7100U 2.4GHz 7th Gen, Kaby Lake.

Is it because of these lines in the log I posted?:

Feb 21, 2022 21:24:40.335 [0x7f90a2ffd700] DEBUG - [MPVEngine/mpv] libmpv_render: Loading hwdec driver 'vaapi-egl'
Feb 21, 2022 21:24:40.335 [0x7f90a2ffd700] DEBUG - [MPVEngine/mpv] libmpv_render/vaapi-egl: VAAPI hwdec only works with OpenGL or Vulkan backends.
Feb 21, 2022 21:24:40.335 [0x7f90a2ffd700] DEBUG - [MPVEngine/mpv] libmpv_render: Loading failed.

It’s libmpv_render/vaapi-egl: VAAPI hwdec only works with OpenGL or Vulkan backends but that env should be giving you the OpenGL backend. Maybe your OS GL is incompatible with the libraries in the snap or perhaps something else is going on. Unfortunately while snaps do help with the mess that is Linux binary distribution, they don’t make absolutely everything consistent.

I’m running Linux Mint but happy to try another distro you recommend?