So you’ve decided self-host your media collection and free ourselves from the shackles of streaming services. you have selected a NASHe filled it with recovered hard drives and armed himself with phrases like “digital sovereignty” because they sound pretty good.
The media server is set up, files are added, as are subtitles and all the metadata, and you think you’re ready to kick back and relax. And then you start streaming your new media, and it’s not seamless. There is buffering or crashing, and you may hear your NAS speed up.
It’s a common scene. This happened to me on my first two NAS enclosures and I blamed it on my hard drives being slow (they weren’t) and my network being saturated (it wasn’t). Anything but the real culprit. Transcoding and the extra strain it puts on my humble NAS CPU.
A short introduction to what transcoding is and does
Two operations, twice the pain for your NAS
Transcoding is activated when your client device (streaming box, smartphone, smart TV, etc.) cannot play the video file you have selected. While it can happen due to discrepancies in video codecs, this is rarer these days, and if I see transcoding occurring, it’s often because Atmos or 7.1 audio is being downmixed to an audio stream that my TV can support.
But whatever the reason, it puts a huge load on the CPU of the low-power NAS. This is because transcoding actually consists of two processes:
- Decode: Your NAS decompresses the entire video file into raw pixel data
- Recode: It then compresses them from raw data to the target format, bit rate, resolution and audio codec for the client’s needs.
Many NAS enclosures only support CPU transcoding, although some Intel-based ones support iGPU and Quick Sync is perfect for this task. I’ve had AMD integrated NAS boxes without hardware support, and some from Intel as well. I haven’t used a Qualcomm NAS in a minute, so look for support if that’s the path you want to go.
It’s the same process no matter what media server you use
Transcoding is one of the universal constants in the world of media streaming, because it does not depend on the server, only the client. The device playing the media is in charge of the codecs it supports, and if it doesn’t support the one the video or audio is encoded in, you get transcoding.
Why does your NAS crash?
That low-power CPU is not designed for this pain
The CPUs used in most NAS enclosures are tuned for low-power operation, not heavy lifting. The double calculation of transcoding is a heavy process and one of the most demanding tasks a chip can perform. If you have a NAS with an iGPU or a dedicated GPU then transcoding is handled there and is a more trivial calculation for graphics processing, but not all NAS have this.
And really, it’s not even just about the calculations, there are four competing potential bottlenecks:
- CPU Saturation: Slows down everything that happens on the NAS, including the operating system
- Thermal throttling: NAS enclosures are not known for good airflow and 100% CPU loading generates a lot of heat even on low-power chips.
- Disk I/O Contention: Transcoding involves continuously reading from the drives on which the source file is located and writing to the temporary cache.
- RAM pressure: The uncompressed frame buffer resides in RAM and is easily gobbled up by 4K video, which takes up about 24 MB per frame.
And it depends on the codecs involved. HEVC (H.265) might be the most common to save file space, but it has a high computational cost to decode and can almost saturate low-power CPUs on its own. Add fallback, re-encode to H.264 and your CPU will struggle to keep up, leading to dropped frames and buffering while you try to watch.
It’s (usually) not your network’s fault
It’s easy to blame the network, after all, is transmission media. But that is rarely the case. When Plex or Jellyfin are transcoding, the high CPU usage looks exactly like a cloud streaming service when it comes to an internet issue, which may make you think the two are comparable.
But it’s not, you’re streaming from one computer on your home network to another over the same network. Below are some rough numbers for each codec and the common resolutions that media libraries are made up of. Most of these shouldn’t be problems for home Wi-Fi, let alone Ethernet:
|
Content |
Codec |
Typical bit rate |
|---|---|---|
|
1080p SDR |
H.264 |
8-20Mbps |
|
1080p SDR |
HEVC |
4-12Mbps |
|
4K SDR (24-30fps) |
HEVC |
35–45Mbps |
|
4K HDR (44 to 56 fps) |
HEVC |
53–68Mbps |
|
4K Blu-ray Remix |
HEVC |
50-120Mbps |
The only place you might have problems is Blu-ray remuxes once you go above 80Mbps, because multiple streams can saturate a gigabit link, but if you’re only streaming to one client, that won’t happen. Wi-Fi congestion can also cause similar problems, and using a web browser as a client will cause problems as it almost always drops to H.264.
What can you do about it?
There are a few ways to avoid the problem, but most will force you to reach for your wallet. You could configure Direct play either direct transmission if your client device supports them; the first plays the file as is, without transcoding it in the first instance, and the second uses only container remuxing (such as MKV-to-MP4). That consumes less CPU and could be the difference you needed.
The other options are to update your client device; My favorite is the Apple TV 4K, but any modern streaming box should work. Or you could add a GPU to your NAS if it’s a DIY build or if the company that made it supports it. That will offload the transcoding to the GPU and everything will be fine. Note that Plex requires Plex Pass for hardware transcoding, while Jellyfin and other options do not.
Transcoding is what makes your NAS feel slow when streaming, not your network
If your media server seems slow, check to see if it has been transcoding your files. Especially if you’ve been using a smart TV app, the client app may not be able to play some of the codecs you have your files in, and that will spell trouble. The easiest way is to make sure the client device can play those files, so you’re looking for a new streaming box. You could do it on the NAS side and add hardware transcoding if possible, but you’re still artificially limiting the bitrate and it’s better to deal with it on the display side.
