go-livepeer: the Go implementation of the Livepeer video network

Three roles, one protocol

The Livepeer project aims to deliver a live video-streaming network protocol that is fully decentralized, highly scalable and crypto-token incentivized to serve as the live media layer in the decentralized development stack, and go-livepeer is the Go implementation of the protocol that powers that network. Concretely, the repository contains implementations of three node roles. The Broadcaster is the node that ingests the source stream and publishes it. The Orchestrator is the node that describes the available transcoding pipelines and their prices and that directs work. The Transcoder is the node that does the actual encoding work on demand. That three-way split is the whole economic design in miniature, since the broadcaster does not have to own the compute that serves its viewers, the orchestrator does not have to own the encoders, and the transcoders are paid for what they do. The repository is a Go module, github.com/livepeer/go-livepeer, requiring Go 1.27.0, and it is MIT licensed with a Discord server, a contributing guide and a pull request template, so it is developed in the open as a protocol implementation rather than as a closed service. The topics on the repository list broadcasting, transcode, video-stream and ethereum, which is the same triangle of concerns.

The transcoding stack is real media engineering, not a mock

The dependency list in go.mod is where the media engineering shows itself. The RTSP stack comes from bluenviron, with gortsplib/v4 for RTSP and mediacommon/v2 for media handling, and the WebRTC stack comes from pion, with webrtc/v4, rtp, sdp and interceptor, which together provide the browser-facing ingest path that a broadcaster uses. On the delivery side there is livepeer/m3u8 for playlist handling, and the media/transcode work is done by shelling out to ffmpeg, which is why the repository has an install_ffmpeg.sh script and a transcode_demo.sh at the top level. The core protocol layer is gRPC based, with the net/ directory holding lp_rpc.proto and redeemer.proto, and the Makefile generates the Go bindings from those files with protoc. The monitoring stack is OpenCensus with the Prometheus exporter, plus the Prometheus client library directly, and the server layer uses go-chi for routing and gorilla/websocket for the websocket endpoints. Two dependencies are worth calling out for a system like this. The Ethereum client is go-ethereum at v1.17.5, which is what the on-chain settlement and the AI market contracts are built against, and livepeer/lpms is the payment and settlement service. There is also a heavy use of generated code, with mockgen producing the redeemer mocks and abigen producing Go bindings from the Solidity contracts, which tells you that the chain interface is a first-class part of the codebase rather than an afterthought.

The build runs code generators before it compiles

The Makefile is where the generated code story is spelled out, and it explains why the repository contains committed artefacts. The default target lists everything the build needs to produce.

all: net/lp_rpc.pb.go net/redeemer.pb.go net/redeemer_mock.pb.go core/test_segment.go eth/contracts/chainlink/AggregatorV3Interface.go livepeer livepeer_cli livepeer_router livepeer_bench

There is a separate release target for the binaries, and the comment above it explains the arrangement, that release builds skip the generated files because they are committed.

binaries: livepeer livepeer_cli livepeer_router livepeer_bench

Each generated artefact has its own rule. The protobuf bindings are produced by protoc from the .proto files in net/, the mocks are produced by mockgen from the generated Go sources, the test segment comes from a shell script, and the Chainlink aggregator contract binding is produced by running solc over the Solidity files in eth/contracts/chainlink and then abigen over the resulting ABI. The version is read from a VERSION file at the top of the repository, and it is stamped into the binary with a linker flag that sets the LivepeerVersion variable in the core package.

version=$(shell cat VERSION)

The four binaries in the output are the interesting part, because they map onto the roles and the tooling. The livepeer binary is the node itself, livepeer_cli is the command line client, livepeer_router is a separate router component, and livepeer_bench is the benchmarking tool. The Makefile also takes care with the generators, since they run on the host even when cross-compiling, so GOOS and GOARCH from the environment are explicitly cleared for mockgen and abigen. That is the kind of detail that only matters once you try to build for a different architecture, and it is the sort of thing that is easy to miss in a codebase this size.

Getting started means a private network before a public one

The requirements are short, the project requires go and a unix shell, and the README links a document for installing and managing Go. The getting started section is three steps, and the order is the point. You clone the repo and follow the installation guide for orchestrators, which is linked to the Livepeer documentation site rather than duplicated in the README. Then you follow the guide to set up a private ETH network with the Livepeer protocol deployed, and that guide lives in the repository at cmd/devtool/README.md. That ordering is a deliberate piece of advice for anyone working on the protocol, because a node that talks to a chain it cannot inspect is hard to debug. The devtool gives you a local chain with the protocol contracts deployed, so you can watch the whole flow, registration and job management and payment, without spending gas or depending on a public network's state. The repository also has a docker/ directory, a test_docker.sh, a test_e2e.sh and a ci_env.sh at the top level, which together suggest that the test suite runs against containerised infrastructure, and the presence of testcontainers-go in the dependency list confirms it. The discovery, monitor, server, media, core, eth and net directories at the top level are the subsystems, and the pm/ directory holds the payment manager that the dependencies hint at.

What the AI and byoc directories suggest about where the project is going

Three top level directories point at the current direction of the work. The ai/ directory sits next to a livepeer-data dependency at v0.8.1, and the repository carries a liveai.openapi.yaml file at the top level, which is an OpenAPI specification for something called liveai. The byoc/ directory is named for bring your own compute, and it sits beside a docker/ directory and a box/ directory, which suggests a mode where a deployer supplies their own infrastructure rather than relying on a shared one. The box/ directory is likely the mechanism for that. The verification/ directory is also notable, since a video network has to answer the question of what was actually delivered, and a verification subsystem is the natural place for a proof that a transcoded segment corresponds to the source. None of the README documents these, and the repository listing does not describe them, so the safe reading is that the protocol implementation has grown well past the three roles the README describes, and that the interesting new work is in the AI and compute models rather than in the core transcoding path. The CHANGELOG_PENDING.md file next to CHANGELOG.md is a small but good sign, since it means unreleased changes are recorded rather than only appearing at release time.

Where go-livepeer is the wrong tool

The obvious mistake is to reach for this because you want a video streaming stack. The transcoding part is not the hard part of Livepeer, and if your problem is ingest plus distribution to a CDN, a conventional stack will be simpler, cheaper to operate and free of on-chain settlement. The protocol layer is where the cost sits, since a node has to stake, register with an orchestrator, respond to price and availability signals, do the work and get paid, and each of those steps is a place where a conventional system has no equivalent requirement. The second limit is operational. The project requires Go and a Unix shell, it wants ffmpeg available, it needs a chain connection, and the test infrastructure pulls containers, so this is not something you deploy on a locked-down host without planning. The third is that the reference implementation and the protocol are not the same thing, so building a node from scratch against the specification may be a better fit if your constraints are unusual, and this repository is the better fit if you want to run a node or extend the reference. The fourth is trust. A decentralized network whose participants are paid in tokens is a different risk model from a service agreement, and if your requirement is a predictable monthly invoice with a support contact, that is a different product category. None of that makes go-livepeer wrong, it just means the question to ask is whether you want the network or only the transcoding.

Editorial conclusion

Adopt go-livepeer if you want to run or build on the Livepeer network and need the reference node implementation, or if you want to understand how live video is routed and transcoded for token-incentivised delivery. Skip it if you are building a conventional live streaming stack, because the protocol, the token economics and the on-chain settlement are the hard parts rather than the transcoding. Verify first which node role you intend to run, that you have the Go toolchain and a Unix shell as the project requires, and that the devtool path for a private Ethereum network is set up before you try anything against a public chain.

Frequently asked questions

Official sources

1. License: MIT
2. livepeer/go-livepeer on GitHub
3. Project website
4. README
5. Releases