Skip to main content
This is a conceptual and tuning guide, not a setup guide. For initial installation and startup, see Setup. For transcoding profile JSON and flag reference, see Pipeline Configuration.
The video transcoding pipeline moves a stream from ingest to playback-ready HLS in three stages:
  1. the gateway segments incoming video,
  2. dispatches each segment to a selected orchestrator with a payment ticket, and
  3. assembles the transcoded renditions for delivery.
This page explains what happens at each stage and how to tune it.
Video transcoding requires on-chain operational mode in production. Remote signers (off-chain mode) do not support video because ticket signing must happen in the hot path per segment. Off-chain video with -network offchain is available for local development and testing with a local orchestrator only.

Architecture

Source reference: BroadcastSessionsManager

go-livepeer/core/broadcast.go

Ingest

The gateway accepts incoming video through two protocols. Which one you use depends on your publishing client.
RTMP is the standard ingest protocol for live streaming. Encoders such as OBS, ffmpeg, and hardware encoders push streams to the gateway’s RTMP server.Default listen address: 127.0.0.1:1935To accept external connections, bind to all interfaces:
-rtmpAddr 0.0.0.0:1935
The ingest URL format is:
rtmp://<gateway-host>:1935/<stream-key>
The gateway reads the incoming RTMP stream, extracts GOP (Group of Pictures) boundaries, and slices the video into segments for distribution.

Orchestrator Selection

Once the stream is ingested, the BroadcastSessionsManager selects which orchestrators will transcode each segment. Selection is not random - the manager evaluates orchestrators against multiple criteria simultaneously.
The -maxPricePerUnit flag sets the maximum number of wei per pixel your gateway will pay. Orchestrators advertising prices above this ceiling are excluded. Setting this too low will result in no available orchestrators; setting it too high means you may overpay.The unit of measurement is wei per pixel. A common starting value for production is 1000 wei per pixel, though competitive market rates vary. Use the Livepeer Explorer and livepeer_cli to see what orchestrators are currently advertising.
The manager tracks round-trip latency and success rate for each orchestrator per session. Orchestrators with degraded latency or high failure rates are deprioritised. This is entirely automatic - you do not need to configure individual orchestrator scoring.
Transcoding sessions are maintained across segments. If an orchestrator fails mid-stream (network drop, timeout, GPU OOM), the manager performs a mid-stream swap: it selects the next best orchestrator and continues from the next segment. The output is seamless to the viewer because the renditions continue - there is no restart.The livepeer_orchestrator_swaps Prometheus metric tracks swap frequency. A high swap rate indicates orchestrator instability or an overly aggressive price ceiling.
On-chain (production): the gateway queries the Livepeer on-chain registry (Arbitrum One) for registered orchestrators that meet your price ceiling. Discovery is automatic; you do not need to list addresses manually.Direct configuration: specify orchestrators directly via -orchAddr as a comma-separated list. The gateway connects to exactly those addresses. Most production gateways with established orchestrator relationships use this pattern.Webhook: use -orchWebhookUrl for dynamic orchestrator lists from an external service.
# On-chain: registry discovery (set network and ETH credentials)
-network arbitrum-one-mainnet

# Direct: specific orchestrator addresses
-orchAddr http://192.168.1.100:8935,http://192.168.1.101:8935

Transcoding

Each segment is sent to the selected orchestrator along with a payment ticket. The orchestrator transcodes the segment into the renditions your profile specifies and returns them to the gateway. The gateway verifies each returned segment before assembling the output using pixel count and signature verification (-localVerify=true, enabled by default for on-chain gateways). If a segment fails verification (wrong duration, corrupt data, wrong resolution), the manager retries with a different orchestrator up to -maxAttempts times (default: 3).

Built-in rendition presets

If you do not specify a custom transcoding profile, the gateway uses a comma-separated list of named presets:
-transcodingOptions P240p30fps16x9,P360p30fps16x9
Available built-in presets follow the pattern P<height>p<fps>fps<aspect>. Common values: P240p30fps16x9, P360p30fps16x9, P720p30fps16x9, P1080p30fps16x9.

Custom JSON profiles

For production deployments, a custom transcodingOptions.json file gives you precise control over the encoding ladder. The full JSON format and per-platform setup are in the Pipeline Configuration page.
[
  {
    "name": "720p",
    "width": 1280,
    "height": 720,
    "bitrate": 3000000,
    "fps": 0,
    "profile": "h264constrainedhigh",
    "gop": "1"
  },
  {
    "name": "480p",
    "width": 854,
    "height": 480,
    "bitrate": 1600000,
    "fps": 0,
    "profile": "h264constrainedhigh",
    "gop": "1"
  }
]
Reference this file at startup:
-transcodingOptions /path/to/transcodingOptions.json

Payment Flow

On-chain video gateways use Livepeer’s probabilistic micropayment (PM) system. Every segment sent to an orchestrator carries a payment ticket. Most tickets are losing lottery draws; winning tickets are redeemed on the Arbitrum One TicketBroker contract against your ETH deposit.
You must have a non-zero ETH deposit and reserve on the TicketBroker contract before your gateway can route video jobs on-chain. Orchestrators will reject jobs from a gateway with an empty deposit. See Fund Your Gateway for the deposit steps.
The per-segment cost depends on two factors:
  • Pixels transcoded: width × height × number of renditions
  • Price per pixel: the orchestrator’s advertised rate in wei per pixel
Example cost estimate: A 720p segment (1280 × 720 pixels) transcoded to three renditions (720p, 480p, 240p) at 1000 wei/pixel:
Total pixels per segment = (1280×720) + (854×480) + (426×240)
                         = 921,600 + 409,920 + 102,240
                         = 1,433,760 pixels

Cost per segment = 1,433,760 × 1000 wei = 1.43376 × 10⁹ wei = ~0.0000014 ETH
For a 1-hour stream with 2-second segments (1800 segments):
1800 × 1.43376 × 10⁹ wei ≈ 2.58 × 10¹² wei ≈ 0.00258 ETH
Monitor your deposit balance via livepeer_cli → Option 1 or the livepeer_gateway_deposit Prometheus metric. Top up before the deposit approaches zero.

Output

The gateway assembles transcoded segments into an HLS manifest (.m3u8) with one variant stream per rendition. Your application or CDN pulls this manifest to serve adaptive bitrate playback. Low-Latency HLS (LL-HLS) is also supported for reduced end-to-end latency. HLS manifest endpoint: http://<gateway-host>:8935/<stream-key>.m3u8 Current manifest shortcut: if -currentManifest is enabled, the most recently active stream is accessible at /stream/current.m3u8 - useful for single-stream setups. For persistent storage, the -objectStore flag pushes segments and manifests to an S3-compatible bucket or IPFS, so streams survive a gateway restart.

Key Metrics

For Prometheus setup and alert YAML, see Monitoring Setup.

Pipeline Tuning

If jobs are failing because no orchestrators are available under your price ceiling, either raise -maxPricePerUnit or use on-chain mode for access to the full orchestrator pool. Use livepeer_cli to see available orchestrators and their advertised rates.
Lower GOP size in your transcoding profile reduces segment duration and therefore end-to-end latency. Set "gop": "1" for keyframe-aligned segments. Use a lower -maxAttempts value if retries on failed orchestrators are adding unacceptable delay - but ensure you have redundant orchestrators before reducing retry tolerance.
The -maxSessions flag (default: 10) caps concurrent active streams. Increase it for high-throughput deployments. The gateway does not enforce per-stream quality independently - all streams share the orchestrator pool you have connected.
Use -authWebhookUrl to point to an HTTPS endpoint that validates stream keys before the gateway begins transcoding. The webhook receives the stream key and returns allow/deny. This prevents unauthorised streams from consuming your orchestrator budget.
Last modified on March 16, 2026