What is transcoding?
Understanding what happens inside your server when you press play - without blame, jargon, or shortcuts.
You can read this if
You can read this if you've noticed your media server straining, your fans spinning up, or buffering appearing partway through a film you've watched fine before. If your setup has been doing this, it's important to know: this is not a fault in your hardware, your network, or your choices. It reflects how media servers respond when any link in the chain between file and screen can't handle what's being asked of it.
Your setup is not broken. It's adapting to a mismatch.
Your server already uses several powerful systems
When you press play, a media server (Plex, Emby, Jellyfin) coordinates several systems at once. Some of the key ones involved include:
- The file reader - pulls bytes from disk or network storage and feeds them forward
- The container parser - unpacks the MKV, MP4, or other wrapper around the actual streams
- The video decoder - turns compressed video (H.264, HEVC, AV1) back into frames
- The audio decoder - turns compressed audio (AAC, AC3, TrueHD) back into sound waves
- The video encoder - compresses frames into a different format if needed
- The network delivery layer - chunks everything up and sends it to the client
- The client's own decoder - on your TV, phone, or Fire Stick
Every device has these systems. They are normal, necessary, and active every time something plays.
What the three playback modes actually do
Media servers don't introduce anything new - they just decide how much of the work each system has to do. The name of the mode tells you which systems are being bypassed.
Direct Play
Direct Play
Your server reads the file from disk and sends it over the network untouched. Your client does all the decoding. The server's CPU barely moves - it's just streaming bytes. Quality is perfect because nothing has been re-encoded. This is always the cleanest path.
Direct Stream
Direct Stream
The container is wrong for your client, but the contents are fine. The server unpacks the original wrapper (e.g. MKV) and wraps the same video and audio streams in a new one (e.g. MP4). Nothing is re-encoded. CPU load is minimal. Quality is identical to Direct Play.
Transcode
Transcode
The actual video or audio is being re-encoded in real time because your client cannot decode the original. The server's CPU (or GPU, if hardware acceleration is available) is doing heavy work. Quality drops. Heat rises. This is where problems surface.
What transcoding does to your hardware
Transcoding is not a small task. A single 4K HEVC transcode can consume multiple CPU cores at near full load. A 1080p transcode is more modest but still significant. When multiple users stream simultaneously, the load stacks.
With sustained transcoding, your server adapts in several ways:
- CPU temperatures rise. Fans spin faster. Over time, dust accumulates more on hot components.
- If the CPU can't keep up, frames are dropped or delivery stalls - buffering appears.
- SSDs used for transcode output absorb significant write wear. Over a busy server's life this can equal petabytes of writes.
- Memory pressure increases. Other services on the same machine compete for resources.
This is not damage. It is the system working as designed - but working much harder than it needs to if the right path were available.
Why transcoding happens (the real triggers)
Transcoding is never random. It is always the server's response to something specific being incompatible. Understanding these triggers is the key to fixing most playback problems.
Video codec incompatibility
Your client simply cannot decode the codec in the file. This is most common with HEVC/H.265 (used widely for 4K) on older devices, web browsers, and some smart TVs. The server must re-encode to H.264, which is universal but heavier.
Bitrate ceiling hit
Your client is configured to request a lower bitrate than the file offers. The server must encode a new, lower-bitrate stream on the fly. This is almost always a client-side setting: "Original" or "Maximum" quality prevents it. "Adjust Quality Automatically" silently causes it - worth turning off.
Subtitle burn-in
Image-based subtitles (PGS from Blu-ray, VOBSUB from DVD) can't be overlaid by most devices. To show them, the server must paint them into the video and re-encode the whole stream. Text subtitles (SRT) usually pass through without this.
Audio format mismatch
TrueHD and Atmos audio can only pass over HDMI or eARC to a compatible receiver. Optical connections and regular ARC can't carry them. When the audio can't reach the receiver in its native form, the server transcodes it - usually fine, as audio transcoding is light.
HDR to SDR tone mapping
If the file is HDR but the display is SDR, the server converts HDR brightness data to SDR. This is one of the heaviest transcodes - especially without hardware acceleration.
None of these mean you chose the wrong file or set things up wrong. They are predictable consequences of what happens when one component in a chain can't accept what another component is producing. Your job is only to notice which link is mismatched.
Why removing transcoding can feel harder before it feels easier
Many people try to fix transcoding by changing one thing - setting quality to Maximum, for instance - and are surprised when buffering replaces the transcode. This is not a failure of the fix. It reflects what's actually happening in the system.
Transcoding was hiding a separate problem: your network couldn't carry the full bitrate. When you removed transcoding, that limitation was exposed. The solution is not to re-enable transcoding (which trades one problem for another), but to address the network - usually by moving from Wi-Fi to Ethernet, or by placing the streaming device closer to the router.
During this period:
- A newly-exposed network limit causes short buffering that feels like regression
- Subtitle or audio issues that transcoding had been silently papering over may now appear
- Hardware transcoding, if enabled, may reveal bugs the CPU transcoder had masked
This is the system re-calibrating to its new mode of operation. It stabilises once each limitation is addressed.
How to see what your server is actually doing
All three servers expose the truth clearly if you know where to look.
Plex
Settings > Status > Dashboard shows every active stream with its mode and the reason. For deeper detail, open the Settings Console and filter for "MDE" - these log lines show exactly which decision the server made and why.
Emby
The server Dashboard > Active Sessions panel shows playback mode and the active transcoder (VAAPI, QSV, NVENC, or CPU). Server logs and FFmpeg logs capture the full command line.
Jellyfin
Dashboard > Active Sessions shows the mode for each stream. FFmpeg logs in the server log directory reveal the exact encode parameters if you need them.
Why hardware transcoding is offered
When transcoding is unavoidable, hardware acceleration offloads the work from the CPU to dedicated video hardware - Intel Quick Sync on integrated graphics, NVENC on NVIDIA GPUs, or VAAPI on AMD and Intel under Linux.
This is not a workaround or a cheat. Modern CPUs have dedicated silicon for video encoding that is dozens of times more efficient than running the same work on general-purpose cores. It exists because video encoding is a common, well-defined task - the hardware manufacturers built special circuits for it.
Using hardware acceleration is not about getting away with something. It is about using the chip the way it was designed to be used.
Important
Plex and Emby require a paid tier (Plex Pass / Emby Premiere) to enable hardware transcoding. Jellyfin includes it for free. None of these choices are wrong - they reflect different positions on how the project is funded.
What this experience does not mean
- It does not mean your server is underpowered - unless it has been transcoding for years, it is likely fine once the right fixes are applied
- It does not mean you need to re-encode your entire library - though matching files to your most-used clients can reduce future transcoding
- It does not mean you made the wrong purchase - the client device can almost always be configured to avoid transcoding, or replaced for less than a server upgrade
- It does not mean you're a bad administrator - the default settings on many clients actively encourage transcoding
A note on context
Many people run media servers to:
- Watch content they already own without being tied to a streaming service
- Share with family on multiple devices, each with different capabilities
- Preserve a library that would otherwise disappear when services change their catalogue
- Enjoy the craft of setting up something well
Transcoding issues are a predictable consequence of this - different devices at different ages, running different apps, on different networks, all asking the same server for the same file. The server adapts to make it work. Your job is only to make it adapt less often.
A final reassurance
If your server has been transcoding more than you expected, you haven't failed. The system was doing its best to deliver playable content across a chain it couldn't fully control. With a few settings changes - quality to Maximum, subtitles adjusted, perhaps Ethernet in place of Wi-Fi - the chain becomes compatible end-to-end, and transcoding stops happening. Nothing needs to be replaced. It just needs to be matched.
Support tips
If you need to ask for help, these details make it much easier for others to understand your situation:
- Which server you run (Plex / Emby / Jellyfin) and its version
- Which client was playing when transcoding started (app, device, version)
- The file's video codec (e.g. HEVC), audio format (e.g. TrueHD), and whether it has subtitles
- The transcode reason shown in your server dashboard (this is the single most useful piece of info)
- Whether quality is set to Maximum / Original on the client
- Network type (Ethernet / Wi-Fi 2.4 GHz / Wi-Fi 5 GHz / Wi-Fi 6)
- What you've already tried
Clear explanations, patience, and collaboration matter.
Did this guide help?
Be the first to vote.
Related guides