You open a 4K video file and your laptop sounds like a jet engine
You start a high-bitrate YouTube stream or drop a local MKV file into your player. The fan immediately ramps up. Your CPU usage spikes to ninety percent. The video stutters, and your battery drains in an hour. You are not doing anything wrong. Your system is using the CPU to decode video frames instead of handing the work to the GPU. Fedora ships with the base video acceleration libraries, but it leaves the actual driver installation to you. This keeps the base system lean and avoids pulling in hardware-specific firmware on machines that do not need it. You need to install the correct VA-API driver and point your media stack at it.
What is actually happening
Video decoding is mathematically expensive. A modern codec like H.265 or AV1 requires millions of calculations per second to reconstruct frames from compressed data. Software decoding runs those calculations on your general-purpose CPU cores. That works, but it burns power and leaves fewer cores for your actual work. Hardware decoding offloads that math to dedicated silicon on your graphics card. The Video Acceleration API (VA-API) is the Linux standard for this offloading. It provides a consistent interface between your media player and the GPU driver.
Think of VA-API as a universal translator. Your browser or video player speaks the translator. The translator speaks the GPU. The GPU does the heavy lifting. Fedora includes the libva base library by default. It does not include the hardware-specific backend drivers. You must install the backend that matches your silicon. The drivers communicate with the kernel through the Direct Rendering Manager (DRM) subsystem. DRM handles memory mapping and command submission. KMS (Kernel Mode Setting) handles display output. VA-API sits on top of DRM and exposes hardware acceleration to userspace applications.
The runtime reports capabilities using profiles and entrypoints. A profile defines the codec and level, like VAProfileH264Main or VAProfileAV1Profile0. An entrypoint defines how the data is processed, like VAEntrypointVLD for video decode. When your player requests a profile, the driver checks if the hardware supports it. If it does, the driver allocates GPU memory and submits decode commands. If it does not, the player falls back to software decoding. You need the correct driver package to register those profiles with the runtime.
The fix for Intel GPUs
Modern Intel integrated graphics (Gen 9 and newer, roughly 2015 and later) use the intel-media-driver. This is the actively maintained, open-source driver that supports modern codecs like AV1 and HEVC. Older hardware or specific legacy applications sometimes require the libva-intel-driver. You can install both without conflict. The system will prefer the modern driver automatically.
Here is how to install the Intel stack and the diagnostic tool you will need to verify it.
sudo dnf install intel-media-driver libva-intel-driver libva-utils # Install the modern driver, legacy fallback, and diagnostic tools
sudo dnf install intel-gpu-tools # Install monitoring utilities to verify hardware usage later
# libva-utils provides the vainfo command for runtime queries
# intel-gpu-tools provides intel_gpu_top for real-time monitoring
The packages drop the shared libraries into /usr/lib64/dri/. The libva runtime scans that directory automatically. You do not need to edit configuration files. Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. Manual file edits drift during updates, while package-managed files stay consistent.
If you run into an application that refuses to use the hardware driver, you can force it with an environment variable.
Here is how to force a specific driver for a single application session.
LIBVA_DRIVER_NAME=iHD mpv video.mp4 # Force the modern Intel driver for this specific command
# iHD is the internal identifier for intel-media-driver
# The variable only affects the current shell session or command
The fix for AMD GPUs
AMD integrated and discrete graphics use the Mesa driver stack. The VA-API backend is bundled directly inside the libva-mesa-driver package. This driver covers everything from older GCN architectures to modern RDNA3 chips. It handles H.264, HEVC, and AV1 depending on your exact GPU generation.
Here is how to install the AMD VA-API backend and the verification tool.
sudo dnf install libva-mesa-driver libva-utils # Install the Mesa VA-API backend and diagnostic tools
# libva-mesa-driver provides the radeonsi driver for VA-API
# The package integrates with your existing Mesa graphics stack
AMD does not require legacy fallback packages. The Mesa driver handles all supported hardware through a single backend. Install it and move to verification.
Configure your media stack
Installing the driver is only half the battle. Your media player must be told to use hardware decoding. Most modern players enable it by default, but some require explicit flags or settings adjustments.
VLC uses hardware decoding automatically if the driver is present. If you see stuttering, open Preferences, navigate to Input and Codecs, and change Hardware-accelerated decoding to Automatic or VA-API. Save and restart VLC.
mpv enables hardware decoding by default. If you need to force it, add --hwdec=vaapi to your command line or add hwdec=vaapi to your ~/.config/mpv/mpv.conf file.
Browsers require a different approach. Firefox uses about:support. Chrome and Chromium use chrome://gpu. Look for the Video Decode section. It should say Hardware accelerated or Enabled. If it says Software only, your browser is falling back to the CPU. Clear your browser cache and restart. Some browsers cache the GPU capability check on first launch. You can also force browser hardware decoding by setting the MOZ_DISABLE_RDD_SANDBOX=0 environment variable for Firefox, though this is rarely needed on modern Fedora releases.
Verify it worked
The vainfo command queries the VA-API runtime and prints the supported profiles and entrypoints. Run it immediately after installation.
Here is how to check which driver is active and which codecs are available.
vainfo # Query the VA-API runtime for active driver and supported profiles
# Look for libva info: va_openDriver() returns 0
# A positive return value means the driver loaded successfully
If the output lists profiles like VAProfileH264Main, VAProfileHEVCMain, or VAProfileAV1Profile0, your hardware decoding is active. If you see unknown driver or a long list of VAProfileNone, the runtime cannot find the backend. Check your package installation first. Reboot before you debug. Half the time the symptom is gone.
You can also monitor real-time GPU usage. The intel_gpu_top command shows decode engine utilization for Intel chips. AMD users can use radeontop or amdgpu_top. If the decode engine shows activity while you play video, the offloading is working. If the CPU spikes and the GPU decode engine stays at zero, your player is still using software decoding.
Common pitfalls and what the error looks like
The most common failure is a missing firmware blob. Intel and AMD GPUs sometimes require microcode updates to initialize the video engine. Fedora ships most firmware in the linux-firmware package, but it is not always installed by default on minimal setups.
Here is how to check if your firmware package is present and up to date.
sudo dnf install linux-firmware # Ensure the base firmware repository is installed
# This package contains microcode for Intel, AMD, and wireless chips
# Reboot after installation to load updated microcode into the kernel
Another frequent issue is containerized or sandboxed applications. Flatpak apps and Docker containers do not automatically see the /dev/dri/renderD128 device node. VA-API requires direct access to that character device. If vainfo works in your terminal but fails inside a Flatpak, you need to grant the device permission.
Here is how to grant Flatpak access to the video acceleration device.
flatpak override --user --device=dri org.videolan.VLC # Grant VLC Flatpak access to the DRI device node
# The --user flag applies to your current account only
# Replace the app ID with the actual Flatpak identifier you are using
You will also see failures when the X server or Wayland compositor is not running. VA-API requires a running display server to initialize the DRM subsystem. Running vainfo from a TTY without a graphical session will fail. Start your display manager or switch to a graphical TTY first.
If you see [FAILED] Failed to start display-manager.service during boot, your graphics stack is broken at a lower level. Fix the display server before troubleshooting video decoding. Run journalctl -xe to read the actual error before guessing. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style.
When to use this vs alternatives
Hardware decoding is not always the right choice. Pick the right tool for your workload.
Use VA-API when you are watching high-bitrate video, streaming 4K content, or trying to preserve laptop battery life. Use software decoding when you are running a headless server, processing video in a virtual machine without GPU passthrough, or debugging codec compatibility issues. Use proprietary GPU stacks when you require CUDA acceleration for AI workloads or need specific vendor SDKs that bypass the open-source stack. Stay on the default Fedora configuration if you only watch standard definition content and your CPU handles it without thermal throttling.