VA-API not working, no hardware H.264 decoding with UVD on ThinLinc

Hi,

I’m trying to enable hardware-accelerated H.264 decoding (UVD) using VA-API on a ThinLinc setup, but so far, VA-API fails to initialize, and decoding falls back to software (llvmpipe). I’m not sure what’s causing the issue and would appreciate help diagnosing it.

Environment:

  • ThinLinc client: 4.19.0-4005
  • ThinLinc server: 4.19.0-4116
  • OS: Linux Mint 21.3 (based on Ubuntu 22.04, kernel 5.15)
  • GPU: AMD GX-415GA SOC with Radeon HD Graphics
  • User is in video and render groups
  • VA-API version: 1.14.0
  • /dev/dri/ contains card0 and renderD128

Symptoms:

vainfo output:

libva info: VA-API version 1.14.0
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
vaInitialize failed with error code -1 (unknown libva error)

glxinfo shows software rendering:

OpenGL renderer string: llvmpipe (LLVM 15.0.7, 256 bits)

dmesg confirms amdgpu loads and UVD is initialized:

[drm] add ip block number 7 <uvd_v4_2>
...
[drm] Found UVD firmware Version: 1.64 Family ID: 9
[drm] UVD initialized successfully.

What I’ve checked so far:

  • amdgpu module is loaded
  • User has access to /dev/dri/* devices
  • DRM and firmware initialization succeeds
  • Tried running vainfo from both the ThinLinc session and a regular X session (same result)

Questions:

  1. Does ThinLinc do anything special with VA-API or GPU access that might interfere?
  2. Is there a known issue with VA-API and amdgpu on Kabini APUs in ThinLinc environments?
  3. Should I manually set LIBVA_DRIVER_NAME=radeonsi? If so, where should this be exported in a ThinLinc session?

Thanks in advance for any hints or suggestions!


Krzysztof

Hi @kszwaba,

Thanks for the detailed report!

The X server responsible for your ThinLinc session generally won’t have access to the GPU, even if the user has the correct permissions. So for example, if you want to run accelerated OpenGL applications in a ThinLinc session, you’d need to use something like VirtualGL. This is why glxinfo is showing a fallback to software rendering.

ThinLinc shouldn’t affect things outside of a ThinLinc session, though. So if you’re unable to get sensible output from vainfo at the local console for example, then you would need to resolve this first.

I’m not familiar with VA-API at all, so the following is pure guesswork :slight_smile: but if/when you have vainfo working at the local console, you might like to try unsetting the DISPLAY environment variable before running vainfo within the ThinLinc session. This will (hopefully) prevent it from trying to use ThinLinc’s X server for GPU access, and get it to use the console one instead. So something like:

DISPLAY= vainfo

or

DISPLAY=:0.0 vainfo

Note that you shouldn’t change the DISPLAY variable globally, for example by exporting it, since ThinLinc relies on this being set correctly.

Let us know how you get on.

Hi aaron,

Building on the discussion about enabling hardware-accelerated video decoding and encoding within ThinLinc sessions, I’d like to suggest exploring a hardware-accelerated proxy encoding/decoding approach similar to what is described here:

https://adrian.siemieniak.net/portal/how-to-enable-hw-accelerated-proxy-encoding-in-kdenlive/

The core idea is to run a dedicated local service (e.g., an ffmpeg-based proxy) with direct access to VA-API/UVD hardware on the server side (for example, within a console or separate X session that has GPU access). ThinLinc sessions, which lack direct GPU access, could then offload video encoding/decoding tasks to this proxy service.

This approach could:

  • Bypass the limitation of ThinLinc’s virtual X servers not having direct GPU device access,

  • Reduce CPU load by offloading video processing to hardware via the proxy,

  • Potentially enable smoother video streaming and better performance inside ThinLinc sessions without requiring a dedicated GPU-enabled X session per user.

Of course, implementing such a proxy would require developing a communication protocol between ThinLinc sessions and the proxy service, as well as integration work. However, this could be a promising avenue to enable VA-API/UVD hardware acceleration indirectly within ThinLinc.

Would be interested to hear if ThinLinc developers or community members have considered or experimented with similar proxy-based hardware acceleration solutions.

Regards
Krzysztof Szwaba

Hi,

This is a bit outside the range of my knowledge, I’m afraid. But as far as I know, there are no plans to integrate anything like this in ThinLinc. It seems to me that this would be mostly separate from ThinLinc anyway, so it may be a moot point. Would be interesting to hear from other community members with a bit more knowledge on the subject than me.

Did you try the suggestions above, and did they work for you?