RTMP, the Real-Time Messaging Protocol, is a TCP-based application protocol for transmitting audio, video and data messages with low delay between an encoder and a media server. In live video streaming and broadcasting, RTMP is today used almost exclusively as an ingest protocol: it carries the stream from the encoder to the platform, which then repackages it for viewers in formats such as HLS or MPEG-DASH.
RTMP was developed by Macromedia for Flash Player and later maintained by Adobe, which published a specification in 2012. Although browsers dropped Flash at the end of 2020, the protocol survived because nearly every encoder and streaming platform supports it, which makes it a dependable common denominator for contribution.
How RTMP transports a live stream
An RTMP session starts with a handshake over TCP, by default on port 1935. The client and server exchange three small packets each, then the client sends a connect command naming an application, followed by a publish command that names the stream, usually with a stream key that authorizes the upload.
Media is split into messages, and messages are split into chunks, by default 128 bytes and typically raised to 4096 bytes or more by the encoder. Chunking lets the protocol interleave audio, video and control data on one connection so that a large video frame does not block audio.
Inside the messages, audio and video are carried in the FLV tag structure inherited from Flash. Classic RTMP supports H.264 video and AAC or MP3 audio; newer codecs require the extensions described below.
| Element | Function | Typical value |
|---|---|---|
| Transport | Reliable byte stream | TCP, port 1935 |
| Handshake | Version and timing exchange | C0-C2 and S0-S2 packets |
| Chunk size | Unit for multiplexing messages | 128 bytes default, often 4096 |
| Application and stream key | Address and authorization | rtmp://host/app plus key |
| Payload format | Audio and video tags | FLV, H.264 and AAC |
RTMP variants and extensions
Several variants of RTMP add encryption or alternative transports. Of these, RTMPS is the one that matters in current workflows, because many platforms require encrypted ingest.
| Variant | What it adds | Current relevance |
|---|---|---|
| RTMP | Plain protocol over TCP | Widely used for ingest |
| RTMPS | RTMP inside TLS, usually port 443 | Required or preferred by major platforms |
| RTMPE | Proprietary Adobe encryption | Obsolete, weak security |
| RTMPT | Tunneling over HTTP | Obsolete firewall workaround |
| Enhanced RTMP | New codecs signaled by FourCC | HEVC, AV1 and VP9 ingest |
Enhanced RTMP, an industry extension published in 2023, adds signaling for HEVC, AV1 and VP9 and later for multitrack audio. It allows HDR and higher-efficiency ingest without abandoning existing RTMP infrastructure, but both the encoder and the server must support it.
RTMP compared with other streaming protocols
RTMP sits on the first mile of a live chain, while HLS and MPEG-DASH serve the last mile to viewers. SRT competes with RTMP for contribution, especially over unreliable networks.
| Protocol | Transport | Typical latency | Main role |
|---|---|---|---|
| RTMP | TCP | About 1 to 5 seconds | Encoder to platform ingest |
| SRT | UDP with retransmission | Below 1 second to a few seconds | Contribution over the public internet |
| HLS | HTTP segments | About 6 to 30 seconds, low-latency mode 2 to 5 | Delivery to viewers |
| MPEG-DASH | HTTP segments | Similar to HLS | Delivery to viewers |
| WebRTC | UDP, SRTP | Under 0.5 seconds | Interactive, real-time viewing |
The weakness of RTMP is its reliance on TCP congestion control. On a link with packet loss, TCP retransmits and slows down, so the encoder buffer fills and frames are dropped. SRT handles loss more gracefully because it recovers packets within a fixed latency window, which is why broadcasters prefer it for remote contribution.
Configuring RTMP ingest
A reliable RTMP stream depends on encoder settings that match the platform’s ingest rules and leave headroom in the uplink. The most frequent cause of an unstable stream is a bit rate that is too close to the available upload capacity.
| Setting | Common choice | Reason |
|---|---|---|
| Video codec | H.264 High profile | Universal platform support |
| Rate control | Constant bit rate | Predictable load for the platform transcoder |
| Keyframe interval | 2 seconds | Aligns with platform segment boundaries |
| Bit rate for 1080p | About 4.5 to 9 Mbps | Depends on frame rate and content motion |
| Audio | AAC, 128 to 192 kbps, 48 kHz | Accepted everywhere |
| Upload headroom | Bit rate below about 75 percent of uplink | Absorbs network fluctuations |
The stream key must be treated like a password. Anyone who obtains it can broadcast to the channel, so it should not be shown on screen or shared in shared configuration files, and it should be regenerated after any exposure.
Limitations and common mistakes
RTMP is simple and robust on good networks, but its design dates from the Flash era. Knowing its limits helps operators decide when to move to RTMPS, Enhanced RTMP or SRT.
- RTMP is not a playback format today; viewers in browsers receive HLS, DASH or WebRTC, not RTMP.
- Plain RTMP is unencrypted, so stream keys and content travel in clear text; use RTMPS where available.
- Variable keyframe intervals cause platform transcoding errors and stalling for viewers.
- A single TCP connection offers no forward error correction, so lossy cellular or satellite links perform poorly.
- Legacy RTMP cannot signal HEVC or AV1, so HDR ingest requires Enhanced RTMP or another protocol.
In simple terms
RTMP is the delivery route for live video from the streamer’s computer to the streaming service. The streaming software packs the picture and sound into a steady flow and sends it to the service’s server, which then prepares copies for every viewer.
It works a bit like a dedicated courier between a studio and a broadcast center. The courier is reliable on good roads, but on bumpy ones it slows down, which is why newer routes exist for difficult connections.
A practical example
A university streams a weekly lecture series. A hardware encoder in the lecture hall sends a 1080p, 30 frames per second signal over RTMPS to a video platform at 6 Mbps with a 2-second keyframe interval and 160 kbps AAC audio. The building has a 50 Mbps wired uplink, which leaves ample headroom.
The platform receives the RTMP stream, transcodes it into several renditions and delivers it to viewers as HLS. Viewers watch with a delay of about 10 seconds, which is acceptable for lectures. When the series later adds a remote speaker joining over a hotel connection with packet loss, the team uses SRT for that contribution link and keeps RTMPS for the final upload to the platform.