The Livepeer Development Stack — Technology Behind Live Streaming Built on Ethereum

The Livepeer Project is aiming to build a solution for decentralized live video broadcasting, that uses a cryptoeconomic protocol and incentives to create a video broadcast network that is scalable, secure, and more cost effective than centralized alternatives. The technology challenges that go into solving this problem touch many different areas, and this post is an attempt to share the different layers in the stack that we are building at Livepeer. For more background on the project, check out Introducing Livepeer, and our Whitepaper. The Livepeer platform includes development at the following layers:

• Cryptoeconomic protocol design and implementation
• Peer-to-peer networking
• Media transcoding
• Live video serving + P2P content distribution
• Client/Node development

Cryptoeconomic protocol design and implementation

At the heart of Livepeer lies the cryptoeconomic protocol that provides the incentives for nodes to contribute their CPU and bandwidth in the service of live video encoding and distribution. The protocol design provides security, verification of work, and distribution policy for Livepeer token, and is defined in The Livepeer Whitepaper. The implementation of the protocol is being carried out using the following tools:

• Ethereum smart contracts built in Solidity for Livepeer token, bonding/unbonding and delegation, transcoder election, verification of work claims, and governance.
• Swarm for decentralized storage of video for verification and archival and video-on-demand.
• Truebit for work verification.

Development of the protocol is well underway (open sourced soon at first milestone), and has been accelerated by the use of OpenZeppelin’s peer reviewed framework for tokens and common utilities. Truffle and TestRPC have served as valuable tools for development practices, testing, and continuous integration during development of the protocol.

Truebit is a very exciting project for scaling computation off chain, in a way that can still be trusted and verified on chain. It would be impossible to verify all the encoding for live video on chain, so instead Livepeer plans to use Truebit to verify small random portions of the encoding off chain, with a smart contract as a backstop in the case of dispute resolution (which should never occur if implemented correctly). We’re prepared to implement “Livepeer-flavored-Truebit” where necessary if the Truebit project’s roadmap prioritizes other aspects of their platform. One of the more technical aspects of this is implementing an on-chain interpreter for the Lanai architecture (work started by Truebit project), so that small bits of computation can be performed on chain in case of dispute. If you’re interested in working on a compiler project, please get in touch with us and the Truebit folks.

Peer-to-peer Networking

Some of the challenges at the network layer that have to be addressed in a decentralized protocol include:

• Peer discovery
• Key exchange and encrypted communication
• Message routing and reliable delivery
• Support for multiple transports like UDP, TCP, WebRTC, etc
• Firewall and NAT traversal

The Livepeer proof of concept node was built on top of the DEVP2P networking layer built into Ethereum from the ground up. This solution is working great for basic network formation and P2P message delivery. However we have the goal of being able to support very low latency live streaming within the web browser and mobile clients directly.

The libp2p project, out of Protocol Labs, the creators of IPFS, supports multiple transport protocols and addressing schemes, and has a nice modularity for being able to have full control over your network stack. The JS implementation allows browser nodes to communicate on an equal playing field with native nodes, which can bring us one step closer to the Livepeer protocol running in every browser, every mobile device, and every server or desktop instance. See this talk at DevCon2 for a demonstration of libp2p bridging the gap between the browser and DEVP2P within the Ethereum protocol. More on p2p networking below in the video delivery section.

Media Transcoding

Transcoding is the process of taking the input video stream from a phone, camera, or laptop, and converting it into all the formats and bitrates necessary to reach every device on the planet at every connection speed. Most open transcoding solutions are very low level, and most commercial transcoding solutions are closed source, proprietary, and expensive. Livepeer is building an open source media server, called the Livepeer Media Server (LPMS), that aims to support a user friendly high level interface for common transcoding requests, including multiple input and output formats, and adaptive bitrate streaming.

LPMS is being built in the Go programming language from the ground up, however it makes use of popular open source libraries such as FFmpeg to do the heavy lifting underneath the hood. At the moment LPMS supports RTMP inputs, and RTMP, HLS outputs at multiple bitrates. Transcoding nodes in the Livepeer network will be running LPMS internally, and it will handle all of the transcoding as well as the serving of requested streams.

LPMS is a great candidate for open source contributions. The roadmap outlines a number of features requested by different video projects, and as an entirely open solution, the community will benefit together from the work being done once in an open way, instead of repeated within every closed, proprietary media server solution that exists today.

Live video serving + P2P content delivery

Transcoding is the computationally heavy step in a live video pipeline. Content delivery is the bandwidth heavy step. In a centralized system, video can be distributed through any number of centralized content delivery networks (CDNs), but if you’d like to remove that single point of failure and cost, then it is necessary to distribute the video in a peer-to-peer manner.

We already discussed P2P networking a bit above, but to distribute live video with low latency, it’s necessary to implement a content delivery protocol on top of the transport layer that the networking solution provides. In the proof of concept, Livepeer used a multicast tree channel based approach, as described in the SWATCH outline on top of Swarm. While we will continue to test this, and it may work reliably in a network with low churn and nodes with high bandwidth availability, it may not survive so well in a less reliable network situation — aka the open internet.

Our candidate protocol to address these issues is based upon the Peer-to-Peer Streaming Peer Protocol, or PPSPP. In this scheme, the entire set of nodes consuming a live video form connections with one another, and pass small pieces of the video around as soon as it’s available, rather than simply receiving all bits of video from one channel provider. Proprietary solutions like Peer5, Bittorrent Live, and other p2p CDNs take this approach. While some of the hard problems to squeeze performance out of the network aren’t solved directly by the PPSPP standard, we believe that an open implementation and incentivized approach will lead to the right technical solution.

Building on top of the transport protocols supported in libp2p, browser nodes, mobile nodes, and full nodes will all be able to communicate on a level playing field and enable the decentralized distribution of video with low latency on all devices.

Client/Node Development

Livepeer is an open protocol and platform for live video distribution. While it’s not a product in and of itself, user experience and developer experience matters. As such, it’s important that:

• A livepeer node, including token storage, be easy to set up and run on any machine.
• Transcoding nodes can interact with the protocol effectively without having to pay constant attention at risk of getting slashed.
• LPMS have a simple interface for broadcasting video and accessing output streams.
• Decentralized app developers can easily include live streaming in their products.
• Any existing broadcaster can try out diverting some of their video through Livepeer and realize cost savings.

To facilitate this we’re developing clients in Golang and JS, as well as mobile clients for broadcasting. We’re building desktop app proofs of concept using Electron so that users can create and consume streams. And we need to create the right developer interfaces so that folks can get started with Livepeer.

Conclusion

As this post indicates, we have a lot of work to do to make decentralized live video broadcasting a reality. But we are off and running, with quite a bit of open source development in action on our Github. If you are interested in the engineering challenges posed by the stack described above, particularly related to video engineering and p2p networking, please take a look at this job description and don’t hesitate to get in touch. Onwards!

For further updates on Livepeer, you should follow @LivepeerOrg on twitter and join the community chat.