DEV Community

John
John

Posted on

Plex Server Sizing: Quick Sync, Discrete GPU or Raw CPU for 3, 5 and 10 Simultaneous Transcodes

#plex #selfhosted #homelab #performance

For almost every household leaving a streaming subscription behind, a modern Intel CPU with an integrated Quick Sync engine and a Plex Pass is the correct answer, and a discrete GPU is money you do not need to spend. Quick Sync handles multiple concurrent 1080p transcodes on a chip that idles at single digit watts, which matters far more than peak throughput on a box that runs 24 hours a day. Raw CPU transcoding only makes sense if you refuse to pay for Plex Pass, because hardware acceleration is a Plex Pass feature, and Plex's own published guidance of roughly 2000 PassMark points per 1080p transcode and roughly 17000 per 4K transcode shows how quickly software encoding runs out of headroom. A discrete NVIDIA card earns its place in exactly one scenario: heavy simultaneous 4K HDR tone mapping for many remote viewers at once.

TL;DR by reader profile:

  • The two viewer household (Maya, watching at home while her sister streams from abroad): a low power Intel mini PC with Quick Sync, because two 1080p transcodes barely register on the iGPU and the box costs less to run than the subscription it replaces.
  • The five stream family (Tom, three kids on tablets plus two remote relatives): a current generation Intel desktop CPU with Quick Sync, an SSD for the transcode directory and 16 GB of RAM, because five concurrent 1080p sessions are comfortably inside one iGPU's budget.
  • The ten stream sharer (Priya, sharing her library with a wide circle of friends): a Quick Sync host plus either a second server or a discrete NVIDIA card, because concurrent session limits and upload bandwidth bite before the encoder does.
  • The 4K HDR remux collector (Daniel, direct playing to an Apple TV but transcoding for everyone else): budget for tone mapping specifically, because HDR to SDR conversion is the single most expensive operation Plex performs per stream.
  • The no Plex Pass holdout (Sam, unwilling to add another recurring charge): buy CPU by PassMark score and plan your library around direct play, because software encoding is the only path open to you.
  • The existing NAS owner (Elena, already running a two bay unit): check whether your NAS CPU has Quick Sync at all before buying anything, because many ARM based units cannot transcode 1080p reliably even once.

The central tradeoff is this: Quick Sync gives you many cheap, low power streams at good but not perfect quality, while a discrete GPU or a large CPU gives you fewer, more expensive streams that survive the hardest 4K HDR and subtitle cases without falling over.

Table of contents

Why does Plex transcode at all, and how do you stop it?

Plex transcodes when the client cannot play the file as it is stored. The server decodes the original video and re encodes it into something the client accepts, and that work is what your hardware budget pays for. Every stream you can push back into direct play costs you nothing but disk reads and bandwidth, so the cheapest transcoding hardware is the transcode you never run.

Four things trigger it, and each has a different fix:

  • Unsupported codec or container: a Chromecast or a smart TV that cannot decode HEVC or AV1 forces a full video transcode. Storing a second H.264 copy of your most watched titles removes it entirely.
  • Bandwidth limits set on the client: the Plex app defaults to a quality cap on remote playback, and a 1080p stream capped at 4 Mbps will be re encoded even though the file itself would play. Setting the client to Maximum in Settings, Video Quality, and enabling "Allow direct play" on the server stops it.
  • Audio the client cannot handle: TrueHD or DTS HD MA on a device expecting stereo AAC triggers an audio only transcode. That path costs a fraction of a video transcode and is usually not worth engineering around.
  • Subtitles that must be burned into the picture: image based formats such as PGS and VOBSUB cannot be passed through, so the video is re encoded. Text based SRT is handed to the client untouched.

The distinction Plex draws in the Dashboard matters. "Direct Play" means untouched, "Direct Stream" means the container is rewrapped but the video is not re encoded, and "Transcode" is the expensive case. Read that label before you buy anything.

What does "3, 5 or 10 simultaneous streams" actually mean?

A stream count on its own tells you almost nothing. Ten people watching 1080p H.264 files on Apple TVs is a smaller load than two people watching 4K HDV remuxes on old smart TVs. Before you size anything, translate your household into transcode units.

Count what your library and your viewers actually produce:

  • Concurrent viewers, not total accounts: a library shared with 30 friends might never exceed 4 sessions at once. Open the Plex Dashboard, leave it running for a fortnight, and use the observed peak rather than the account count.
  • Transcodes, not sessions: if 7 of your 10 sessions direct play, you are sizing for 3 transcodes. This single distinction moves you from a desktop CPU with a discrete card down to a mini PC.
  • Resolution of each transcode: Plex's published guidance puts a 1080p transcode at roughly 2000 PassMark points and a 4K transcode at roughly 17000, so one 4K session is worth about eight 1080p sessions in software.
  • Tone mapping and subtitle burn in per stream: these are per stream multipliers, not fixed overheads, so a household with 5 transcodes where 2 need burned in PGS subtitles is meaningfully heavier than 5 clean ones.
  • Peak overlap window: most households peak for 2 to 3 hours in the evening. Sizing for the 90th percentile of that window rather than the absolute maximum saves real money.

Write the result as a sentence: "peak 5 sessions, of which 3 transcode, 1 of them 4K HDR". That sentence, not the headline number, is what you buy hardware against for the rest of this article.

How much CPU do you need for software only transcoding?

Without Plex Pass, every transcode runs on the CPU, and the sizing rule is arithmetic rather than judgement. Plex publishes PassMark guidance per stream, you look up your candidate chip on cpubenchmark.net, and you divide. Headroom matters because the score is a whole chip figure and your server is also reading disks, scanning the library and running the operating system, so aim to use no more than 70 percent of the total.

Workload per stream Plex published PassMark guidance What that means when you shop
720p transcode Around 1500 points A modern dual core handles two of these and little else
1080p transcode Around 2000 points 3 concurrent streams need roughly 6000 points of usable score
4K transcode Around 17000 points One stream demands more than most mainstream desktop CPUs deliver in total
5 mixed 1080p streams Around 10000 points plus overhead Realistically a 6 core or 8 core desktop chip, not a mini PC
10 concurrent 1080p streams Around 20000 points plus overhead Server or high core count workstation territory

Two practical consequences follow. First, 4K software transcoding is effectively off the table: a single stream at roughly 17000 points costs more silicon than five 1080p streams, which is why 4K libraries are built around direct play or hardware acceleration. Second, software encoding scales by core count rather than clock speed, so an older 12 core Xeon can beat a newer quad core for this one job while drawing far more power for every other hour of the day.

How many streams can an Intel Quick Sync iGPU handle?

More than most households will ever ask of it. Quick Sync is a fixed function media engine, so a 1080p transcode consumes engine time rather than CPU cores, and the same job that pins several software threads shows up as a few percent of CPU load. Intel does not publish a Plex specific stream ceiling, and Plex does not either, so treat the engine as your bottleneck and verify with your own Dashboard rather than trusting a forum number.

What actually determines the answer:

  • Generation, not CPU tier: an i3 and an i7 from the same generation usually carry the same media engine, so paying for more cores buys you nothing for transcoding. Buy the newest generation you can, not the fastest chip in an old one.
  • Codec support by generation: 7th generation added HEVC Main10 decode, 11th generation added AV1 decode, and 12th generation and later Arc based engines added AV1 encode. A file your engine cannot decode falls back to the CPU silently.
  • The F suffix trap: Intel CPUs ending in F, such as an i5 14400F, ship with no integrated graphics at all. This is the single most common way people buy a Plex server that cannot hardware transcode.
  • BIOS and container plumbing: the iGPU is often disabled when a discrete card is installed, and in Docker you must pass the device through explicitly with --device /dev/dri/renderD128. Check with ls /dev/dri before blaming Plex.
  • No artificial session cap: unlike consumer NVIDIA drivers, Quick Sync imposes no vendor limit on concurrent encode sessions, so you scale until quality or engine time degrades.

When does a discrete GPU beat Quick Sync, and where do AMD and Apple Silicon land?

A discrete card wins in one narrow case: many simultaneous 4K HDR transcodes, where tone mapping and high resolution decode saturate a single integrated media engine. Below that threshold you are buying idle wattage and a PCIe slot you did not need.

  • NVIDIA, and the session cap you must check: consumer GeForce drivers have historically capped the number of concurrent NVENC encode sessions, with the cap raised across driver generations. Quadro and RTX professional cards carry no such limit, and community driver patches exist for GeForce cards, so confirm the current cap for your exact card before assuming ten streams will run.
  • AMD Radeon, the least travelled path: Plex supports AMF acceleration, but the tooling, driver behaviour and tone mapping results are less consistently reported than Intel or NVIDIA. Choose it only if you already own the card.
  • Apple Silicon and VideoToolbox: a Mac mini running Plex Media Server with Plex Pass hardware transcodes through VideoToolbox and idles very low, which makes it a credible small server if you accept macOS as your host operating system.
  • Where the server itself lives: the acceleration path available to you is decided by the host, whether that is a NAS, a self built home server, a rented VPS or a managed platform. Yundera is a managed Personal Cloud Server, built on CasaOS, that runs self hosted apps as Docker containers on a server dedicated to the user, and it sits alongside those options rather than replacing the sizing question.
  • Both engines at once: Plex uses one acceleration path per server, so an iGPU plus a card does not add their capacities together.

What 4K HDR tone mapping does to your hardware budget

Tone mapping is the most expensive per stream operation Plex performs. Converting a 4K HDR10 file to SDR for a client that cannot display high dynamic range means decoding 4K, remapping the colour volume frame by frame, scaling and then encoding. Skip this step and the same file is merely a 4K transcode. Include it and your per stream cost rises sharply, which is why one 4K HDR viewer can dictate a build that five 1080p viewers never would.

  • It is a Plex Pass feature with a switch: find it in Settings, Transcoder, "Enable HDR tone mapping". Turning it off does not save you money, it just produces washed out, grey looking video on SDR clients.
  • Generation decides whether it is accelerated: older integrated engines fall back to slower paths for the tone mapping stage even when decode and encode are accelerated, so an eighth generation part and a twelfth generation part are not interchangeable for this workload.
  • Dolby Vision is the sharp edge: Profile 5 files carry no HDR10 base layer, so transcoding them for a non Dolby Vision client commonly yields the well known green or purple cast. Profile 7 and Profile 8 files with an HDR10 base layer behave predictably.
  • The cheapest fix is storage, not silicon: keeping a 1080p SDR H.264 copy beside the 4K HDR original removes the operation entirely for every client that would have triggered it.
  • Host choice does not remove it: a NAS, a home server, a VPS or Yundera all face the same per stream cost, because tone mapping is decided by the file and the client, not the location.

Subtitles: the setting that turns a hardware transcode back into CPU work

You can own the right iGPU, transcode 1080p all evening, and still watch one session collapse because of a subtitle track. Image based subtitles cannot be sent to the client as text, so Plex composites them into the picture, and that burn in step is frequently handled outside the fixed function encoder. The result is a session that shows as hardware accelerated in the Dashboard while CPU load climbs anyway.

  • Know which formats force it: PGS from Blu-ray sources and VOBSUB from DVD sources are bitmap tracks and always burn in. Styled ASS and SSA tracks often burn in too, because their positioning and effects cannot survive being passed as plain text.
  • SRT is the format that costs nothing: a plain text track is handed to the client and rendered there, so the video can direct play untouched. A sidecar file named Movie.2019.en.srt beside the video is the simplest way to get one.
  • Set the client policy deliberately: in Settings, Player, the "Burn Subtitles" option accepts Never, Only image formats and Always. Leaving it on Always converts every text track into an expensive transcode for no benefit.
  • Convert once instead of burning nightly: running your PGS tracks through OCR in a tool such as Subtitle Edit produces SRT files that serve every future playback. One conversion replaces hundreds of transcodes.
  • Forced tracks are the hidden repeat offender: files with forced foreign dialogue subtitles trigger burn in on titles you assumed were direct playing, so audit your most watched foreign language content first.

Budget one extra transcode unit for every stream that burns subtitles, then work to eliminate them.

How much RAM and what scratch disk does the Plex transcoder need?

RAM is rarely the constraint. Plex Media Server itself is modest, and a transcode holds working buffers rather than the whole file, so the memory question is really about how much you can spare for a RAM backed scratch directory. The scratch disk is where careless builds get punished, because every transcoding session writes segment files continuously for as long as someone is watching.

  • Start at 8 GB and choose 16 GB if you use tmpfs: 8 GB runs a small server comfortably, and the second 8 GB exists so you can hand several gigabytes to a RAM disk without starving the operating system's file cache.
  • Move the transcode directory off the media array: set Settings, Transcoder, "Transcoder temporary directory" to an SSD path or to /dev/shm on Linux. Leaving it on a spinning array makes disks seek between reading source files and writing segments while other users are browsing.
  • Understand what the buffer setting costs you: "Transcoder default throttle buffer" defaults to 60 seconds, so each session writes roughly a minute of encoded video ahead of the viewer. Multiply that by your peak transcode count to size the directory.
  • Watch SSD endurance, not just speed: transcoding is a sustained write workload on a drive that is otherwise idle, which is a real argument for tmpfs on a machine with spare RAM.
  • Put the library database on an SSD regardless: com.plexapp.plugins.library.db drives every browse, scan and search, and it is the difference between a client that loads instantly and one that stalls on the home screen.

Size RAM for the scratch directory you intend to use, then stop.

How much upload bandwidth do 3, 5 and 10 remote streams need?

Transcoding capacity is worthless if your upstream cannot carry the result. Remote playback is limited by your upload speed, and most domestic connections are asymmetric, so a household with 500 Mbps down might have 40 Mbps up. Size against Plex's own quality presets, which are the bitrates your viewers will actually select, and add roughly 20 percent of headroom for protocol overhead and anything else using the line.

Concurrent remote streams Upload required at the 1080p 8 Mbps preset Practical note
3 streams Around 24 Mbps plus overhead, so 30 Mbps Within reach of most fibre and some cable uploads
5 streams Around 40 Mbps plus overhead, so 48 Mbps Rules out most VDSL and older cable connections
10 streams Around 80 Mbps plus overhead, so 96 Mbps Symmetric fibre or a hosted server territory
3 streams at the 20 Mbps 1080p preset Around 60 Mbps plus overhead, so 72 Mbps Quality preset matters more than stream count
1 stream of an untranscoded 4K remux Frequently 50 Mbps or more, depending on the file Direct play saves CPU and spends bandwidth instead

Two controls keep this predictable. Settings, Server, Remote Access carries a "Limit remote stream bitrate" option that caps what any single remote viewer can pull, which protects the connection at the cost of forcing more transcodes. Separately, if direct connection fails and sessions fall back to Plex Relay, throughput is capped at 1 Mbps, or 2 Mbps with Plex Pass, which is why a working port forward or reverse proxy matters more than any encoder.

What Plex Pass unlocks, and why it changes the hardware maths

Hardware transcoding is a Plex Pass feature. That single fact reframes the whole build, because the choice is not "iGPU or CPU", it is "pay for a subscription and buy a small machine" against "pay nothing recurring and buy a large one". For a reader who has just cancelled a streaming service, the second option often costs more in the first year and far more in electricity across three.

  • Hardware accelerated encode and decode: without a Pass, Plex ignores Quick Sync, NVENC and VideoToolbox entirely, no matter what silicon you installed.
  • Subscription shape, not a single price: Plex Pass is sold as a monthly plan, an annual plan and a one time lifetime purchase, so the comparison against a bigger CPU is a three year total, not a monthly line item.
  • Server side background work: intro and credit detection, chapter thumbnails and loudness analysis run as scheduled tasks on your server. They consume CPU outside playback hours, which is an argument for keeping some general purpose headroom even on a Quick Sync build.
  • Mobile downloads change your peak: synced offline copies are transcoded once, at full speed rather than in real time, so a single sync job can briefly load the machine harder than three live streams.
  • The Pass follows the account, not the machine: you can move your server between a NAS, a self built box, a VPS or Yundera without repurchasing, so the hardware decision stays reversible.

Decide the Pass question first. Every sizing number in this article changes depending on the answer.

Three reference builds sized for 3, 5 and 10 concurrent transcodes

These three builds assume Plex Pass, 1080p transcodes with SDR sources, and the scratch directory already moved off the media array. Adjust upward if your peak sentence from earlier includes 4K HDR or burned in subtitles.

Target load Core hardware Why this is the cut off
3 concurrent 1080p transcodes Intel N100 or N305 mini PC, 16 GB RAM, 500 GB NVMe for the database and scratch A twelfth generation media engine covers this load while the whole machine draws less power than a single desktop GPU at idle
5 concurrent 1080p transcodes Intel Core i3 or i5 desktop of a recent generation, non F model, 16 GB RAM, separate NVMe Same engine class in a chassis with room for drives and a 3.5 inch bay backplane
10 concurrent 1080p transcodes Recent Intel Core i5 or i7, non F model, 32 GB RAM, NVMe scratch, symmetric fibre upstream Bandwidth and library database contention arrive before the encoder saturates
3 concurrent 4K HDR transcodes Recent Intel Core i5 with Arc based graphics, or an NVIDIA RTX card in a tower Tone mapping at 4K is the workload that justifies discrete silicon
No Plex Pass, any count High core count desktop or used workstation CPU, sized by PassMark Software encoding scales by cores, so the chassis, cooling and power bill all grow

Two notes apply to every row. Buy the storage array separately from the compute decision, because drives do not affect transcoding. And validate with intel_gpu_top or the Plex Dashboard under real load before adding hardware you assumed you needed.

Top comments (0)