Hardware and transcoding

Most “what hardware do I need” answers start with the wrong question. The honest one is: how often will this server actually re-encode anything? A server that never re-encodes is doing little more than reading files off a disk and putting them on the network, and a very modest machine does that for several people at once. A server that re-encodes 4K HDR for every viewer is doing real work and wants real hardware.

So this page starts with what decides that, then gives numbers.

The three ways a file reaches you

Every time you press play, the server picks the cheapest option that will actually work on your device. You never choose this, and it is chosen per stream, so two people watching at once can be on different rungs.

Direct play. The file is sent as-is. Your device does all the decoding. The server does almost nothing: no decode, no encode, just reading and sending. Cost is close to zero no matter whether the file is 1080p or 4K.

Direct stream (remux). The video is copied through untouched but the container or the audio is rebuilt around it, because your device could play the picture but not the wrapper or the soundtrack. There is still no video re-encode, so this is cheap. A little CPU, no GPU needed.

Transcode. The video is decoded and re-encoded, because the device cannot play the codec, or the resolution has to come down, or HDR has to be tone-mapped, or subtitles must be burned in. This is the expensive one and it is the only one your hardware choice really changes.

The practical consequence: if your library and your devices match well, you can run a big 4K library on a small machine. Modern Apple TV, recent Android TV boxes, and current browsers direct-play a lot. Transcoding is what happens at the edges: an old device, a weak connection, a subtitle format that has to be painted onto the picture.

What actually costs the most

Not the part people expect. On a 4K transcode the decode of the source is usually more expensive than the encode. We measured two 4K HEVC streams on a machine with a current Nvidia card pinning the CPU at 99% while the GPU’s video encoder sat at 3%: all the work was software decoding, none of it was encoding.

That is why the server offloads decoding to the GPU as well as encoding, and why a machine with any capable GPU beats a machine with a fast CPU and no GPU for this job. On the same 4K source, moving decode onto the GPU cut CPU use by about 80% for a full-resolution stream and about 50% for one that also had to be scaled down.

Our stance on hardware encode and decode

We test your hardware instead of trusting its spec sheet. On startup the server runs real encodes and real decodes against your actual chip and driver, half a second each, and records what genuinely worked. It does not read the list of codecs ffmpeg advertises, because a GPU routinely lists codecs its driver stack cannot actually run, and it does not use ffmpeg’s automatic hardware detection, because that silently falls back to software and would report success while doing the work on the CPU.

Three things follow from that, and they are deliberate:

• The results are per machine, not per model number. Two identical GPUs with different drivers can come out differently, and the one in front of you is the one that counts. You can see exactly what was detected in Settings → Advanced, per codec, for both encode and decode.
• It fails safe. Anything the probe cannot prove is treated as unsupported. The worst case is that the server does something on the CPU that your GPU could have done, which is slower. It never means a broken stream.
• A chip has to prove itself twice. A backend has to pass a plain H.264 encode before we consider it working at all, and then it is tested separately for each codec. Support for one codec is never assumed from support for another.

We never encode HEVC in software. If HEVC comes out of this server, it came from your GPU’s video encoder. That is a licensing decision as much as a performance one, and it has a practical consequence worth knowing: keeping HDR as HDR through a transcode needs a GPU that can encode 10-bit HEVC. On a machine without one, an HDR file that has to be transcoded comes out as tone-mapped SDR instead, which looks fine and is not an error.

Output is H.264 or HEVC. AV1 and VP9 play and decode, but the server does not encode to them yet. It will when consumer GPU support is boring rather than exciting.

Which chip does what

Backends the server will look for, by platform:

Platform	Looks for, in order
Windows	Nvidia NVENC, Intel Quick Sync, AMD AMF, then software
Linux	Nvidia NVENC, Intel Quick Sync, VAAPI (Intel or AMD), then software
macOS	Apple VideoToolbox, then software

The software fallback encodes H.264 only, and it is always available, so there is no such thing as a machine this will not run on. It is just slower.

The table below is a guide to what a generation can usually do. Treat it as a shopping guide, not a promise, because the answer for your machine is whatever the probe found in Settings → Advanced. Encode support is what matters for transcoding; decode support is what makes transcoding cheap.

Vendor	H.264	HEVC 8-bit	HEVC 10-bit (keeps HDR)	AV1 decode
Nvidia	Kepler (GTX 600) and later	Maxwell 2nd gen (GTX 960) and later	Pascal (GTX 10) and later	Ampere (RTX 30) and later
Intel	Sandy Bridge (2nd gen) and later	Skylake (6th gen) and later	Kaby Lake (7th gen) and later	Xe / Arc / 12th gen and later
AMD	GCN and later	Polaris (RX 400) and later	Vega / RDNA and later	RDNA 2 (RX 6000) and later
Apple	Any Mac with Quick Sync or Apple silicon	Skylake Macs, T2 Macs, all Apple silicon	Apple silicon, T2 Macs	M3 and later

Two notes that catch people out. Intel’s Quick Sync is disabled on many desktop builds when a separate graphics card is installed, or when the motherboard has no display output enabled; you may need to turn the integrated GPU back on in the BIOS. And on Linux, Nvidia and Quick Sync need their driver packages present, or the probe correctly reports nothing and the server falls back to software.

Minimum and recommended, by library

These assume a normal household: a few devices, one or two things playing at once. They are deliberately conservative, because the failure mode of an underpowered server is stuttering playback, which is miserable.

A mostly 1080p library

	Minimum	Comfortable
CPU	Any 4-core from the last decade	Modern 4-core or better
RAM	4 GB	8 GB
GPU	None needed if most things direct-play	Any Quick Sync, Nvidia, AMD, or Apple silicon GPU
Disk	Your library, plus about 10 GB	Same, on an SSD for the database
Concurrent transcodes	1 to 2 on CPU alone	5 or more with any modern GPU

A 1080p library is forgiving. Software H.264 encoding at 1080p is within reach of an ordinary CPU for one or two streams, so a small box, an old laptop, or a NAS with a real processor is genuinely fine.

A 4K or HDR library

	Minimum	Comfortable
CPU	Modern 6-core	Modern 8-core
RAM	8 GB	16 GB
GPU	Strongly recommended: any GPU with HEVC decode	A GPU with 10-bit HEVC encode, so HDR survives a transcode
Disk	Your library, plus about 20 GB	Same, on an SSD for the database
Concurrent transcodes	1 on CPU alone, and it will struggle	3 to 5 with a modern GPU

Be honest with yourself about the GPU line. 4K software transcoding is not really viable: a single 4K HDR stream can saturate a strong desktop CPU, and the decode side alone will do it. If your 4K library will only ever be watched on devices that direct-play it, a modest machine is fine. If it will be watched away from home, on older TVs, or with burned-in subtitles, get a GPU.

Per platform

The requirements above are the same on all three platforms; these are the platform-specific parts.

	Windows	macOS	Linux
Version	Windows 10 or later, 64-bit	macOS 13 Ventura or later	Any current 64-bit distribution
Architecture	x86-64	Apple silicon or Intel	x86-64 or ARM64
Installs as	Per-user, no administrator prompt	One installer for both chips, menu bar app	deb, rpm, or tarball, as a systemd service
Hardware video	Nvidia, Intel Quick Sync, or AMD	VideoToolbox, built in and always present	Nvidia or Quick Sync with drivers, or VAAPI
Worth knowing	Nothing extra to install; ffmpeg is bundled	Any Apple silicon Mac is a strong server for its size and power draw	Driver packages are the usual reason a GPU is not detected

A note on Apple silicon, because it surprises people: even a base M-series Mac mini is a genuinely capable server here. VideoToolbox handles HEVC in both directions including 10-bit, it draws very little power for a machine that is on all the time, and it needs no driver setup at all.

Network

Two different questions, and people usually only think about the first.

At home

What matters is the bitrate of the file, not its resolution, and the two are only loosely related. A heavily compressed 4K stream can be lighter than a Blu-ray rip of a 1080p film.

What is playing	Typical per stream
Transcoded to 720p	About 4 Mbps
Transcoded to 1080p	About 8 Mbps
Transcoded to 4K	About 16 Mbps
Direct play, streaming-style 1080p	5 to 15 Mbps
Direct play, 1080p Blu-ray rip	20 to 40 Mbps
Direct play, 4K HDR Blu-ray rip	50 to 100 Mbps

So:

• Wire the server if you can. It is the single most effective thing you can do, and it matters more than the router.
• 1080p over Wi-Fi is comfortable on any decent modern Wi-Fi, wired or not.
• 4K direct play really wants a wire, or Wi-Fi 6 with a good signal. A 100 Mbps 4K remux does not fit reliably down a weak Wi-Fi link, and this is the most common cause of 4K stuttering that gets blamed on the server.
• Gigabit Ethernet comfortably carries several 4K streams at once. It is rarely the bottleneck.

Away from home

Here the limit is almost always your home internet’s upload speed, which for most connections is far smaller than the download speed you pay attention to. One remote viewer at 8 Mbps needs 8 Mbps of upload that is not being used for anything else.

Upload speed	Realistically supports
5 Mbps	One 720p stream
10 Mbps	One 1080p stream
25 Mbps	Two or three 1080p streams
50 Mbps or more	Several streams, or one 4K direct play

Because of this, remote viewing usually transcodes down even when the device could play the original, and the server applies its own remote quality ceiling by default so a viewer away from home does not accidentally try to pull a 100 Mbps remux through a 10 Mbps upload. You can adjust that in Settings.

Two more things about remote:

• Direct connections are attempted first, and the relay is the fallback when your network will not allow one. Direct is faster and does not count against anything.
• Watching on your own network never counts as remote, however you got there.

Where to check your own machine

Everything above is a guide. Your server already knows the real answer:

• Settings → Advanced shows the detected hardware backends and the full per-codec encode and decode matrix for this exact machine.
• The Activity section of the server settings shows what is playing right now, which rung each stream is on, and what each one is costing in CPU, memory, disk, and GPU.

If something is transcoding that you expected to direct-play, Activity will tell you which of the reasons above caused it.