Livepeer provides GPU-backed video transcoding and delivery for both live streams and recorded video. An encoder pushes a single-quality RTMP stream to a gateway node; the network’s orchestrators transcode it into multiple adaptive bitrate renditions and return the output as HLS for viewers. Video workloads use LPT stake-weighted routing and round-based rewards. This is the protocol’s original economic model, running since 2018.Documentation Index
Fetch the complete documentation index at: https://docs.livepeer.org/llms.txt
Use this file to discover all available pages before exploring further.
Video workload types
Livestreams accept a continuous RTMP push from OBS, FFmpeg, or any RTMP-capable encoder. The gateway segments the stream, routes segments to orchestrators for transcoding, and serves the transcoded output as adaptive bitrate HLS. Sub-second WebRTC playback is available for latency-sensitive applications. VOD assets accept an uploaded video file. The network transcodes it to multiple renditions. The asset is playable via HLS or short-form MP4. Multistream simultaneously pushes a live stream to additional RTMP destinations (YouTube Live, Twitch, custom RTMP servers) alongside Livepeer transcoding. Recording archives a livestream as a VOD asset when the stream ends. The recording is available for playback after transcoding completes.Access paths
Two paths exist for video developers, depending on how much infrastructure you want to operate. The REST API is the faster path: create a stream with four lines of code and get an RTMP ingest URL and HLS playback URL. The self-hosted gateway gives full pricing and routing control but requires operating a node and funding a payment deposit.REST API and SDKs
The Livepeer REST API covers streams, assets, webhooks, playback, access control, and viewership metrics. SDKs wrap the API in TypeScript, Python, Go, and React:- TypeScript
- Python
@livepeer/react package provides a Player component for HLS and WebRTC playback and a Broadcast component for browser-based WHIP publishing:
Self-hosted gateway
Running a go-livepeer broadcaster node gives direct network access. The node accepts RTMP on port 1935, segments the stream, routes segments to orchestrators for transcoding, and serves HLS on port 8935.Transport protocols
| Layer | Protocol | Direction |
|---|---|---|
| Live ingest | RTMP | Encoder to gateway |
| VOD and standard live playback | HLS (ABR) | Gateway/CDN to player |
| Low-latency live playback | WebRTC (WHEP) | Gateway to browser |
| Browser publish | WebRTC (WHIP) | Browser to gateway |
| Segment submission (internal) | HTTP/HTTPS | Gateway to orchestrator |
@livepeer/react Player uses WHEP automatically for live streams when the gateway supports it.
Pricing
Video transcoding on the Livepeer network is priced in wei per pixel. Total output pixels across all rendition profiles per segment, multiplied by the orchestrator’s price, gives the expected payment for that segment. Orchestrators set their price via-pricePerUnit. Gateways set a maximum acceptable price via -maxPricePerUnit. Orchestrators above the maximum are excluded from selection.
The Livepeer Explorer at explorer.livepeer.org shows historical per-pixel prices across the active orchestrator set.
The video overview in the Build section covers ingest configuration, transcoding profiles, VOD upload, and player integration in detail.