RTMP, RTMPT and RTMPS: What They Are and Whether to Still Use Them

The three names in one table

Name	What it is	Used for today
RTMP	Real-Time Messaging Protocol, developed by Adobe for audio, video and data between Flash player and server, carried over TCP	Ingest (encoder to server) — still the mainstream choice
RTMPT	RTMP tunnelled inside HTTP to cross firewalls	Historical; effectively retired
RTMPS	RTMP secured with SSL/TLS — RTMP over TLS	When the ingest path must be encrypted

What RTMP actually does

RTMP behaves like a container for data: the payload may be AMF-formatted control data or FLV-wrapped audio and video. A single connection carries multiple streams over separate channels, with packets transmitted in fixed-size chunks.

Originally both halves of a live chain ran on it — an FMS server on one end and a Flash player on the other. Today only one half of that picture still holds.

Why RTMP survived the end of Flash

A typical modern chain splits into two legs:

• Leg one (ingest): encoder to server over RTMP or SRT. Requirements are low latency, stability and broad compatibility.
• Leg two (delivery): server to viewers over HLS, DASH or HTTP-FLV. This runs on HTTP so it traverses CDNs and arbitrary networks.

So "RTMP is obsolete" is only half true: as a playback protocol it has exited; as an ingest protocol it is still the de facto standard.

How the three variants differ

• RTMP: cleartext, default port 1935. Simplest to configure, best compatibility.
• RTMPT: wrapped in HTTP so it could traverse firewalls that only allowed port 80, at the cost of overhead and higher latency. As firewalls began allowing 1935 and HTTPS tunnelling matured, it fell out of practical use.
• RTMPS: adds TLS encryption, materially better security for public-network transport, at the cost of handshake and crypto overhead plus server-side support.

One claim from older material deserves a caveat — that RTMP is inherently harder to copy than HTTP because it does not cache locally. Whatever truth that had, protection today rests on authentication, tokens and DRM, so it should not drive a protocol decision.

When to use RTMP — and when not to

Scenario	Recommendation	Why
Ingest to a cloud platform or CDN	RTMP	Widest support; the default in platform documentation
Stable LAN or leased line	RTMP	Good link quality means no need for extra loss resistance
Public internet with visible loss or jitter	Use SRT instead	RTMP sits on TCP; loss inflates latency or stalls the stream
Encryption required on the link	RTMPS or SRT	Cleartext RTMP is unsuitable for sensitive content over the internet
Viewer-side playback	HLS or HTTP-FLV	Flash is gone; browsers no longer play RTMP
4K at high bitrate on an average link	Test first	The bottleneck is bandwidth and loss, not the protocol

How it divides work with SRT and HLS

• SRT: reliable, secure transport over unreliable networks with strong loss recovery. It beats RTMP clearly on public links and mobile backhaul. It competes with RTMP on leg one.
• HLS: HTTP-based segmented delivery with the best traversal and CDN support, at the cost of latency (typically several seconds; low-latency HLS reaches roughly 2–5 seconds). It owns leg two.
• HTTP-FLV: a common low-latency delivery option, lower latency than HLS with reasonable traversal.

Common RTMP configuration pitfalls

1. Wrong address hierarchy: an RTMP URL is server address + port + application name + stream key. The last two are assigned by the platform; getting them wrong connects to the server but fails to publish, usually with an unhelpful error.
2. Missing DNS: when publishing to a domain name, the encoder's network settings need a correct DNS server, which differs by ISP. Failure looks like "network is fine but nothing goes out".
3. Codec mismatch: H.264 over RTMP is the safe choice. If the encoder is set to H.265, many servers and players cannot handle it — the symptom is a black picture or audio with no video.
4. Bitrate above real upstream capacity: the most common cause of stutter. Set bitrate at roughly 60–70% of measured upstream and leave headroom.
5. Port 1935 blocked outbound: common on corporate networks. Confirm outbound 1935, or move to RTMPS over 443.

Suggested order: first pull the encoder's RTSP or HTTP stream in VLC on the LAN to confirm encoding is healthy, then check network and DNS, then verify the platform-side address and authentication. That cleanly separates device problems from network or platform problems.