Gateway Functions
A gateway performs five core functions for every job it processes:- Job intake - accept requests from applications via RTMP (video) or HTTP API (AI, video, BYOC)
- Orchestrator selection - match each job to the best available orchestrator based on capability, price, latency, and performance history
- Session management - maintain persistent connections to orchestrators for the duration of a stream or job batch
- Payment handling - generate probabilistic micropayment tickets per job segment (on-chain operational mode) or delegate payment to a remote signer (off-chain operational mode)
- Result delivery - return transcoded video (HLS/DASH), inference output (JSON/binary), or stream results to the calling application
Orchestrators perform GPU compute, run AI models, transcode video, and execute containers. Compute providers should see .
Workload Types
Gateways route four categories of work into the Livepeer network. Operational mode sets the eligible categories.BYOC (Bring Your Own Container)
BYOC pipelines allow applications to define custom container-based workloads that orchestrators execute. The gateway routes BYOC requests through the same HTTP API it uses for AI inference, and the orchestrator runs an application-defined container instead of a standard AI model. BYOC enables use cases like custom ML workflows, enterprise-specific processing, and novel applications (e.g. ). See for the developer-side setup.Orchestrator Selection
When a job arrives, the gateway must decide which orchestrator to send it to. This is the gateway’s most important function - it directly affects cost, latency, and reliability for end users. The selection algorithm considers:Discovery Methods
Gateway discovery follows the operational mode:- On-chain gateway
- Off-chain gateway
Queries the on-chain orchestrator registry (ServiceRegistry contract on Arbitrum). All registered orchestrators are discoverable automatically. The gateway refreshes this list periodically.This is the default discovery method and requires no additional configuration.
Sessions and Failover
Gateways maintain sessions with orchestrators for the duration of a workload. For video transcoding, a session covers an entire livestream. For AI inference, a session usually covers a single request or batch. Key session behaviours:- Session reuse - the gateway reuses an existing session with an orchestrator when a new segment of the same stream arrives, avoiding repeated orchestrator selection overhead
- Automatic failover - when an orchestrator fails mid-session (timeout, error, disconnect), the gateway selects the next-best orchestrator and retries the segment
- Session managers - the gateway runs separate session managers for video (
BroadcastSessionsManager) and AI (AISessionManager), allowing dual-workload operation from a single node - Price negotiation - session setup includes price agreement. A mid-session price change triggers renegotiation or a switch
Running both video and AI workloads from a single gateway node is called dual-workload configuration. The gateway handles this through separate session managers - no special setup required beyond enabling both ingest protocols. See for the internal pipeline view.
Gateway Marketplace Role
Gateways participate in the Livepeer marketplace as the demand side. They create competition among orchestrators by routing jobs based on price, performance, and capability. This means:- Better orchestrators earn more work - gateways naturally route to faster, cheaper, more reliable nodes
- Gateways compete on routing quality - application developers choose gateways based on supported features, latency, developer experience, and pricing
- New capabilities are instantly routable - when an orchestrator adds a new AI model or pipeline, gateways discover it and route to it without code changes