Broadcasting live video starts before CDN distribution, before transcoding, before viewers. It starts with getting the video from the streamer’s machine to your servers reliably. That first hop, from broadcaster to origin, is where RTMP fits.

RTMP: Designed for Live#

RTMP (Real-Time Messaging Protocol) was created by Macromedia in the early 2000s for Flash video. It’s old. It’s also still the standard ingest protocol for live streaming because it solves the ingest problem well.

RTMP maintains a persistent TCP connection from the broadcaster to an origin server. Video and audio are sent as a continuous stream of small packets interleaved on the same connection. TCP provides reliable ordered delivery, which matters for video: a dropped packet at the wrong moment corrupts the video stream.

The persistent connection model means the streamer doesn’t negotiate a new connection for each video segment. Connection overhead is paid once. The streaming can continue for hours on a single connection.

Broadcaster → [RTMP, persistent TCP] → Origin Ingest Server
                                              |
                               receives continuous stream of A/V packets

The Ingest Pipeline#

Once the origin ingest server receives the RTMP stream, it:

Converts the incoming stream into segments (typically 2-6 second chunks). This conversion from a continuous stream to discrete segments is what HLS and DASH distributions need downstream.

Writes segments to shared storage (object storage or a distributed filesystem) as they complete.

Signals the packager and CDN that new segments are available.

graph TD A[Streamer: OBS/Broadcast Software] -->|RTMP persistent TCP| B[Origin Ingest Server] B --> C[Segment: 2-6 second chunks] C --> D[Object Storage: segments uploaded] D --> E[Packager: generates HLS/DASH manifests] E --> F[CDN Edge Nodes: pull and cache segments] F --> G[Viewers: download segments] style A fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style B fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style C fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style D fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style E fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style F fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style G fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff

RTMP vs SRT vs WebRTC for Ingest#

RTMP is reliable but not fast: TCP’s retransmission behavior adds latency when packets are dropped. For standard live streams where 5-10 seconds of latency is acceptable, this doesn’t matter.

SRT (Secure Reliable Transport) is a newer protocol that uses UDP with its own reliability layer. It handles packet loss more gracefully than TCP in high-packet-loss environments, making it better for streams over unreliable internet connections (mobile hotspots, stadium WiFi).

WebRTC is designed for sub-second latency but is complex to use for ingest. It’s better suited for interactive streams (two-way video calls) than one-way broadcasting.

At Oracle#

We didn’t do video ingest, but we had a similar problem: devices sending continuous telemetry data to an ingest server over long-lived TCP connections. Connections dropped silently when the device went behind a NAT that had connection timeout. We added heartbeat messages every 30 seconds so both sides could detect dead connections and reconnect quickly. RTMP has a similar ping mechanism to keep connections alive through network middleboxes.

What I’m Learning#

Protocol design for live ingest prioritizes connection stability and simplicity over everything else. A streamer losing their connection mid-broadcast is a catastrophic experience. RTMP’s persistent TCP model makes reconnection the exceptional case rather than the normal case.

Have you worked with long-lived connection protocols and how did you handle silent connection failures?