Jellyfin Intel Quick Sync in Docker Compose

Everything below follows Jellyfin's own Intel hardware acceleration guide. Where this page changes one of its examples, it says what changed.

#QSV or VA-API?

On Linux, Jellyfin's docs list two ways to drive an Intel GPU:

• QSV: preferred on mainstream GPUs, for better performance. Linux QSV works on Broadwell (5th gen Core) and newer.
• VA-API: needed for pre-Broadwell GPUs. It supports nearly all Intel GPUs.

On Windows, QSV is the only option. So for any Intel chip from the last several years, pick QSV. One caution from the docs: Ice Lake, Jasper Lake, Elkhart Lake and older chips are losing QSV support on Linux because Intel deprecated the MediaSDK runtime. They may stop working with QSV "in a few years", at which point you'd switch them to VA-API.

#Prerequisites

• An Intel CPU with integrated graphics, or an Intel Arc card. Models ending in "F" have no iGPU, and the docs tell you not to use them.
• A 64-bit Linux host. The Linux setup section says this is required.
• Docker with the Compose plugin.
• A recent enough kernel for your GPU. The known-issues page lists minimums. Arc A-series needs Linux 6.2+. Arc B-series needs 6.12+ and Resizable BAR switched on. The N150, N250 and N350 (ADL-N Refresh) need 6.9+.
• Jellyfin 10.9 or later if you want AV1 encoding. The current release is 12.1, published 15 September 2026, so any fresh install qualifies.

If you're still choosing hardware, the Jellyfin profile summarises the project's hardware guide. It recommends an Intel N100 or an i5-11400 class chip with 8GB of RAM.

#Step 1: check that the host sees the GPU

Jellyfin's docs suggest lspci to list the GPU:

lspci -nn | grep -Ei "3d|display|vga"

Then confirm that at least one render device exists:

ls -l /dev/dri

What you should see: a renderD128 entry owned by the render group, as in the docs' example (crw-rw----+ 1 root render 226, 128 ... renderD128). If there's no renderD* device, the docs say to upgrade your kernel or enable the iGPU in the BIOS. A second GPU shows up as renderD129.

#Step 2: find the render group's ID

The container needs the host's numeric group ID, not the group name:

getent group render | cut -d: -f3

What you should see: a single number. The docs' examples use 122, but yours may differ, so use whatever the command prints. On some releases, the docs note, the group is video or input instead of render. The group that owns renderD128 in step 1 is the one you want.

#Step 3: write the compose file

This is the docker-compose example from Jellyfin's Intel guide, with three changes, marked in the comments:

services:
  jellyfin:
    image: jellyfin/jellyfin
    container_name: jellyfin            # added, so the docker exec checks below work
    user: 1000:1000
    group_add:
      - '122'                           # replace with the number from step 2
    network_mode: 'host'
    volumes:
      - /path/to/config:/config
      - /path/to/cache:/cache
      - /path/to/media:/media
    devices:
      - /dev/dri/renderD128:/dev/dri/renderD128
    restart: 'unless-stopped'           # added, as in the docs' docker run example

What changed and why:

• container_name: jellyfin comes from the docs' general container example. Without it, Compose gives the container a generated name, and the docker exec -it jellyfin ... checks in step 5 won't find it.
• restart: 'unless-stopped' matches the --restart=unless-stopped flag in the docs' own docker run version of the same setup.
• The group_add comment was reworded. The docs' comment says to change the value to match your render group ID and then delete the comment.

Set user: to the UID and GID that own your media and config folders. Replace the three /path/to/... paths with real directories. The docs also suggest putting the cache on an SSD or a RAM disk, because on modern GPUs the transcoder can end up waiting on disk I/O.

Ports. With network_mode: 'host' there's no ports: section. Jellyfin listens directly on the host's port 8096. If you'd rather use bridge networking, drop network_mode and add the mappings from the docs' container page: 8096:8096/tcp for the web interface and 7359:7359/udp for client auto-discovery.

#Step 4: start the container

docker compose up -d

Open http://your-server-ip:8096 and finish Jellyfin's setup wizard if this is a new install.

#Step 5: confirm the container can use the GPU

Run the two checks from the Intel guide's Docker section. First, list the QSV and VA-API codecs the GPU exposes:

docker exec -it jellyfin /usr/lib/jellyfin-ffmpeg/vainfo

What you should see: a driver line naming the Intel iHD driver, followed by "Supported profile and entrypoints". Per the docs, iHD means both QSV and VA-API work. If you see the older i965 driver instead, only VA-API is available, and that should only happen on pre-Broadwell chips.

Then check the OpenCL runtime, which Jellyfin uses for HDR tone-mapping:

docker exec -it jellyfin /usr/lib/jellyfin-ffmpeg/ffmpeg -v verbose -init_hw_device vaapi=va -init_hw_device opencl@va

What you should see: lines naming your Intel GPU and reporting that the QSV-to-OpenCL mapping functions were found, as in the docs' sample output.

#Step 6: switch on QSV in Jellyfin

The docs' instruction is short: "Enable QSV or VA-API in Jellyfin and uncheck the unsupported codecs." In the Jellyfin dashboard, open the transcoding settings and choose QSV as the hardware acceleration method. Leave the device as the default /dev/dri/renderD128 unless you passed through renderD129. The docs say to change it in the dashboard in that case.

For the decoding checkboxes, tick only what your GPU generation supports. From the Intel guide:

Jasper Lake and Elkhart Lake chips (the N5095, N5105, N6005 and J6412 family) have no AV1 acceleration. Hardware HDR and Dolby Vision tone-mapping works on any Intel GPU that can decode HEVC 10-bit.

The docs mention two tone-mapping methods. OpenCL supports Dolby Vision profile 5 and has more tuning options. QSV VPP uses less power but has fewer options and is Linux-only. For Dolby Vision, the docs say the "Prefer OS native DXVA or VA-API hardware decoders" option must be ticked.

#Step 7: prove it's the GPU doing the work

Install intel-gpu-tools on the host, not in the container:

sudo apt update && sudo apt install -y intel-gpu-tools

Play a video in the Jellyfin web client and force a transcode by picking a lower quality or bitrate. Then run:

sudo intel_gpu_top

What you should see: activity on the Video engine, which the docs identify as the QSV decoder and encoder. Tone-mapping and scaling show up under Render/3D or VideoEnhance. If those engines stay idle while the stream plays, the transcode is running on the CPU.

#What to do next

• Remote access. Jellyfin's hardware guide says the server "is not designed to be exposed directly to the internet." Put it behind a proxy with HTTPS: see reverse proxy for a homelab: Caddy or Nginx Proxy Manager.
• Coming from Plex? Hardware transcoding in Jellyfin needs no subscription. The differences are in Jellyfin vs Plex and Plex alternatives.
• Thinking of a Raspberry Pi instead? Jellyfin has deprecated Pi hardware acceleration, and the Pi 5 has no hardware encoder. See the best self-hosted apps for a Raspberry Pi for what suits one.
• Full requirements and versions are on the Jellyfin profile.