What Is RTMP? The Real-Time Messaging Protocol, Explained

By the WpStream Editorial Team

Last updated: June 28, 2026

RTMP (Real-Time Messaging Protocol) is a TCP-based streaming protocol, default port 1935, that carries audio and video from an encoder to a streaming server. Macromedia built it for Adobe Flash around 2002; Adobe now stewards the open specification. On the wire, RTMP keeps a persistent TCP connection open for the entire broadcast, splits media into small interleaved chunks, and uses Action Message Format (AMF) for control messages. The critical distinction in 2026: RTMP is a contribution protocol, not a delivery protocol. It moves video from your encoder to a server, the first mile of the journey, and nothing further. No mainstream browser speaks RTMP anymore because the only thing that did was the Flash plugin, which reached end of life on 31 December 2020. When you stream to YouTube, Twitch, Facebook, or your own WordPress site, RTMP is almost certainly the on-ramp, even though the viewer never touches it. RTMP carries the stream; it does not show the stream.

Where RTMP fits in the bigger pipeline

RTMP is one piece of a much bigger live pipeline, and the pieces around it each deserve their own deep dive. If you want the delivery side of the story, see our adaptive bitrate streaming guide. For the latency question specifically, see low-latency streaming. To go deeper on rolling your own server, see how to build a streaming server. On delivery at scale, see CDN live streaming. And on quality switching, see adaptive bitrate streaming. Below, we stay focused on RTMP itself: what it is, how it works on the wire, and why it outlived the platform that created it.

What is RTMP, exactly?

RTMP stands for Real-Time Messaging Protocol. Macromedia built it for the Flash platform around the turn of the millennium, and after Adobe acquired Macromedia, it became an open specification that Adobe stewards to this day. The core mechanics at a glance: it runs over TCP, defaults to port 1935, keeps a single persistent connection open for the whole stream, splits media into small interleaved chunks, uses Action Message Format (AMF) for its command messages, and historically carries H.264 video paired with AAC audio. Each of those mechanics gets its own treatment below.

RTMP today is a contribution protocol, also called an ingest protocol. It carries video from an encoder up to a server, the first mile of the journey. It is not a delivery or playback protocol. No mainstream browser speaks RTMP anymore, because the only thing that ever did was the Flash plugin, and the Flash plugin is gone. When a viewer watches your stream, their browser is almost certainly playing HLS, not RTMP.

In practice: the encoder pushes RTMP in, and the platform repackages it into something browsers can play and sends that out. RTMP carries the stream; it does not show the stream.

A short history: from Flash to first-mile standard

RTMP originated at Macromedia in the early 2000s, out of an internal project nicknamed “Tin Can,” and shipped publicly around 2002 alongside Flash Communication Server. In 2005, Adobe acquired Macromedia and inherited both Flash and RTMP. By 2009, Adobe had announced it would publish the RTMP specification, and on 21 December 2012 it released the canonical document, “RTMP Specification version 1.0.”

Flash spent the 2010s being deprecated, attacked for security holes, and abandoned by browser after browser, until Adobe formally ended Flash Player’s life on 31 December 2020. By January 2021 the major browsers had removed the plugin entirely. RTMP playback died right there with it, because RTMP playback only ever existed inside Flash.

But the protocol outlived the platform. Encoders kept their RTMP “publish” output, servers kept their RTMP ingest endpoints, and the first mile never switched. One honest footnote: the spec Adobe published was not complete. It left out some details (RTMPE, Adobe’s proprietary encryption layer, being the well-known example), which is exactly why reverse-engineered clients like librtmp had to exist. That gap is real, but it never stopped RTMP from doing its day job.

How does RTMP actually work?

A persistent connection over TCP (port 1935)

RTMP rides on TCP, the reliable, ordered transport that guarantees every byte arrives in the order it was sent. Crucially, it holds that one connection open for the entire broadcast, rather than opening and closing a fresh request for every piece of data the way plain HTTP does. Frames flow continuously up the pipe with no repeated handshake on each one, which keeps latency low on the upload leg.

The handshake: the introduction before any video flows

Before a single frame of video moves, the two sides perform a three-step handshake. The client sends three packets (C0, C1, C2); the server answers with three of its own (S0, S1, S2):

• C0 and S0 are a single byte each, carrying the RTMP version number (value 3).
• C1 and S1 are 1536-byte packets containing a timestamp plus a block of random data.
• C2 and S2 are each side echoing the other’s C1 and S1 back, to confirm receipt.

This is the protocol equivalent of two people confirming they speak the same language before they start talking. It happens once, at the start, and then the stream flows.

Chunks: how audio and video share one lane

Once connected, RTMP splits every message into small chunks and interleaves audio, video, and data chunks over the single TCP connection. This multiplexing lets one connection carry a full A/V stream without one media type starving the other. The default chunk size is 128 bytes, negotiable upward via a Set Chunk Size control message (audio commonly travels in 64-byte chunks). RTMP also defines four chunk header formats; the leaner ones omit any field identical to the previous chunk, cutting per-chunk overhead.

AMF, and what RTMP carries

The command and control messages (“set up this stream,” “start publishing,” “here is the metadata”) are encoded in Action Message Format, in two versions: AMF0 and AMF3. Think of AMF as the instruction language the encoder and server use to negotiate and control the broadcast (a Flash-era artifact that still quietly runs the show on millions of streams). The actual media payload, historically, is H.264 video plus AAC audio, the workhorse pairing every rtmp encoder defaults to. That limitation is exactly what Enhanced RTMP set out to fix.

The handshake, chunk, and AMF mechanics above all come from one source of record: the Adobe RTMP Specification version 1.0, published 21 December 2012. The Wikipedia Real-Time Messaging Protocol article is a readable companion for checking byte-level details.

RTMP variants: RTMPS, RTMPE, RTMPT, RTMFP

“RTMP” is really a small family of related protocols. Most are historical curiosities; one you should actually care about. Here is the lineup.

The one that matters in 2026 is RTMPS. And the key thing: RTMPS is not a different protocol, just the same handshake and chunks running inside a TLS tunnel so nobody on the network path can read your stream key or your video. YouTube’s official RTMPS ingestion page spells out the recipe precisely: connect on port 443, use RTMP over SSL, and include the SNI (Server Name Indication) extension set to the server’s hostname. The practical takeaway: plain RTMP on port 1935 is unencrypted. The moment your stream crosses the public internet, reach for RTMPS on 443 and keep your stream key private.

Enhanced RTMP: the protocol is not actually frozen

The obvious objection to everything above: isn’t RTMP stuck forever on ancient H.264? It was, until recently. The Veovera Software Organization now maintains Enhanced RTMP (often written E-RTMP), an industry-sanctioned modernization of RTMP and the FLV container, developed in collaboration with Adobe, YouTube, and Twitch.

Enhanced RTMP adds modern video codecs: VP8, VP9, HEVC (H.265), VVC (H.266), and AV1, plus HDR support. On the audio side it adds Opus, FLAC, AC-3, and E-AC-3. It also introduces FourCC codec signaling, multitrack streams, a Reconnect Request feature, and finer timestamp precision. As of 2026, the V2 specification is stable and ready for broad implementation.

But here is the honest tradeoff. The codec upgrade only works if both ends (your rtmp encoder and the rtmp server receiving the stream) actually implement it. Recent builds of OBS and vMix do; older encoders and many servers do not. The upgrade is available, but it is not automatic.

Why RTMP survived when Flash did not

The distinction is the spine of everything: RTMP as playback (server to browser) is dead, while RTMP as contribution (encoder to server) is alive and dominant. Three reasons explain why the ingest job stayed loyal to a Flash-era protocol.

Universal encoder support. OBS, vMix, Wirecast, StreamYard, and nearly every hardware H.264 encoder ship with an RTMP “publish” output built in. It is the lowest common denominator of going live. Whatever box or app you are using, it almost certainly speaks RTMP, and that ubiquity is self-reinforcing.

Low ingest latency. That persistent TCP connection pushes frames up continuously, with much lower latency on the upload leg than a chunked HTTP approach would give you. For getting video from your camera to the server quickly, RTMP is genuinely good at its job.

Mature, simple, and good enough. On a reliable connection RTMP is stable, well understood, and supported by every media server and CDN ingest endpoint on the market. There is little incentive to replace something that works.

Read the modern pipeline left to right: your camera or OBS pushes RTMP (or RTMPS) into a media server or cloud platform. That server transcodes and repackages the stream, and the resulting HLS is what viewers actually watch (covered in the adaptive bitrate streaming guide). From there it rides a content delivery network out to players everywhere, a scaling topic covered in CDN live streaming. RTMP owns the first arrow and nothing else.

And RTMP does have a real weakness on that first arrow. Because it rides TCP, packet loss on a flaky network forces retransmissions that can stall the whole stream while everyone waits for the missing piece. On a clean wired connection this rarely causes issues; on congested hotel Wi-Fi or a shaky cellular uplink, it can. That exact gap is the reason SRT was invented, which brings us to the comparison.

RTMP vs HLS, SRT, WebRTC and DASH

The most common mistake here is framing these protocols as rivals fighting for one crown. The right question is not “which is best” but “which job does each one do.” RTMP and HLS are teammates, not competitors: RTMP carries the stream in, HLS and DASH carry it out. Only SRT and WebRTC actually compete with RTMP, and only on the ingest leg. The table below sorts them by job, with latency bands that are illustrative ranges as of June 2026, not guarantees.

Treat every number above as a band, not a promise; real latency depends on your encoder settings, the network, and the platform. And here is the nuance most articles miss: the latency a viewer actually feels is overwhelmingly the HLS delivery repackaging, not the RTMP hop. The upload leg is fast; the seconds pile up afterward, in the segmenting and buffering that make HLS play smoothly everywhere. So if shaving seconds is your goal, the lever is on the delivery side, which is exactly what we dig into in low-latency streaming.

How to set up RTMP ingest yourself

There are two honest paths to running RTMP ingest: build it yourself or let a platform run it. The build-it path first, because understanding it makes the managed path make sense.

The DIY route: Nginx with the RTMP module

The classic open-source approach is the nginx-rtmp-module project, which turns ordinary Nginx into a media server: RTMP in, HLS and DASH out. It listens on port 1935, and inside an application block you set live on; and hls on;, which makes Nginx write out .ts segments and an .m3u8 playlist that a normal HTTP block then serves to HTML5 players. That is the on-the-fly RTMP-in to HLS-out conversion you would otherwise pay a platform to handle. The push and pull directives relay streams to other RTMP servers (handy for restreaming to YouTube and Twitch from one ingest point); exec runs FFmpeg for transcoding; and HTTP callbacks like on_publish enable stream-key authentication. A minimal configuration:

rtmp {
    server {
        listen 1935;
        application live {
            live on;
            hls on;
            hls_path /tmp/hls;
            hls_fragment 3s;
            hls_playlist_length 60s;
        }
    }
}

One honest caveat before you commit: the original arut/nginx-rtmp-module is enormously popular (14,000 GitHub stars as of June 2026), but it is not actively maintained. Many teams now run a community fork or an FFmpeg-based pipeline instead. Do not point a production deployment at the upstream repo expecting active support. For the full build, including transcoding ladders and stream-key authentication, see how to build a streaming server.

Pushing from OBS, the most common reader action

Whether you self-host or use a platform, the encoder side is nearly identical. Open Settings, then Stream in OBS and set Service to Custom. Two fields then matter, and people constantly confuse them. The Server is the RTMP URL, in the form rtmp://host:1935/appname (or rtmps://host:443/appname for encrypted ingest). The Stream Key is the per-stream identifier that tells the server which channel this broadcast belongs to. The URL says where; the key says which. Over in Settings, then Output: set encoder to H.264, rate control to CBR, keyframe interval to 2 seconds, and a bitrate that fits comfortably inside your real upload headroom. That is the whole setup.

Quick disclosure before we go further: WpStream is our own plugin, so treat what follows as the example we know best, not a neutral ranking.

The managed path: RTMP ingest with WpStream

The DIY Nginx route teaches you exactly what a managed platform does for you: the same RTMP-in to HLS-out pipeline, minus the self-hosted server you have to patch, secure, and babysit. WpStream is a WordPress live-streaming and pay-per-view plugin (4,000+ active installs and a 4.8 out of 5 rating across 78 reviews on WordPress.org as of June 2026), and RTMP ingest is available on every plan, including the Free one. Point the same OBS Server and Stream Key you just configured at a WpStream channel, and go live. It also accepts vMix, Wirecast, and StreamYard.

One caveat worth stating plainly, because it trips people up: broadcasting straight from the browser is a paid-only feature. The Free plan supports external RTMP and OBS ingest only, topping out at 50 concurrent viewers on a single channel, with no recording and no pay-per-view. The free tier is genuinely useful for RTMP ingest, but do not expect to skip the encoder on it.

On the delivery side, WpStream takes your RTMP ingest and pushes it out over a multi-CDN footprint spanning continents, using adaptive-bitrate HLS so each viewer gets the quality their connection can handle. End-to-end latency lands at a few seconds. The quality-switching half of that pipeline is worth understanding on its own, and we cover it in adaptive bitrate streaming.

One practical tip before an important broadcast: check your upload headroom with the WpStream speed test. Unlike a generic speed test, it measures against the actual streaming ingest infrastructure, so the number means something for your stream. Run it at your peak-use time and set your encoder bitrate conservatively below whatever it reports. Paid plans start at Lite ($24 per month) and Plus ($59 per month) as of June 2026; confirm current pricing before buying.

Key Takeaways

• RTMP (Real-Time Messaging Protocol) is a TCP-based ingest protocol, default port 1935, that moves video from an encoder to a streaming server, not to a viewer’s browser.
• RTMP playback died with Flash in December 2020; RTMP ingest remains the dominant first-mile standard for live streaming in 2026 because every major encoder ships with it built in.
• Use RTMPS (same protocol, TLS-encrypted, port 443) whenever your stream travels across the public internet; it protects your stream key and your video content.
• Enhanced RTMP adds modern codecs (HEVC, AV1, Opus) to the protocol, but both your encoder and your rtmp server must support it; the upgrade is not automatic.
• Most glass-to-glass latency in a live pipeline comes from HLS delivery repackaging, not the RTMP ingest hop; optimize the delivery side to meaningfully shave seconds for viewers.

Frequently Asked Questions

Is RTMP obsolete in 2026?

No. RTMP playback died with Flash, but RTMP ingest is still the default first mile for almost every encoder, and it is exactly how you push a live broadcast into WpStream today.

Is RTMP TCP or UDP?

TCP, on default port 1935 (RTMPS uses TCP plus TLS on port 443). WpStream accepts both, so you can use the encrypted variant whenever your stream crosses the public internet.

What is the difference between an RTMP URL and a stream key?

The URL (rtmp://host/app) tells your encoder where to send the stream, while the stream key tells the server which channel it belongs to. Your WpStream channel hands you both values to paste into OBS.

RTMP or RTMPS, which should I use?

Use RTMPS (port 443, TLS) whenever the stream travels across the public internet; it is the same protocol, just encrypted, so there is no real downside. WpStream supports secure ingest for exactly this reason.

How do I reduce RTMP latency?

Most of the latency you feel comes from the HLS delivery side, not the RTMP hop, so a 2-second keyframe interval and adequate upload headroom (test it with WpStream’s speed test) help most. For genuinely sub-second interaction, you want WebRTC instead.

What bitrate should I use for RTMP?

Match it to your upload headroom with margin to spare; roughly 6 Mbps is a common starting point for 1080p30 as of June 2026, but your real ceiling is whatever the WpStream speed test reports against the ingest infrastructure.

Where your stream goes from here

RTMP is the on-ramp, not the destination. It outlived Flash by quietly becoming the thing nobody thinks about: the first mile, the boring reliable arrow at the left edge of every pipeline diagram. What actually shapes your viewers’ experience (the latency they feel, the quality they get, the scale you reach) all happens after RTMP has done its small job and handed the stream off. Enhanced RTMP is extending the protocol’s life with AV1 and HEVC while SRT and WebRTC chip at its edges, but for the foreseeable future, if you are going live, you are starting with RTMP. The interesting question stopped being “RTMP or not.” It is now “what repackages your stream once it arrives.” So point that OBS stream key at a WpStream channel and watch what happens on the other side (the answer, mercifully, is “a lot, and none of it your problem”).