What is RTMP Pass-Through?
RTMP pass-through relays an incoming Real-Time Messaging Protocol stream to another endpoint while preserving its encoded media. Unlike transcoding, it does not decode and recompress the audio or video.
How RTMP Pass-Through works
In pass-through mode, a service receives RTMP messages, preserves the compressed tracks, and republishes them toward another RTMP endpoint. It may still demultiplex, remultiplex, adjust timestamps, or reconnect the session, so relay behavior is not necessarily a byte-for-byte copy. Avoiding codec reconstruction reduces compute demand and prevents generational quality loss. The relay sits in the live ingest path when source encoding already satisfies the destination’s codec, rate, and packaging expectations.
Key facts
- 1Classic RTMP commonly carries H.264 video and AAC audio in FLV-style messages, making that combination a frequent compatibility baseline for pass-through ingest.
- 2A relay cannot repair an unsupported codec, excessive bitrate, invalid keyframe cadence, or mismatched audio layout without transforming the media or rejecting it.
- 3Timestamp discontinuities and source reconnects can propagate downstream; a robust relay must decide whether to preserve, normalize, or restart the outgoing timeline.
When RTMP Pass-Through matters
Use pass-through to restream a compatible live feed with low processing overhead and no re-encoding loss. The destination must accept the original codecs and stream parameters, or playback or ingestion may fail.
Common use cases for streaming
These examples cover streaming broadly, not specifically RTMP Pass-Through.
- Delivering long-form, episodic, educational, live, or user-generated video over variable networks.
- Providing low-bandwidth through high-resolution renditions from one master.
- Combining captions, alternate audio, encryption, thumbnails, and ad markers with playback media.
Working with streaming
This guidance covers streaming broadly, not just RTMP Pass-Through.
An encoder creates several quality levels, and a packager divides them into aligned segments referenced by a manifest. During playback, the client estimates throughput and buffer health, then requests an appropriate segment from one rendition at a time.
Streaming quality depends on the relationship between renditions, segments, manifests, players, and the network. A valid encode can still perform poorly if keyframes are misaligned, the ladder is inefficient, or the player cannot switch cleanly.
What you gain
- Segmented delivery lets playback begin without downloading the entire program.
- Multiple renditions let a player adapt quality as network and device conditions change.
- HTTP-based protocols can reuse ordinary web caching and delivery infrastructure.
What it costs
- Short segments can reduce switching and live latency but increase request and packaging overhead.
- A dense rendition ladder offers finer adaptation while increasing encoding, storage, and cache cost.
- More aggressive quality selection can improve sharpness but raises rebuffering risk on unstable networks.
Before production
- 1Test the rendition ladder on slow, changing, and high-latency connections.
- 2Align segments and keyframes, then validate manifests in the target players.
- 3Measure startup, rebuffering, quality switches, CDN efficiency, and playback failures.