Skip to main content

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.

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.

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:
import { Livepeer } from 'livepeer';

const client = new Livepeer({ apiKey: process.env.LIVEPEER_API_KEY });

const { stream } = await client.stream.create({
  name: 'my-stream',
  profiles: [
    { name: '720p', bitrate: 3000000, fps: 30, width: 1280, height: 720 },
    { name: '360p', bitrate: 1000000, fps: 30, width: 640, height: 360 },
  ],
});

console.log(stream.rtmpIngestUrl); // push here from OBS / FFmpeg
console.log(stream.playbackId);    // use in @livepeer/react Player
The @livepeer/react package provides a Player component for HLS and WebRTC playback and a Broadcast component for browser-based WHIP publishing:
npm install @livepeer/react

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.
livepeer \
  -broadcaster \
  -network arbitrum-one-mainnet \
  -ethUrl <ARBITRUM_RPC_URL> \
  -ethKeystorePath /path/to/keystore \
  -maxPricePerUnit 0 \
  -rtmpAddr 127.0.0.1:1935 \
  -httpAddr 127.0.0.1:8935
The gateway’s ETH deposit in TicketBroker on Arbitrum One must be funded before jobs are accepted. Orchestrators check the deposit before processing segments. Self-hosted gateways give you control over orchestrator selection (price filtering, explicit inclusion/exclusion), payment parameters, and routing. This path is relevant when operating at scale where per-pixel cost matters, or when you need to run alongside custom middleware. See local gateway setup for the step-by-step development path.

Transport protocols

LayerProtocolDirection
Live ingestRTMPEncoder to gateway
VOD and standard live playbackHLS (ABR)Gateway/CDN to player
Low-latency live playbackWebRTC (WHEP)Gateway to browser
Browser publishWebRTC (WHIP)Browser to gateway
Segment submission (internal)HTTP/HTTPSGateway to orchestrator
RTMP is the standard ingest format. HLS carries 5-15 seconds of glass-to-glass latency for live streams due to segment buffering. WebRTC provides sub-second latency; the @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.
Last modified on May 19, 2026