Direct Play, remux and transcoding are different answers to one question.
A media server must decide how much of a source file the selected client can consume safely. The best plan is normally the least expensive path that preserves correct video, audio, subtitles and seeking—not simply the path with the fewest FFmpeg processes.

- Server
- Public pre-release evaluation through Docker Compose
- Web client
- Available with the server
- Fire TV & Android
- Supervised device testing
- Paid launch
- Pricing and final terms pending
From source facts to a dependable system.
Each guide connects the visible outcome to the playback, infrastructure and recovery decisions underneath it.
Direct Play sends the original media streams
Direct Play keeps the source container, video, audio and ordinarily the selected subtitle delivery unchanged. It minimises server work and preserves source quality, but it is valid only when the client accepts the complete combination—not merely the headline video codec.
An H.264 file can still require processing when its profile, level, bit depth, chroma format, audio codec, channel layout, container or subtitle format exceeds the client’s real capability.
Remux changes the container, not compatible essence
A remux repackages compatible video and audio into a container the client can consume. For example, video may remain byte-for-byte H.264 while FFmpeg produces fragmented MP4 segments for an HLS client. This is much cheaper than decoding and re-encoding video, but still requires correct timestamps, keyframes and range or segment delivery.
Audio conversion should preserve compatible video
If a television supports HEVC video but not DTS audio, converting only audio usually provides the lowest-cost valid result. Channel count, sample rate, passthrough support and the selected audio track all affect this decision. A server that always converts the video in this case wastes capacity and reduces quality.
Video transcoding is sometimes necessary
Full conversion is appropriate when the video codec, profile, level, resolution, bitrate, frame rate, bit depth or HDR format cannot be delivered safely. Image-based subtitles may also require burn-in, and HDR-to-SDR tone mapping adds decoding, colour conversion and encoding work. Hardware acceleration can reduce CPU load, but must be verified during a real session.
Diagnose the decision with facts
Record the probed source streams, chosen tracks, reported and observed client capability, requested quality, delivery method, server backend and reason codes. Then measure time to first frame, seek delay, buffering and decoded frames. Codec labels alone are not enough to prove that Direct Play will work.
- Container and video, audio and subtitle stream details
- Client model, application version and decoder history
- Network bitrate, byte-range handling and buffer level
- The exact reason that changed the playback path
The selected playback path should remain visible.
A plan is more useful when source facts, client capability, reason codes and the observed backend can be inspected together.

Practical self-hosting guides
Move from the playback decision to the hardware, public route and recovery boundary behind it.
Understand what each path changes and why files that look compatible may still need conversion.
You are here HardwareChoose media-server hardwareSize CPU, GPU, memory, storage and networking around real simultaneous workloads.
Read guide Remote accessVerify the complete public routeConnect DNS, HTTPS, NAT, byte ranges, HLS and WebSockets without exposing management services.
Read guide SecurityProtect a self-hosted media serverUse explicit accounts, bounded sharing, verified updates, safe diagnostics and tested recovery.
Read guideSee whether Finetic earns a place in your home.
Install the compiled server with Docker Compose and evaluate every server feature. No card, automatic charge or source-repository access is required.