Bar chart with three states. At 1080p: current software-only setup about 4.5 simultaneous transcodes, repairing the Quadro P1000 about 7 (up 56%), moving to an M4 Mac mini about 20 (2.9 times). At 4K HDR to 1080p: about 0.5, then 3 (6 times), then 8 (2.7 times).

Plex Transcode Capacity: Where We Are, a Repaired GPU, and an M4 Mac mini

BySimon

Transcoding capacity is not a single number, it is a decision with steps. So rather than compare two machines in the abstract, here are the three states actually available to me for the same Plex library: the box as it stands, the same box with its accelerator repaired, and a move to an M4 Mac mini.

Each step has a different price and a different payoff. The point of the chart below is to show that the free step is not the small one.

What each state actually is

Where we are now — OcontoPlex (10.7.7.41)

  • A VMware VM on an ESXi host, presenting an Intel Core i7-9800X — 8 cores and 16 threads, PassMark CPU Mark 19,753 with a 2,527 single-thread score.
  • 8 vCPU and 8 GB RAM allocated to it. The wiki and NetBox both record 16 GB; the guest reports 8 GB by three independent counters, so the records are wrong.
  • Windows Server 2016 (build 14393) — which Plex explicitly supports, alongside Windows 10 and newer. The 199 GB system drive has 108 GB free.
  • Plex Media Server 1.43.4.10903, with hardware acceleration already switched on in the settings.
  • A Quadro P1000 passed through — 4 GB, GP107, Pascal, one NVENC engine, one NVDEC engine, and an eight-session encode limit. It is currently sitting in device error Code 43, so it contributes nothing today.
  • WAN upload capped at 9 Mbps.
A row of computer servers housed in server racks.
Server racks — the kind of shared host the OcontoPlex VM runs on. Photo by CSIRO, CC BY 3.0.

Fix the Quadro P1000

Same box, same 8 vCPU, no new hardware. Just a working accelerator and a different ceiling. The P1000’s published capability is around fourteen 1080p streams of raw throughput, but the limit that actually binds is NVIDIA’s eight-session encode cap on low-end Quadro cards — a limit Plex’s own documentation acknowledges as a driver restriction, and one that applies to Intel Quick Sync users not at all.

Move to an M4 Mac mini, 24 GB

  • Apple M4: 10-core CPU (4 performance cores, 6 efficiency cores), 10-core GPU, 16-core Neural Engine, 120 GB/s memory bandwidth.
  • A dedicated media engine: hardware H.264, HEVC, ProRes and ProRes Raw, with its own video decode engine and video encode engine, plus AV1 decode.
  • 24 GB unified memory, macOS, 155 W maximum continuous power per Apple’s specs.
An Apple Mac mini M4 compact desktop computer from 2024.
An M4 Mac mini — the machine the comparison recommends. Photo by Seasider53, CC BY 4.0.

The line that matters is not the 10-core CPU. It is the media engine: fixed-function silicon that transcodes video while the CPU stays mostly idle, with no equivalent session limit.

The yardstick Plex gives us

Plex’s own support guidance is a PassMark score per full transcode: 2,000 for a 1080p H.264 source, 12,000 for 4K SDR HEVC, and 17,000 for 4K HDR HEVC down to 10 Mbps 1080p. That scale describes the software path — what happens when CPU cores do the encoding. It is the right ruler for the top row of the chart and the wrong one for the other two.

The comparison

Three states, two resolutions:

  • Where we are now (software only, accelerator dead): about 4-5 simultaneous 1080p transcodes, and effectively 0-1 of 4K HDR.
  • Fix the Quadro P1000, no new hardware: about 6-8 simultaneous 1080p — up roughly 56% — and 2-4 of 4K HDR, which is the difference between four times nothing and something.
  • Move to an M4 Mac mini, 24 GB: roughly 20 simultaneous 1080p, about 2.9× the repaired VM, and 6-10 of 4K HDR.

What each step actually costs

This is the part the bars do not show:

  • Repairing the GPU costs no new hardware. It buys the largest single jump available for free, and it is the only step that changes 4K HDR from impossible to possible. The cost is operational: driver and passthrough work on a live server.
  • The Mac mini is a purchase, plus a migration. I measured the move: the Plex data directory on that box is 31.5 GiB, of which about 25.8 GiB is real payload once caches, logs and old database backups are excluded. The watch state itself is small — the live databases total 964 MB — but 72% of the payload is artwork, which is what makes the rescan slow. And the machine only helps if the media storage comes with it.

Both steps are worth doing; they are not alternatives. The repair raises the floor on hardware already paid for. The Mac raises the ceiling, and the ceiling is roughly three times higher per step above that.

How to read those numbers

Only one figure here is a direct measurement: a published community test ran six simultaneous 4K HDR to 1080p transcodes on a base M4 at around 40% CPU. The Mac mini’s 1080p figure is extrapolated from it using the roughly four-to-one pixel cost between 2160p and 1080p, which is why the chart hatches it.

The other two rows are models, not measurements. The software row comes from PassMark against the CPU share a single 8-vCPU guest can realistically claim on a 16-thread host. The repaired-GPU row starts from the P1000’s published engine counts and applies the eight-session cap. For 4K the same engine decodes 10-bit HEVC, tone-maps and re-encodes at roughly three to four times the cost of a 1080p session, which is where two to four comes from.

One documented caveat sits behind the Mac’s 4K row. Plex’s HDR-to-SDR tone mapping matrix lists hardware tone mapping for Windows (Intel and NVIDIA), Linux, Docker and NAS. macOS is listed as software only — there is no hardware tone-mapping entry for it at all. If that still holds for Apple Silicon, the M4 is doing tone mapping on its CPU while the media engine handles decode and encode. The observation behind the figure is real, but the thing scaling that row is the CPU, not the media engine, which makes the Mac’s 4K number the least certain one on the chart.

Why the Mac still wins by roughly three times per step

  1. The session cap, not the silicon, is the binding constraint on the VM. NVIDIA limits concurrent NVENC sessions on consumer and low-end Quadro cards; the P1000 carries an eight-session ceiling. Apple’s media engine has no equivalent licence-style limit, so its ceiling is throughput. A GPU with the cap removed would move this comparison more than a faster one would.
  2. Seven years of encoder generations. The P1000’s encoder is Pascal, from 2017. The M4’s media engine is from 2024 and decodes AV1 in hardware, which the Pascal part predates entirely.
  3. The VM is still using its CPU for everything else. Decode, scaling, audio and container work still cost CPU per session, on 8 vCPUs shared with other guests on the same host.

What limits the VM at every step

  • The eight-session cap is per GPU and shared by every app. Plex, Stash and any future Tunarr instance on that box would all draw their sessions from the same eight. Repairing the accelerator is not a free upgrade; it is a budget to divide.
  • 8 GB of RAM. The box runs Plex alongside Tautulli, SABnzbd and Stash, with about 3.5 GB free at the time of inspection.
  • Baseline load. I measured 33% CPU utilisation with zero transcodes running.
  • Shared silicon. The VM holds 8 of the host’s 16 threads, and other guest machines compete for the same physical cores.
  • A 9 Mbps upload ceiling. This caps remote playback at roughly one 8 Mbps stream no matter how much compute is left over. LAN clients are unaffected.
  • Plex is not running as a service. The media server is a manually started process while its NSSM service shows Stopped, so a reboot would leave the server down.

How these numbers were produced

The current-state figures come from a read-only inspection: WinRM queries against the guest for processor, memory, GPU device state and disk; nvidia-smi for driver reachability; the Plex instance’s own preferences file for its transcoder settings; and its logs for transcode activity. Nothing was changed on the host. The P1000’s engine counts and session limit come from a published Plex hardware-transcoding reference, the PassMark figures from PassMark, the data-directory measurement from the disk, and the Mac mini figures from Apple’s published specifications plus the community measurement cited below.

Caveats worth stating plainly

  • Two of the three rows are models, not measurements. I have shown the working so you can disagree with it.
  • Plex does not document hardware transcoding as working inside a virtual machine. Its own support article states that hardware-accelerated streaming is not currently possible in VMs, because hypervisors do not expose video encode/decode hardware to guests. PCIe passthrough — what the P1000 uses — is the exception that works in practice, but it sits outside the documented support. The middle row is a plan, not a promise.
  • Windows has more hardware paths than macOS, even though the Mac is faster along the one it has. Plex lists three encoders for Windows (Intel Quick Sync, NVIDIA NVENC, Media Foundation) and two decoders; for macOS it lists VideoToolbox and nothing else. A single very good engine beats three merely available ones — but it also means no fallback if VideoToolbox cannot handle a given file.
  • Transcoding only happens when a client cannot direct-play. A well-matched library and clients need none of this capacity.
  • Plex on macOS reaches the media engine only as the native app; a Linux container on a Mac cannot touch it and silently falls back to CPU.
  • Hardware transcoding in Plex requires a Plex Pass.
  • The VM shares a host with other machines, so its real-world ceiling moves with whatever else is running.

Sources

Measured on 10.7.7.41 on 2026-10-02; forward steps modelled. Estimates are labelled as estimates, the ranges are mine, and I have shown where they came from so you can disagree with them.

Similar Posts