You have a 4K HEVC file that direct plays perfectly on your NVIDIA Shield. Then someone enables English subtitles. Suddenly the Plex dashboard shows a full video transcode — CPU spiking, quality dropping, buffering starting. The video itself hasn’t changed. The subtitles are just text. Why is your server re-encoding the entire video stream just to show words at the bottom of the screen?
The Three Subtitle Formats and Why They Matter
Not all subtitles are created equal, and the format determines whether your server transcodes or not. There are three categories:
Text-based subtitles (SRT, WebVTT, SSA/ASS). These are plain text files with timestamps. SRT is the simplest — just timing and dialogue, no formatting. WebVTT is the web equivalent. SSA and ASS add styling: fonts, colors, positioning, effects, karaoke timing. The critical thing about text subtitles is that they’re separate from the video stream. They can be rendered by the client player independently, overlaid on top of the video without touching the video data at all.
Image-based subtitles (PGS, VOBSUB, SUP). These are bitmaps — actual images of pre-rendered text. PGS (Presentation Graphic Stream) is the format used on Blu-ray discs and is by far the most common image-based format in media libraries. VOBSUB comes from DVDs. Each subtitle “event” is a PNG-like image with alpha transparency. The text has already been rendered into pixels, including any styling, positioning, and effects.
Forced/foreign subtitles. These aren’t a format but a flag. Any subtitle track can be marked as “forced,” indicating it contains only translations of foreign-language dialogue (like when characters speak Elvish in Lord of the Rings). Forced tracks are usually small, but their format still matters for transcoding.
Why Image-Based Subtitles Force a Transcode
Here’s the core problem: most Plex client apps cannot overlay image-based subtitles on their own. When a PGS subtitle track is selected, Plex has to burn them in — composite the subtitle images onto the video frames and re-encode the entire video stream. This is a full video transcode, even though the video codec, resolution, and bitrate don’t need to change.
The burn-in process works like this:
- Plex decodes the video stream (CPU or GPU)
- For each frame, Plex checks if a PGS subtitle image exists at that timestamp
- If yes, it alpha-composites the subtitle bitmap onto the decoded frame
- The composited frame is re-encoded via H.264 or HEVC
Even if the original video is 4K HEVC that would normally direct play, enabling PGS subtitles forces a full decode → composite → re-encode cycle. On a CPU, this can easily consume 100% of a modern processor for a single stream. With GPU hardware transcoding, it’s faster but still uses significant resources that weren’t needed before.
When Text Subtitles Also Cause Transcoding
You might think SRT subtitles are always safe. They usually are — but not always. There are two cases where even text subtitles trigger a transcode:
1. ASS/SSA with complex styling. Advanced SubStation Alpha subtitles can include custom fonts, colored text, positioned dialogue (like signs in anime), drawing commands, and animated effects. Most Plex clients can’t render these natively, so Plex burns them into the video. If you watch a lot of anime with fansubs, this is probably why your server transcodes even with “text” subtitles — those fansubs are almost always ASS format with heavy styling.
2. Client app doesn’t support text subtitle overlay. Some older or less capable Plex clients (certain smart TV apps, older Roku models, and the web player in some configurations) don’t support client-side subtitle rendering for all text formats. When the client reports it can’t handle the subtitle format, Plex falls back to burn-in.
The Plex Subtitle Settings That Matter
Plex has a subtitle burn-in setting that many users never touch, and it’s the single most impactful setting for avoiding unnecessary transcodes. You’ll find it under Settings → Languages in the Plex web UI:
- “Automatic” (default) — Plex decides based on the client’s reported capabilities and the subtitle format. This is usually the safest option, but it’s conservative — Plex will burn in whenever it’s unsure.
- “Only image formats” — only burns in PGS/VOBSUB/SUP. Text subtitles are always sent as-is for client-side rendering. This is the best option for most users, as it avoids transcoding for the majority of subtitle scenarios.
- “Always” — burns in every subtitle, even plain SRT. This guarantees consistent rendering across all clients but means every subtitle selection triggers a transcode. Avoid this unless you have a powerful GPU and don’t mind the overhead.
- “Never” — never burns in subtitles. If the client can’t render them, subtitles simply don’t show. This completely avoids subtitle-triggered transcoding but can leave users without subtitles on less capable devices.
How to Fix Your Library for Maximum Direct Play
The real solution isn’t fighting Plex’s transcoder — it’s fixing the subtitle tracks in your files. Here’s a practical strategy:
Convert PGS to SRT. Tools like Tesseract OCR with SubtitleEdit or Bazarr can OCR image-based subtitles into SRT text. The accuracy is generally excellent for Latin scripts (98%+) and good for CJK characters (90%+). Run this as a batch job across your library and you eliminate the biggest source of subtitle-triggered transcoding.
Use Bazarr for automatic SRT downloads. Bazarr integrates with Sonarr and Radarr to automatically download SRT subtitles from OpenSubtitles, Subscene, and other providers. If your media files have PGS subtitles embedded, Bazarr can find and download matching SRT files, which Plex will prefer for client-side rendering.
Strip ASS styling to SRT. If you have anime with ASS fansubs, you can convert them to SRT (losing the styling but gaining direct play) using ffmpeg:
ffmpeg -i input.mkv -map 0:s:0 -c:s srt output.srtYou lose sign translations, karaoke effects, and positioned text, but you gain direct play for every client.
The Performance Cost: Numbers
To quantify how much subtitles actually cost in transcoding overhead:
| Scenario | Transcode? | CPU Impact |
|---|---|---|
| 4K HEVC, no subs | Direct Play | ~1% |
| 4K HEVC + SRT subs | Direct Play | ~1% |
| 4K HEVC + PGS subs | Full transcode | 85–100% |
| 4K HEVC + ASS subs (styled) | Full transcode | 85–100% |
The difference between “1% CPU” and “100% CPU” is the difference between serving 12 users and serving 1. And it’s all determined by the subtitle format, not the video itself.
How PlexBeam Handles Subtitle Burn-In
When subtitle burn-in is unavoidable — PGS on a Blu-ray remux that has no SRT alternative, or ASS fansubs where the styling is actually important — PlexBeam offloads the entire burn-in pipeline to a remote GPU worker. The GPU composites the subtitle images onto decoded video frames and re-encodes using NVENC, completing the transcode at 8–11× realtime. Your local server stays idle while the burn-in happens on dedicated hardware.
For libraries heavy on anime or Blu-ray remuxes with PGS tracks, this turns what would be an unwatchable experience on a NAS into seamless playback for every user.