What is RTMP? A Practical Guide for Enterprise Video Teams

RTMP, or Real-Time Messaging Protocol, is a TCP-based protocol that carries live video and audio from an encoder to a streaming platform. It is the protocol that gets the stream from the camera into the platform. From there, the platform transcodes the feed and delivers it to viewers using a different protocol entirely, usually HLS or DASH. Most working RTMP today is invisible to the audience. It is what the production team's encoder is doing in the background.

For enterprise video teams, RTMP shows up in one specific place: the ingest path. When you set up a webcast or live stream, the encoder you use, whether that is a hardware appliance from Teradek or AJA, or software like OBS Studio, sends the compressed feed to the platform over RTMP. The encoder URL the platform gives you starts with rtmp:// or rtmps://. That is RTMP doing its job.

This guide covers what RTMP actually is, how it works in a real enterprise streaming pipeline, why people keep saying it is dead (and why it is not), the difference between RTMP and RTMPS, and what you need to know to set up a reliable RTMP stream. By the end you should be able to evaluate an encoder, troubleshoot a failed ingest, and have an honest answer the next time someone asks if RTMP is still relevant.

What is RTMP?

RTMP is a protocol developed by Macromedia in the early 2000s for streaming video, audio, and data between a Flash player and a server. Adobe acquired Macromedia in 2005, opened the spec in 2009, and RTMP became the dominant protocol for low-latency live streaming on the web for the next decade.

The protocol is built on TCP, meaning every packet is acknowledged and resent if lost. That is what makes RTMP reliable for live ingest. When an encoder is pushing a live feed to a platform, you cannot afford to drop packets quietly and have audio/video desync. RTMP guarantees order and delivery, at the cost of slightly higher latency than UDP-based protocols.

The technical specifics: RTMP runs on TCP port 1935 by default, splits the stream into chunks (typically 64 bytes or 128 bytes), interleaves audio, video, and data within those chunks, and supports adaptive streaming through bitrate switching. The data is unencrypted in standard RTMP, which is why enterprises almost always use RTMPS instead (more on this below).

The reason most working video professionals know RTMP today is that the entire live streaming ecosystem standardized around it for ingest. Twitch, YouTube Live, Facebook Live, every enterprise webcasting platform, every encoder manufacturer, all built around RTMP as the default ingest protocol. Even now, with newer protocols available, RTMP is still what the encoder pushes to the platform in 90%+ of live streaming setups. That market position is why RTMP outlived Flash by a decade and is still the default ingest protocol in 2026.

Is RTMP dead?

Short answer: no. The longer answer is more useful.

What died was Flash. Flash Player reached end-of-life in December 2020 after Adobe officially deprecated it, browsers removed support, and the consumer-facing reason for RTMP's existence (delivering video to a Flash player in a browser) disappeared.

What did not die was RTMP itself, because the protocol was never just about Flash playback. It was the ingest standard, and it remains the ingest standard. The chain looks like this today:

• Encoder pushes to platform via RTMP. This still happens. Almost every encoder on the market still defaults to RTMP. The platform listens for the RTMP stream on a specific URL (often called the "stream key" or "ingest URL").

• Platform transcodes the RTMP feed into multiple HLS or DASH renditions. This is where RTMP exits the chain. The protocol's job is done once the platform has received the feed.

• Platform delivers HLS or DASH to viewers. This is what the audience experiences. RTMP is no longer involved.

So RTMP is not dead. It just got pushed back to one specific stage in the pipeline, and it owns that stage. The protocols that replaced RTMP for delivery (HLS and DASH) are not designed for ingest, and the protocols that compete with RTMP for ingest (SRT, WebRTC, RIST) have not displaced it because the ecosystem of encoders, hardware, and tooling around RTMP is too entrenched to move quickly.

The practical answer for enterprise video teams: assume RTMP is part of your ingest path for the foreseeable future. Plan for RTMPS as the secure variant. Know what its limits are.

How RTMP works

The mechanics are simpler than the specification makes them look. There are three things happening.

• Step 1: The encoder establishes an RTMP connection to the platform. The encoder is configured with an ingest URL (something like rtmp://ingest.platform.com/live/) and a stream key (a unique identifier the platform uses to associate the incoming stream with the right event). The encoder opens a TCP connection on port 1935, performs an RTMP handshake (a three-step exchange to confirm both sides speak RTMP), and creates a "publishing stream" that the platform now listens to.

• Step 2: The encoder pushes encoded video and audio over the connection. The encoder takes the camera feed, compresses it using a codec (typically H.264 for video, AAC for audio), splits the compressed data into RTMP chunks, and pushes them down the TCP connection. The platform receives the chunks, reassembles them into a coherent stream, and starts processing.

• Step 3: The platform processes and redistributes the stream. The platform transcodes the incoming RTMP feed into multiple resolutions and bitrates, packages the renditions in HLS or DASH format, and serves them to viewers through a CDN. From the audience's perspective, none of this is visible. They just see a video player that works.

What can go wrong at each stage is also useful to know. At step 1, the connection fails if the firewall blocks port 1935, the ingest URL is wrong, or the stream key is invalid. At step 2, the stream can stutter or disconnect if the encoder bandwidth is unstable, the encoder settings are misconfigured (bitrate too high for the upload connection, keyframe interval too long), or the platform is having ingest issues. At step 3, the audience sees buffering or playback failures if the transcoding is overloaded or the CDN is misconfigured.

RTMP vs RTMPS

RTMP is unencrypted. The video, audio, and metadata moving between the encoder and the platform are visible to anyone who can intercept the network traffic. For consumer streaming, this is rarely a concern. For enterprise streaming, it is unacceptable for any sensitive content.

RTMPS is RTMP wrapped in TLS encryption, the same kind of encryption your browser uses for HTTPS. RTMPS runs on TCP port 443 by default (the same port HTTPS uses), making it firewall-friendly, and it encrypts the entire stream from encoder to platform. The encoder configures rtmps:// instead of rtmp:// and everything else stays the same.

For enterprise webcasts, especially internal town halls with confidential strategy or financial information, RTMPS is non-negotiable. The performance overhead is minimal on modern hardware. The security gain is meaningful. There is no reason to run RTMP unencrypted for an enterprise event in 2026.

A common confusion: RTMPS is not a different protocol. It is RTMP plus TLS. Anything that supports RTMP can usually be configured to use RTMPS by changing the URL prefix and the port. If your encoder or platform does not support RTMPS, that is a sign you are running outdated software.

RTMP vs HLS vs DASH vs WebRTC vs SRT

The streaming protocol landscape is crowded. Five protocols dominate different parts of the pipeline, and they are not interchangeable.

• RTMP is for ingest, sending video from an encoder to a platform. It is reliable, low-latency at the ingest stage, and ubiquitous. Almost every encoder supports it.

• HLS (HTTP Live Streaming, developed by Apple) is for delivery, sending video from a platform to a viewer's player. It is HTTP-based, works through any firewall that allows web traffic, and supports adaptive bitrate streaming so a viewer on slow connection gets a lower-quality version automatically. HLS is the dominant delivery protocol on the web and on mobile. Latency is typically 10-30 seconds, which is fine for most enterprise use cases but too high for true real-time interaction.

• DASH (Dynamic Adaptive Streaming over HTTP) is also for delivery, very similar to HLS in structure. It is the international standard (HLS is an Apple standard). Most platforms support both and serve whichever the player requests. The differences between HLS and DASH matter mostly to streaming engineers; for enterprise video teams, the platform handles the choice.

• WebRTC is for ultra-low-latency, two-way streaming. It is what powers Google Meet, Microsoft Teams' browser experience, and most browser-based video calling. Zoom uses its own proprietary protocol for native clients but supports WebRTC for browser-only joins. Latency is sub-second. WebRTC is excellent for video conferencing and interactive applications, but it is a poor fit for one-to-many broadcasts because it does not scale well past a few hundred concurrent connections without complex infrastructure.

• SRT (Secure Reliable Transport) is a newer ingest protocol, designed by Haivision, that addresses some of RTMP's limitations: lower latency, better packet loss recovery over unstable networks, modern encryption. SRT is gaining adoption in broadcast workflows and contribution feeds (sending video from a remote venue back to a studio), but most enterprise video platforms have not yet replaced RTMP with SRT for ingest. Expect SRT to grow over the next few years, not displace RTMP entirely.

The practical takeaway: a typical enterprise webcast uses RTMP for ingest (encoder to platform), HLS or DASH for delivery (platform to viewer), and avoids WebRTC unless the use case is specifically interactive. Each protocol is doing the job it is best at.

How to set up an RTMP stream

The setup is more straightforward than the protocol description suggests. The steps are the same whether you are using a hardware encoder or software like OBS Studio.

• Get the ingest URL and stream key from your platform. Every webcasting platform provides these in the event setup screen. The URL looks like rtmps://ingest.platform.com/live/ and the stream key is a long alphanumeric string. Together, they tell the encoder where to send the stream and how the platform should identify it.

• Configure the encoder. In the encoder settings, paste the ingest URL into the server/URL field and the stream key into the stream key field. Set the video codec to H.264, the audio codec to AAC, the resolution and bitrate to match your event's quality target (1080p at 6 Mbps is a common starting point for high-quality enterprise webcasts), and the keyframe interval to 2 seconds. These settings work for most platforms; check your platform's documentation for any specific requirements.

• Test the connection well before the event. Start a test stream from the encoder to the platform at least one full day before the live event. Verify the platform receives the feed, the audio and video are in sync, the bitrate is stable, and the test viewer experience is smooth. The morning of the event is the wrong time to discover the encoder cannot reach the platform.

• Have a backup encoder ready. Hardware encoders fail. Software encoders crash. The cheapest insurance for any production webcast is a second encoder, configured identically, ready to take over if the primary fails. Some enterprise platforms support automatic failover between primary and backup ingest URLs. If yours does, configure both.

• Have a backup network path. Most webcast failures trace to network issues at the venue. A second internet connection, even a mobile hotspot or a separate ISP, can save the broadcast if the primary connection fails. The encoder should be able to switch network interfaces without restarting the stream, but most cannot, so plan for the possibility of restarting the stream on the backup network.

If any of these steps feel unfamiliar, that is a sign your team would benefit from running a technical rehearsal end-to-end with the actual production setup before any high-stakes event.

Common RTMP problems and how to fix them

A few patterns show up over and over in enterprise RTMP troubleshooting.

• The connection refuses to establish. Usually a firewall is blocking outbound TCP on port 1935 (for RTMP) or 443 (for RTMPS). Switch to RTMPS on 443 if you are not already, since 443 is rarely blocked. If RTMPS still fails, work with IT to allowlist the platform's ingest hostname.

• The stream connects but immediately disconnects. Almost always a stream key problem. The platform did not recognize the stream key, or the key was for a different event, or the event has not started yet on the platform side. Verify the key in the platform's event settings.

• The stream stutters or buffers on the receiving end. Bitrate is set too high for the upload bandwidth, or the upload bandwidth is unstable. Reduce the encoder bitrate or move to a more reliable network connection. Run a sustained upload test (not just a speed test, which can mislead) at the bitrate you plan to stream.

• The stream is severely out of sync (audio leads or lags video). The encoder is misconfigured. Check the audio and video timestamp settings in the encoder, ensure both are using the same reference clock, and verify the audio sample rate matches what the platform expects (usually 48 kHz).

• The stream has a frozen first few seconds. The keyframe interval is too long. Set it to 2 seconds. Some platforms require shorter intervals (1 second) for adaptive bitrate switching to work cleanly.

These are not exhaustive, but they cover the majority of real-world RTMP failures in enterprise webcasting setups.

Where RTMP fits in an enterprise video pipeline

For enterprise video teams, RTMP is one piece of a larger pipeline that needs to work end-to-end.

The capture stage is where the production team operates. Cameras, microphones, video switchers, the production environment in the room or studio.

The encoding stage is where RTMP enters. The encoder takes the production feed, compresses it, and pushes it over RTMP (or RTMPS) to the platform.

The ingest and processing stage is where the platform takes the RTMP feed, transcodes it into multiple HLS/DASH renditions, records the live broadcast for on-demand viewing, generates captions, and prepares the stream for distribution.

The delivery stage is where the public CDN serves HLS/DASH to external viewers and an eCDN handles internal corporate distribution to employees on the same network. RTMP is not involved in delivery.

The playback stage is where the viewer's browser or app receives HLS/DASH and plays it back. Authentication, audience interaction, and analytics happen here.

RTMP touches one stage of this pipeline. But that stage is the foundation. If the RTMP ingest fails, nothing downstream matters. The eCDN, the delivery CDN, the player, the analytics, all of them are useless if the encoder cannot push the stream to the platform.

This is why production teams obsess over the encoder, the ingest URL, and the network path between the venue and the platform. It is the part of the pipeline most likely to fail, and the part with the smallest margin for error.

Enterprise RTMP streaming with EnterpriseTube

EnterpriseTube ingests live video over RTMPS as the default for enterprise webcasting events. The platform supports any encoder that speaks RTMP or RTMPS, including hardware encoders from Teradek, Epiphan, and Matrox, and software encoders like OBS Studio, vMix, and Wirecast. Platform-side, the RTMPS endpoint sits behind the same SSO and access controls that govern the rest of the platform, so authenticating to schedule an event also authenticates to ingest from it.

Once the RTMPS feed arrives, EnterpriseTube transcodes it into multiple adaptive bitrate renditions in real time and distributes through a public CDN for external viewers, with a P2P enterprise content delivery network handling internal distribution. The platform records the broadcast automatically. Once the event ends, AI processes the recording for transcription (in 82 languages), automatic chaptering, summarization, and object detection, and the on-demand replay is searchable from the moment processing finishes.

For enterprise teams running live streaming and webcasts, the RTMP pipeline does not need to be visible. It needs to work reliably, push securely, and integrate with the rest of the video platform. EnterpriseTube handles the parts of the RTMP/RTMPS pipeline that production teams should not have to think about.

To see how the platform handles a specific use case, start a free EnterpriseTube trial or talk to the team.