For Jellyfin HDR playback with subtitles, four versus eight CPU cores is usually the second question, not the first: client compatibility and a supported GPU media engine decide whether the server Direct Plays or performs expensive tone mapping and subtitle burn-in. Choose eight cores only when the same accelerated platform still shows a repeatable CPU-bound subtitle or multi-stream workload that four cores cannot sustain.
Test the Playback Path Before Counting Cores
Hold the test constant: one HDR file, one subtitle track, the same client, playback quality, network path, Jellyfin version, and concurrency. Start playback and read the dashboard mode and FFmpeg log. A core-count result without that context is only a story about two unrelated systems.
Jellyfin documents that Direct Play delivers the file unchanged with almost no additional server load. If the client supports the video, audio, container, and subtitle format, both four-core and eight-core CPUs may sit well below their limits; extra cores cannot improve a path that is already direct.
Continue the comparison only when playback invokes video transcoding, HDR-to-SDR tone mapping, subtitle conversion or burn-in, or several other host workloads. Otherwise the lower-cost four-core system wins by sufficiency, subject to having the same supported media engine and storage/network path.
HDR Tone Mapping Can Make Both CPU Tiers the Wrong Choice
HDR becomes expensive when an SDR client forces the server to tone-map while transcoding. Jellyfin's transcoding documentation says software HDR-to-SDR conversion is so slow that no modern consumer CPU may manage it in real time and therefore recommends a GPU.
That is the hard stop for a core-count-only purchase. A modern four-core CPU with a supported Intel, AMD, NVIDIA, Apple, or Rockchip acceleration path can outperform an eight-core CPU whose GPU, driver, operating system, or container mapping cannot accelerate the required codecs and tone-map stages.
Compare the exact media engine generation and codec matrix before cores. If both candidates support the same full pipeline, resume the four-versus-eight test. If neither does, reject both or change the client/output plan; doubling general-purpose cores is not a reliable substitute for the missing fixed-function path.
Subtitle Burn-In Is the Real Eight-Core Trigger
Subtitles are not one workload. Text subtitles may be passed through or converted, while image subtitles or unsupported styling can force the text or image layer to be burned into video. Jellyfin's codec tables call subtitle burn-in the most CPU-intensive transcoding method.
Hardware acceleration is a pipeline of decode, scaling, tone mapping, subtitle burn-in, and encode stages. Jellyfin notes that some stages cannot be GPU accelerated on every combination and that partial acceleration raises CPU use and can lower transcode speed. That residual work is where extra general-purpose cores can help.
Choose eight cores when the held test shows the four-core system below real-time transcode speed, near sustained CPU saturation, or starving other required services—and the eight-core candidate keeps the same or better supported accelerator. Stop if the bottleneck moves to storage, memory, GPU, thermals, or the network.
Four-Core vs Eight-Core: Conditional Verdict
Four cores win for Direct Play, occasional accelerated transcodes, and a dedicated server whose measured busy window retains CPU headroom. Eight cores win when subtitle burn-in or partial acceleration remains CPU-bound, multiple such streams overlap, or the host must protect Jellyfin from substantial co-hosted work.
Do not compare core count across different processor generations without naming the media engine. An eight-core CPU with older codec support can lose this exact task to a newer four-core chip. The HDR-and-subtitle server guide is the next decision when the whole platform—not just CPU tier—is still open.
Buy the least expensive tier that passes your worst repeatable file, subtitle, client, and concurrency test with recovery room. If neither candidate has a supported hardware path for the required HDR stage, choose a different platform rather than paying for cores that cannot fix the pipeline.
| Observed workload | Four cores | Eight cores | Decision |
|---|---|---|---|
| Direct Play | Sufficient | Idle headroom | Four cores |
| One fully accelerated transcode | Test first | Usually extra margin | Choose by measured headroom |
| CPU subtitle burn-in or partial acceleration | May saturate | Useful if the stage scales | Eight cores after proof |
| Unsupported HDR tone mapping | Poor fit | Poor fit | Choose a supported GPU path |
Product Comparisons
More to Read

Can Home Assistant Replace openHAB for Whole-Home Device Control?
Home Assistant can replace openHAB only when every essential device and automation passes a parallel migration and rollback test.

Mini PC vs Single-Board Server vs NAS for Home Assistant
Pick an SBC for a small efficient appliance, a mini PC for flexible headroom, or a NAS only when shared-host operations are already mature.

How to Choose Between a Dedicated Home Assistant Server and a Shared App Host
Choose dedicated hosting for simpler failure isolation; choose a shared host when isolation, maintenance windows, and recovery are proven.

