Media / IPTV
Direct play vs transcoding
Why media servers need different sizing when streams are passed through directly versus re-encoded for each viewer.
Direct play is mostly a delivery problem
Direct play sends the existing media file to the viewer without changing codec, resolution, or bitrate. The server still needs enough disk throughput and network capacity, but CPU demand is usually modest.
This is why a media library can need a large port even when CPU load looks low.
Transcoding is a compute problem
Transcoding re-encodes video into a different format or bitrate. That moves the bottleneck toward CPU or GPU, and a bigger network port will not fix a saturated transcode queue.
If many viewers need transcoding at once, size the server from expected active jobs before choosing the final bandwidth tier.
Use separate roles when growth becomes serious
Large platforms often split storage, transcode, and delivery roles. This makes failures easier to contain and helps each node use the right hardware.
Bandwidth Pool can help when those roles sit across multiple servers with uneven demand.
Test one file in three playback modes
Play a representative file on a device your viewers use. Note the selected audio and subtitle tracks, playback mode, CPU or GPU utilization and outbound bitrate. Repeat with subtitles enabled and then with a lower remote quality limit.
Direct Play leaves the file intact. Direct Stream can repackage compatible streams without re-encoding video; audio can still need conversion. Burning unsupported subtitles into the picture requires video processing. See the Plex playback documentation for the distinctions.
Send these results with your media server request. Disk reads and egress matter for all three tests; only the conversion tests tell you much about encoder capacity.
Related next steps
