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)
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 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.
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:
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.
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?
but if/when you have