Jump to content

H264 VAAPI hardware encoding not registering despite successful detection (4.9.5.0, Intel Alder Lake-N)".


Recommended Posts

Chadstratts
Posted

Emby Server version: 4.9.5.0 (Linux)

Platform: TerraMaster NAS, Ubuntu 22.04 base, kernel 6.12.63

Hardware: Intel Alder Lake-N (UHD Graphics), driver iHD 25.2.4

Device: /dev/dri/renderD128

Summary:

Hardware acceleration is enabled (EnableHardwareEncoding: true, HardwareAccelerationType: vaapi), and the Hardware Detection scheduled task correctly finds the GPU adapter every time it runs. However, CodecManager's final CodecList always comes back empty for hardware encoders — only software (libx264) ever gets registered, forcing every transcode into full CPU software encoding (250%+ CPU for a single 1080p stream).

Steps I've taken to rule out anything on my end:

Confirmed a manual ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -c:v h264_vaapi encode succeeds completely outside Emby — hardware and driver both work fine.

Confirmed the emby user is in the render group and /dev/dri/renderD128 has correct permissions.

Ran Emby's own bundled ffdetect tool manually — as the emby user, with Emby's exact environment variables (LD_LIBRARY_PATH, LIBVA_DRIVERS_PATH) — using the exact command Emby itself runs (ffdetect ... vaencdec -print_format json). This returns a full, valid Encoders array including H264_MAIN with real capabilities (MaxWidth 4096, RateControl 3294, etc.) and no errors.

Server logs confirm VaapiCodecProvider successfully detects the adapter (Adapter #0: 'Alder Lake-N UHD Graphics') on every Hardware Detection run.

Immediately after that same detection run, the log shows CodecManager: CodecList: with nothing following it — completely empty.

Re-triggering Hardware Detection after fixing permissions doesn't change the outcome.

Already on the latest stable version (4.9.5.0) — this isn't fixed by updating.

Conclusion:

Detection genuinely succeeds and returns valid hardware encoder capability data, but something in how CodecManager parses/consumes VaapiCodecProvider's output is failing silently for this driver version, so the working hardware encoder never gets registered for actual use.

Happy to provide full logs, the raw ffdetect JSON output, or test any patch/beta build if that would help track this down.

 

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...