Livepeer Protocol Client, PPSPP, and Transcoding Update - 7/6/2017

Updates
1

This is a development focused update on a bunch of work in progress development that’s been going on in the past two weeks. The summary is:

  • The client for interacting with the Livepeer Protocol is beginning to work with the on chain smart contracts
  • The concept of a Transcoding Job is now in place and supported by the Livepeer Media Server
  • Development of the PPSPP protocol for delivering video segments amongst a swarm of connected peers rather than just relaying all video from one origin node is well underway and making good progress.

Protocol Client

For those of you who have used or seen the go-livepeer node in action, you’ve seen video broadcast and consumed in a peer to peer way through the Livepeer toy network. This proof of concept didn’t contain any incentives or security mechanisms to make sure that people would be willing to run nodes to transcode and distribute video correctly. The Livepeer Protocol, as defined in the whitepaper, introduces these incentives. The latest version of the Livepeer client introduces interaction with the blockchain smart contracts to introduce these incentives. Over the past two weeks we’ve made significant progress on two of the main loops for users to participate in Livepeer.

  1. The Bond -> Delegate -> Reward loop which allows users to bond their tokens, delegate them towards effective transcoders, and earn their portion of newly minted token upon successful completion of work.
  2. The Job -> Claim -> Verify loop which allows broadcasters to submit transcode jobs to the network, transcoders to claim the work they performed on that job, and verification to ensure that the work was done correctly.

We have our first working integration tests that use the Livepeer client node to run through both of these loops on the Ethereum blockchain, and we’ll be pushing forward to create the right interfaces, daemons, and event listeners to let users participate in the manual parts (like choosing to bond your tokens or delegate them towards a transcoder), and let the node do the automated parts (like remembering to claim your work or call the reward function after it’s been performed).

Right now the smart contracts are open source on github, and the client itself will be opened up as soon as we get through more of a working end-to-end milestone.

Transcoding Job

The above workflows work regardless of what actual work is being done on the live video stream, but of course we want to provide useful adaptive bitrate transcoding functionality as the starting point for the network. We also hit the milestone last week of getting the “transcoding job” complete for a number of popular transcoding profiles in our p2p network.

When a broadcaster submits a job on chain, they can specify the transcoding parameters such as what bitrates and output formats they would like their stream converted to. A transcoder gets selected via the protocol, can take the initial stream, perform the transcoding, and alert the broadcaster of the new output stream ID. This lets the broadcaster create a manifest listing the different bitrates and formats so that players can request whichever stream they’d like depending on device and connection speed.

As we integrate this with the client protocol workflows described above, we’ll be well on our way to a test network with live incentives.

PPSPP

As mentioned in previous updates, we’re testing the PPSPP (Peer-to-peer Streaming Peer Protocol) for delivering video in more of a swarm-based way with video being delivered from many peers, rather than in a relay based approach where you’re reliant on one peer’s bandwidth and availability to serve you the entire stream. We’ve implemented a number of the message types:

  • Handshake
  • Have
  • Data
  • Request

and we have the framework for building in the integrity and ack messages for being able to run our first tests soon. We’ll also open source this library, and it’s something we’re looking for contributions on if people are interested in peer-to-peer networking and live protocols.

It’s been and will continue to be busy on the development front, as we push towards our milestones of launching a fully working end-to-end test network with incentives in the next couple months. We’re also open to adding team members if you’re a developer interested in p2p, video, blockchain, and decentralized technology.

2

this may be in your whitepaper, but what mechanic are you employing to authenticate the outbound stream from a transcoding node is identical in substance to the inbound stream?

3

Good question. That’s the “verification of transcoding work” problem, and the majority of our whitepaper is devoted to laying out the solution. The high level is that…

  1. The broadcaster “signs” the segments of the original stream so that everyone can trust that this is indeed the right inbound segment.

  2. As the transcoder is doing their work they keep track of a bunch of state (hashes, signatures, even raw stream data) temporarily. When they finish their work they submit a proof that commits them to the work they have done…essentially representing what their output data is in a way that they can never claim otherwise later.

  3. Later on, random segments are challenged. To get paid the transcoder needs to submit the proof of what the original segment was and what the output segment was. Since they have already committed to their work, they can’t change it at this point, and the protocol can verify that they did the work correctly (using Truebit or other methods).

That’s the economically and cryptographically secure way. The quick, practical, sanity check way is that the broadcaster can do spot checks and stop paying the transcoder if they’re not behaving correctly…and the viewer of the stream’s player can do spot checks on the new stream plus original broadcaster signature to make sure it’s getting the right output.