IP Streaming Protocols — HLS, RTMP, SRT, RTSP, WebRTC

IP streaming protocols govern how encoded video and audio move from a source encoder to a destination — whether that destination is a CDN for audience delivery, a remote venue for contribution, a browser for conferencing, or an IP display for digital signage. No single protocol is optimal for all uses: the right choice depends on latency requirements, audience size, firewall constraints, and whether the stream is contribution (encoder to server) or distribution (server to viewer). AV integrators encounter all five major protocols — HLS, RTMP, SRT, RTSP, and WebRTC — and must understand their trade-offs to design reliable streaming systems. For deep coverage of SRT and WebRTC specifically, see signal-types/srt and signal-types/webrtc.

Streaming Architecture: Contribution vs. Distribution

Before selecting a protocol, clarify the role of each link in the streaming chain:

Contribution (encoder → ingest server or CDN): The encoded video travels from the venue to a server for processing and distribution. Quality matters most; latency is secondary (5–30 seconds is acceptable). Protocols: RTMP (industry standard), SRT (increasingly preferred for reliability), RIST.

Distribution (server → viewers): The server delivers the stream to potentially thousands of simultaneous viewers. Scalability and device compatibility matter most. Protocols: HLS (universal compatibility), DASH (adaptive streaming), WebRTC (sub-second latency, limited scale).

Direct peer-to-peer or point-to-point: Encoder directly feeds a display, decoder, or second location without a central server. Protocols: SRT (firewall traversal, low latency), RTSP (IP camera feeds), NDI (local network).

A typical live event streaming system uses SRT or RTMP for contribution (venue encoder → cloud ingest) and HLS for distribution (cloud → audience browsers/apps). The latency introduced at each stage is additive.

HLS — HTTP Live Streaming

Overview

HLS was developed by Apple (2009) and is now the universal standard for video delivery to browsers, mobile devices, and smart TVs. HLS segments the video stream into short MPEG-TS or fMP4 (Fragmented MP4) files (typically 2–10 seconds each) and serves them via standard HTTP. Clients download segments sequentially and play them in order. Because HLS uses standard HTTP/HTTPS, it passes through any firewall and CDN without special configuration.

Latency

Classic HLS latency is 15–45 seconds — the sum of segment duration, playlist update interval, and client buffer. This is unacceptable for live interaction but fine for broadcast-style delivery.

Low-Latency HLS (LLHLS), standardized in 2019, reduces latency to 2–5 seconds by serving partial segments and using HTTP/2 push. LLHLS is supported by Apple devices (iOS 14+, macOS 11+) and modern CDNs (Cloudflare, Fastly, AWS CloudFront). Enabling LLHLS requires both the encoder and CDN to support it.

HLS Adaptive Bitrate (ABR)

HLS supports multiple quality renditions in a master playlist. The client automatically selects the appropriate rendition based on available bandwidth:

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
1080p/stream.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2500000,RESOLUTION=1280x720
720p/stream.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360
360p/stream.m3u8

ABR makes HLS resilient to variable internet connections — critical for audience members on cellular networks. Most production encoders (Elemental, Haivision, Wowza, OBS with restream) generate multi-rendition HLS automatically.

Use Cases

• Live event streaming to public audiences (conferences, worship, sports)
• Corporate all-hands meetings delivered via intranet
• Digital signage IPTV systems with centralized media servers
• VOD (video on demand) delivery from media servers

RTMP — Real-Time Messaging Protocol

Overview

RTMP was developed by Macromedia (acquired by Adobe) for Flash Player video streaming. Despite Flash's death, RTMP survives as the dominant ingest protocol for streaming platforms. YouTube Live, Twitch, Facebook Live, and Vimeo all accept RTMP streams from encoders; they transcode internally and distribute via HLS to viewers. RTMP for ingest is effectively universal — any hardware or software encoder (OBS, vMix, Haivision Makito, Teradek Cube) supports it.

Technical Characteristics

• Transport: TCP port 1935 (RTMPS = RTMP over TLS, port 443)
• Latency: 1–5 seconds (inherent TCP buffering)
• Codecs: H.264 video + AAC audio (standard); H.265 via RTMP is non-standard and not universally supported
• Stream key: Each platform provides a stream key (secret URL token) that identifies the ingest destination

RTMP Limitations

RTMP has no native error recovery for packet loss — dropped TCP packets cause encoder stalls and stream interruptions. On unreliable networks (cellular bonding, congested venue WiFi), RTMP contributes streams fail or freeze. SRT has replaced RTMP as the preferred contribution protocol for professional installations precisely because SRT has ARQ retransmission. Most CDNs and streaming platforms now accept SRT ingest alongside RTMP.

RTMPS (RTMP over TLS) should be used instead of plain RTMP whenever the platform supports it — it encrypts the stream and stream key in transit.

RTMP Stream URL Format

rtmp://ingest.youtube.com/live2/[STREAM-KEY]
rtmps://live-api-s.facebook.com:443/rtmp/[STREAM-KEY]
rtmp://a.rtmp.youtube.com/live2

SRT — Secure Reliable Transport

SRT is a modern open-source transport protocol (Haivision, SRT Alliance) designed for low-latency, reliable video contribution over unreliable networks. It uses UDP with ARQ (Automatic Repeat reQuEST) retransmission to recover from packet loss without the head-of-line blocking of TCP. For a full deep dive, see signal-types/srt.

Key Characteristics

• Transport: UDP (default port 9000, configurable)
• Latency: 120 ms to 8 seconds (configurable latency buffer for retransmission)
• Packet loss recovery: ARQ retransmission within the latency buffer window
• Encryption: AES-128 or AES-256 (built-in, passphrase-based)
• Modes: Caller, Listener, Rendezvous (for NAT traversal)

SRT vs. RTMP for Contribution

For contribution links with any risk of packet loss — cellular bonding, public internet, long-haul WAN — SRT is the professional choice over RTMP.

RTSP — Real Time Streaming Protocol

Overview

RTSP (Real Time Streaming Protocol, RFC 2326) is a control protocol for streaming media servers and IP cameras. It functions like an HTTP for media: clients send RTSP commands (DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN) to negotiate a session, and the actual audio/video data travels via RTP over UDP or TCP. RTSP is the standard interface for IP cameras (ONVIF specifies RTSP for video streaming), video encoders, and some media servers.

RTSP URL Format

rtsp://[ip]:[port]/[path]
rtsp://192.168.1.100:554/stream1         # Generic IP camera
rtsp://192.168.1.100:554/cam/realmonitor?channel=1&subtype=0  # Dahua/HikVision
rtsp://192.168.1.100/axis-media/media.amp  # Axis camera
rtsp://192.168.1.100:554/h264Preview_01_main  # Common pattern

Default RTSP port: 554 (TCP for RTSP control); RTP data travels on UDP ports negotiated during setup (typically ephemeral high ports).

RTSP in AV Integration

RTSP is used to:

• Pull video from IP cameras into video switchers, media servers, and recording systems
• Integrate PTZ cameras with NDI converters (Magewell, Epiphan) that accept RTSP input
• Feed IP camera streams into Q-SYS or Crestron for display routing
• Monitor camera feeds on NVRs and VMS (Video Management Software)

Firewall consideration: RTSP uses dynamic RTP ports (UDP, range 1024–65535 by default). Stateful firewall inspection (SPI) may block RTP traffic even when port 554 is open. Enable RTSP ALG (Application Layer Gateway) on firewalls handling RTSP, or configure fixed RTP port ranges on the camera and open those ports explicitly.

RTSP vs. NDI vs. SRT for Camera Feeds

WebRTC — Web Real-Time Communication

WebRTC is a browser-native, peer-to-peer real-time communication standard. For full coverage, see signal-types/webrtc. In the streaming context:

• Sub-second latency (50–500 ms end-to-end)
• No plugin or app required — runs in Chrome, Firefox, Safari, Edge natively
• Used by: Google Meet, Zoom (browser), Microsoft Teams (browser), Amazon IVS ultra-low latency
• Limitation: Does not scale to thousands of viewers without a media server (SFU/MCU) infrastructure
• Codecs: VP8/VP9/AV1 (video), Opus (audio) — not always H.264 compatible

WebRTC is the protocol underlying all browser-based video conferencing. It is not typically used for CDN-scale distribution; at scale, a WebRTC-to-HLS transcoder (Wowza, Ant Media Server) is used to convert sub-second WebRTC streams to HLS for large audiences.

Protocol Selection Guide

Common Pitfalls

• Using plain RTMP instead of RTMPS for public internet contribution. Plain RTMP transmits the stream key and video in cleartext. Anyone on the network path can intercept the stream key and use it to broadcast to your channel. Fix: always use RTMPS (RTMP over TLS, port 443) when the destination platform supports it — YouTube, Facebook, and Twitch all support RTMPS.

• Configuring SRT latency too low for the network path. SRT's latency buffer must be greater than the network round-trip time (RTT) plus jitter for ARQ retransmission to work. Setting a 120 ms latency on a 200 ms RTT path means retransmitted packets arrive too late and are discarded — the stream degrades as if there were no retransmission. Fix: measure the RTT between encoder and decoder (ping or SRT statistics), then set latency to at least 3–4× the RTT; 500 ms is a safe starting point for most internet contribution links.

• RTSP dynamic RTP ports blocked by firewall. RTSP control uses TCP port 554, but the actual video data (RTP) travels on dynamically negotiated UDP ports (1024–65535). A firewall that allows port 554 but blocks dynamic UDP ports will pass the RTSP handshake but not the video. Fix: enable RTSP ALG on the firewall to track dynamic RTP ports; or configure the camera/encoder to use a fixed RTP port range and open those ports explicitly.

• Expecting HLS to deliver sub-5-second latency without LLHLS. Classic HLS with 6-second segments has 15–45 seconds of latency — inherent in the segmented delivery model. A client expecting near-real-time interaction (live auction, interactive event) will experience confusing delays. Fix: use Low-Latency HLS (2–4 second latency) if the CDN and encoder support it; or use WebRTC/SRT for sub-second requirements and HLS for the broad audience.

• Assuming RTSP streams will cross VLANs without firewall rules. IP cameras on a camera VLAN sending RTSP to a media server on a management VLAN require both TCP 554 (RTSP control) and UDP (RTP data) to be allowed in the inter-VLAN ACL. Missing the UDP rule passes the handshake but drops all video frames. Fix: define fixed RTP port ranges on cameras, document them, and include them in the VLAN firewall rules.