Jellyfin N100 Transcoding Settings: The Exact Setup

The correct Jellyfin N100 transcoding settings fit on one screen: Dashboard → Playback → Transcoding, hardware acceleration set to Intel QuickSync (QSV), every decode codec the chip supports ticked, hardware encoding on, and Enable VPP tone mapping ticked for HDR. That is genuinely most of it — but the difference between “it works” and “it works well” lives in a handful of less obvious choices: which tone mapper, the Linux driver and firmware underneath it, Docker device permissions, and knowing how to prove the iGPU is actually doing the work rather than the four little E-cores.

Everything below comes from the server under my own TV: an Intel N100 mini PC with 16GB of RAM and a 512GB SSD that cost about £139. Measured at the wall it idles at 6 W and sits around 11 W streaming 1080p direct play, which at my 27p/kWh works out to roughly £15 a year. It is the reference build for this whole site — the budget Jellyfin server hub covers why I picked it — so when I say a setting matters, it is because I have toggled it on this exact box.

What the N100 actually gives you

The N100 is four Alder Lake E-cores with no hyperthreading, and on their own they are poor transcoding hardware — a single software 4K HEVC transcode will flatten them. The reason the chip is everywhere in budget Jellyfin builds is the iGPU: a cut-down UHD-class part with the same Quick Sync media engine as Intel’s 12th-gen desktop chips. It decodes H.264, HEVC in both 8-bit and 10-bit, VP9, and AV1 in hardware, and it encodes H.264 and HEVC. There is no AV1 encode, which is fine — Jellyfin transcodes to H.264 or HEVC anyway.

The practical takeaway: the CPU cores are nearly irrelevant to playback. Your job in the settings page is to make sure every stream goes through the media engine and never falls back to software. If you want the background on why that matters so much, my hardware transcoding guide covers the theory; this page is just the N100-specific checklist.

The settings walkthrough: Dashboard → Playback → Transcoding

Open the admin dashboard, then Playback → Transcoding. Set Hardware acceleration to Intel QuickSync (QSV). On Linux, QSV is the right pick over VA-API — it rides on top of the same driver but unlocks the better-tuned encoder paths and the VPP tone mapper. Then tick the following:

• Enable hardware decoding for: H264, HEVC, HEVC 10bit, VP9, VP9 10bit, AV1, MPEG2, VC1. Everything the chip can decode, ticked. Leaving one unticked silently pushes that codec onto the E-cores.
• Enable hardware encoding — ticked. This is the half people forget; decode-only still burns CPU on the encode side.
• Allow encoding in HEVC format — I leave this on. HEVC output halves the bitrate for remote streams, and the N100’s HEVC encoder is barely more expensive than H.264. Turn it off only if you have old clients that choke on HEVC.
• Prefer OS native DXVA or VA-API hardware decoders — leave unticked when using QSV on Linux.

VPP tone mapping vs standard tone mapping

HDR-to-SDR tone mapping is the thing most likely to sink an N100, so this choice matters. Enable VPP tone mapping uses the fixed-function video post-processing block inside the media engine — it is dramatically cheaper than the standard OpenCL tone mapper, which runs as compute shaders on the same small GPU that is already busy decoding and encoding. The trade-off is flexibility: VPP ignores most of the fine-tuning options (tone mapping algorithm, peak luminance overrides) and its output is slightly more matter-of-fact — a touch less highlight roll-off than the bt2390 OpenCL path. On a desktop-class iGPU I would consider standard tone mapping; on an N100, tick VPP and do not look back. If both are enabled, Jellyfin uses VPP where the content allows and falls back to OpenCL for things VPP cannot handle, such as HDR10+ and Dolby Vision profiles that need per-scene metadata.

Low-power encoding on Linux: driver and firmware

On Linux you need the modern intel-media-driver (the iHD driver), not the legacy i965 package — Alder Lake-N is not properly supported by the old one. There is also a firmware wrinkle specific to these low-power chips: the N100’s encoders run in “low-power” (VDEnc) mode, which requires the GuC/HuC firmware to be loaded by the kernel. On my box, HEVC encodes failed with cryptic ffmpeg errors until I added i915.enable_guc=2 to the kernel parameters and rebooted. You can confirm HuC is running with cat /sys/kernel/debug/dri/0/gt/uc/huc_info — you want to see running. Most 2024-or-later distros enable this out of the box, but if encodes fail while decodes work, check here first. The official Jellyfin Intel acceleration docs have the full distro-by-distro detail.

Throttling and segment retention

Two settings further down the page earn their keep on a small box. Throttle transcodes makes ffmpeg pause once it has buffered a few minutes ahead instead of racing to the end of the file — that keeps the chip near idle for most of a viewing session rather than pinned for the first twenty minutes. Delete segments (segment retention) bins old transcoded chunks behind the playhead, which protects a 512GB SSD from filling up during a long 4K film. The cost is that seeking backwards re-transcodes; with throttling on, that is a couple of seconds of spinner, and I think it is worth it.

Docker: pass the GPU through properly

If Jellyfin runs in Docker — mine does — the container needs the render node. Pass --device /dev/dri:/dev/dri (or the devices: equivalent in compose). Then sort permissions: /dev/dri/renderD128 is owned by the render group on most distros (video on some older ones), and the container user has to be in it. Find the GID with getent group render and add it via group_add: [989] — using the number, not the name, because the group may not exist inside the image. The classic symptom of getting this wrong is QSV mysteriously falling back to software with a permission-denied line buried in the ffmpeg log.

How to verify it is actually working

Do not trust the settings page — verify. Three checks, in increasing order of rigour:

1. Playback Info overlay. Play something that forces a transcode, open playback info on the client, and look for Transcoding (hardware) plus the reason. “Video codec not supported” with hardware transcoding is fine; seeing (software) means a checkbox or permission is wrong.
2. The ffmpeg log. Dashboard → Logs, open the latest FFmpeg.Transcode*.log. You want to see -init_hw_device qsv near the top and an encoder like hevc_qsv or h264_qsv in the command line — if it says libx264, you are in software.
3. intel_gpu_top. Install intel-gpu-tools and run it during a transcode. The Video engine row should show real utilisation while overall CPU stays low. A hardware transcode that pins all four cores is not a hardware transcode.

Realistic limits on an N100

With everything above set correctly, my box handles four to five simultaneous 1080p H.264 transcodes without stuttering, and one 4K HEVC-to-1080p tone-mapped transcode comfortably — a second 4K tone-mapped stream works but leaves no headroom, and I would not plan a household around it. Subtitle burn-in is the hidden tax: image-based PGS subtitles force a transcode on their own and the compositing roughly halves the streams the box can sustain. If your viewing is mostly 4K remuxes with PGS subs for multiple users at once, an N100 is the wrong chip — my mini PC buying guide covers what to step up to.

When it still struggles, fix the client instead

Most “my N100 can’t keep up” complaints are actually one client forcing transcodes it does not need. A Fire TV Stick 4K direct plays HEVC 10-bit and even outputs HDR, so a properly set up stick turns your heaviest 4K stream into a near-zero-cost direct play — my Jellyfin Fire TV Stick guide walks through it. I care about this end of the pipeline enough that I maintain my own custom build of the official Android TV client (a personal fork of jellyfin-androidtv v0.19.7) as my daily driver, and fixing client playback profiles has solved more “transcoding problems” for me than any server setting. The other lever is pre-optimising the library: if one show always transcodes for one device, re-encode it once overnight rather than live on every watch.

Common N100 gotchas

Three things bite N100 owners that have nothing to do with the Jellyfin settings page. First, the platform is single-channel memory only, and some cheap variants ship slow soldered RAM — it barely affects transcoding, but it is why benchmarks of the “same” chip vary between vendors. Second, BIOS power limits: vendors set PL1 anywhere from 6 W to 15 W and some boxes throttle hard under sustained tone-mapping load; if a long 4K transcode degrades after ten minutes, check the power limit and cooling before blaming Jellyfin. Third, the low idle figures depend on power management — my 6 W at the wall needed PCIe ASPM enabled in the BIOS plus powertop --auto-tune on boot; without them the same box idles several watts higher, which compounds over a year. Plug your own numbers into the home server power calculator to see what your tariff makes of it.

That is the whole setup: QSV on, every decode box ticked, VPP tone mapping, the iHD driver with HuC firmware underneath, the render group sorted in Docker, and a quick intel_gpu_top to prove it. Set it once, verify it once, and the N100 quietly becomes the best price-to-performance transcoding box you can put under a TV.