Enable Intel VA-API Hardware Acceleration in Firefox on Rocky/RHEL Linux

Introduction

Modern web browsers can offload video decoding from the CPU to the GPU, a feature known as hardware video acceleration. On a laptop, this reduces CPU usage, lowers temperatures, decreases fan noise, and improves battery life during video playback — all things this series has been working toward since Part 1.

During the optimization of the same Intel Ice Lake laptop running Rocky Linux 9.8 with Xfce, OpenGL acceleration worked correctly out of the box, but hardware video decoding did not. This guide documents that troubleshooting process end to end: from a failing vainfo test to a fully working Firefox hardware decoding pipeline, including the YouTube codec quirk that undoes the fix if left unaddressed.

Why Hardware Video Decoding Matters

Without hardware acceleration, the CPU decodes every video frame in software. Streaming high-resolution video can noticeably increase CPU utilization, battery drain, and system temperature — especially on a dual-core, thermally limited laptop CPU. When VA-API is working correctly, the Intel GPU performs most of the decoding work for supported codecs such as H.264, VP9, and HEVC, freeing the CPU for everything else.

Before You Begin

Test Platform

Important warnings

Step 1: Verify Basic Graphics Acceleration

Before troubleshooting VA-API, confirm that OpenGL acceleration itself is working:

glxinfo -B

What it does: Reports whether direct rendering is available and which renderer Mesa is using. Expected output: Direct rendering: Yes, an Intel renderer string, and Accelerated: Yes. Reboot required: No. Risk: None — read-only diagnostic.

Next, confirm the kernel graphics driver is loaded:

lspci -k | grep -A3 VGA

The important line to look for is:

Kernel driver in use: i915

In the validation environment, both checks passed — OpenGL acceleration and the i915 kernel driver were functioning correctly. That confirmed the graphics hardware itself was healthy, and any remaining problem would be specific to video decoding.

Step 2: Test VA-API and Identify the Failure

Test the Video Acceleration API directly:

vainfo

What it does: Attempts to initialize a VA-API driver and list supported codec profiles. Expected output on a working system: Driver name, VA-API version, and a list of supported profiles. Reboot required: No. Risk: None.

In the validation environment, this command failed instead of listing codecs. The system searched for both iHD_drv_video.so and i965_drv_video.so, but neither driver initialized successfully — indicating that the graphics hardware was working, but no compatible video acceleration driver was actually installed.

Checking installed packages

rpm -qa | grep -E 'mesa|libva|intel'

What it does: Lists installed packages matching the graphics stack. Expected output: Mesa libraries, libva, and possibly intel-mediasdk. Reboot required: No. Risk: None.

This confirmed Mesa, libva, and intel-mediasdk were present, but the required Intel Media Driver file was still missing from the driver directory.

Step 3: Why the Legacy i965 Driver Was Not Enough

The first troubleshooting attempt installed the legacy Intel VA-API package:

sudo dnf install libva-intel-driver

This successfully installed i965_drv_video.so. Testing again:

LIBVA_DRIVER_NAME=i965 vainfo

Initialization still failed. What it does: Forces vainfo to load the i965 driver specifically. Expected output on compatible hardware: Codec profile list. Reboot required: No. Risk: Low.

The reason is architectural: the legacy i965 driver supports older Intel GPU generations, while the validation system's Ice Lake (Gen11) GPU requires the newer Intel Media Driver (iHD). Installing the wrong driver family can still leave hardware decoding unavailable even though the install itself succeeds without error.

Step 4: Finding the Correct Driver

Searching the default repositories initially produced confusing results — the legacy libva-intel-driver package was visible, but the modern Intel Media Driver was not, because the RPM Fusion Nonfree updates repository was disabled. After enabling that repository, the search succeeded:

dnf search intel-media-driver

The package listing confirmed it would provide /usr/lib64/dri/iHD_drv_video.so — the file the earlier vainfo attempt had been unable to find.

Step 5: Install the Intel Media Driver

sudo dnf install intel-media-driver

What it does: Installs the modern Intel iHD VA-API implementation required for Gen9+ and Ice Lake graphics, distinct from the older i965 driver. Expected output: Successful transaction summary. Reboot required: No. Risk: Low.

Verify the driver file now exists:

ls -l /usr/lib64/dri/iHD_drv_video.so

The file should be present after installation.

Step 6: Verify VA-API

LIBVA_DRIVER_NAME=iHD vainfo

What it does: Forces vainfo to initialize the iHD driver and list supported codec profiles. Expected output: Intel iHD driver name, VA-API version, and supported profiles — no initialization errors. Reboot required: No. Risk: None.

In the validation environment, this produced a successful result listing typical Ice Lake codec support:

A successful vainfo test like this is one of the strongest indicators that hardware video decoding is correctly configured at the system level.

Step 7: Configure Firefox

Open about:support and check the following items:

Next, open about:config, accept the risk warning, and confirm these preferences are enabled:

media.ffmpeg.vaapi.enabled = true
media.hardware-video-decoding.enabled = true
media.rdd-ffmpeg.enabled = true

What it does: Allows Firefox's media pipeline to use VA-API for supported codecs instead of decoding in software. Expected output: All three preferences show true; about:support reports Hardware Video Decoding as Available after a restart. Reboot required: No — restarting Firefox is enough. Risk: Low.

Step 8: Fixing YouTube Codec Selection

Even with VA-API fully working, YouTube frequently selected the AV1 codec during testing. AV1 offers excellent compression efficiency, but the Intel Core i3-1005G1 has no dedicated AV1 hardware decoder — so Firefox fell back to decoding AV1 on the CPU, silently undoing the benefit of the VA-API setup for that site.

Installing the Firefox extension enhanced-h264ify solved this. Recommended configuration:

Blocking only AV1 lets YouTube fall back to VP9, which the Intel GPU can decode through VA-API. For most other streaming services, codec selection is controlled by the site itself — if it serves H.264, VP9, or HEVC, the Intel GPU can usually decode it through the pipeline configured in this guide.

Observed Benefits

After completing this configuration, the changes were measurable rather than anecdotal:

• Firefox reported Hardware Video Decoding as Available in about:support.
• Supported videos used GPU decoding instead of software decoding.
• CPU usage during streaming decreased noticeably.
• Laptop temperatures remained lower during extended playback.
• Fan noise reduced during video-heavy sessions.
• Battery life improved while watching online video, complementing the gains from Part 1 of this series.

Conclusion

Hardware video acceleration depends on several components working together: the kernel graphics driver, Mesa libraries, the correct Intel VA-API driver, and browser support. A single missing or mismatched component — in this case, the absence of the iHD driver — can prevent the entire pipeline from functioning even when everything else looks correct.

By installing the modern Intel Media Driver, verifying VA-API with vainfo, and configuring both Firefox and YouTube's codec selection, this Rocky Linux laptop achieved reliable hardware decoding for H.264, VP9, and HEVC content — a cooler, quieter system with lower CPU usage and better battery life during multimedia playback. Part 3 of this series continues with a PowerTOP deep dive to measure and extend these gains further.