Transport Protocols

The transport protocols used in Livepeer: RTMP for ingest, HLS for delivery, WebRTC for low-latency playback and broadcast, and trickle for real-time AI.

---

Livepeer’s video pipeline spans four distinct transport layers. The choice of protocol at each layer is determined by the requirements of that layer: encoder compatibility at ingest, CDN delivery at playback, sub-second latency in the browser, and persistent low-latency framing for real-time AI.

Protocol by Layer

RTMP (Ingest)

RTMP (Real-Time Messaging Protocol) is the standard input format for live streams. OBS, FFmpeg, and all professional encoders support it. go-livepeer accepts RTMP on port 1935 by default (-rtmpAddr flag).

The stream name is taken from the first path segment of the RTMP URL: rtmp://localhost/stream/<name>. The HLS output manifest appears at http://localhost:8935/stream/<name>.m3u8. A stream key can be appended to the RTMP URL to prevent unauthorised playback.

RTMP is an ingest-only protocol in modern Livepeer deployments. Playback goes through HLS or WebRTC.

See for flag reference and stream key configuration.

HLS (Playback)

HLS (HTTP Live Streaming) is the standard delivery format for VOD assets and standard live streams. Livepeer outputs ABR HLS: a top-level manifest listing multiple rendition playlists, one per transcoding profile. Players (including the @livepeer/react Player) select the appropriate rendition based on available bandwidth.

HLS carries 5-15 seconds of glass-to-glass latency for live streams due to segment buffering. This is acceptable for event streams and VOD but not for interactive scenarios.

See for manifest structure and ABR configuration.

WebRTC (Low-Latency Live)

WebRTC provides sub-second glass-to-glass latency for live streams. The @livepeer/react Player uses WHEP (WebRTC-HTTP Egress Protocol) for low-latency playback and the Broadcast component uses WHIP (WebRTC-HTTP Ingestion Protocol) for browser-based publishing.

WHIP was standardised by the IETF as RFC 9725 in March 2025. It provides a single HTTP POST for WebRTC session establishment, replacing the proprietary signalling protocols previously required for WebRTC ingest.

WebRTC requires ICE server infrastructure (STUN/TURN) for NAT traversal. Livepeer’s managed gateway infrastructure handles this; self-hosted gateways require ICE server configuration.

See for WHIP/WHEP endpoint details and ICE configuration.

Trickle (Real-Time AI)

The trickle protocol (j0sh/http-trickle) is an HTTP/1.1-based streaming transport for real-time AI frame pipelines. It splits a media stream into sequential short segments delivered as soon as they are produced. The gateway opens a persistent HTTP connection to the orchestrator; the orchestrator forwards frames to the ai-runner over a second trickle connection.

Trickle is an internal protocol between Livepeer components. Developers interact with it indirectly via the live-video-to-video pipeline endpoint and the PyTrickle StreamServer interface.

See for the Cascade architecture that uses trickle.

Related Pages

RTMP

go-livepeer RTMP ingest: flags, stream keys, and webhook authentication.

HLS

HLS output format, ABR manifest structure, and segment delivery.

WebRTC

WHIP/WHEP endpoints, ICE configuration, and low-latency playback.

Real-Time AI Overview

Cascade architecture and the trickle-based frame pipeline.