Web3 Goes Live -- Livestreaming Video on the Peer-to-Peer Internet

Um uh my name is Eric Tang and uh I am here uh with the Livepeer project. Uh at first I want to thank Victor and the and the organizers here to to invite us here to to tell you a little bit about video streaming. Um the past four days has been really awesome for me like just being among like my peers and all trying to make decentralized web happen and it's like the best thing ever. So, today I'd like to share a little bit about um why decentralization is so important for video live streaming. Um and also uh want to share a little bit about um a road map where um how how we can work together to make this whole system work because um live streaming is is you know a combination of many different things and Livepeer is is is a part of that and and Swarm is a part of that um and and among other systems.

Uh so, before I dive in, I would like to give a live demo and uh and I know this is against the rules of uh presentations in general, but uh I will do that. So, what I'm doing here is I am live streaming uh a video from my phone to the test network that we've set up about a month ago and I am consuming that video from my um from my uh uh uh gate gateway. Um It it it's not very clear, but um but you can see this is video live streaming working in a decentralized peer-to-peer network. Um so, thank you. Uh I just broke my presentation.

That's okay. Um so with the uh you know, with peer-to-peer decentralized video streaming, um there's a bunch of use cases that we can enable that that was not possible before, right? Um I think uncensorable journalism is super important um as we can as we have seen, you know, happening right now in the world. Uh whenever there is a some kind of political unrest or um war breaks out, the live video stream is the first thing that gets cut off. Um but a decentralized video streaming solution can be very very important in solving this problem.

Uh another interesting thing that I'm personally very excited about is a pay-as-you-go education or expert network. So this could be um things like a tutoring service or telemedicine or telepsychiatry um where, you know, finally the service providers can have the tools they need to connect and transact directly with the people who need the service and get off the centralized networks today that are charging 30 to 80% of that transaction fee. Um another really interesting use case here is an auto-scaling social video service. Um and this and this works because um in in video live streaming, we're we're pretty notoriously known for the peaks and valleys of the resources needed to provide the service. Um you know, popular streams come up and it you'll require a lot of uh bandwidth and computation to serve that and then it goes away and then uh you don't need that service anymore.

Uh so the underlying um economics uh in the blockchain can really create this automatically dynamically um changing um network and throughput to solve this problem and save a lot of cost. And finally, this decentralized video live streaming network enables DApp developers to to build completely decentralized applications that have a video component where, you know, we haven't been able to do before. So, I'm really looking forward to seeing all kinds of interesting use cases that people can think of with a decentralized solution for video streaming. Um so, before we can get into how decentralized video streaming works, I thought I would um take a quick uh we can take a quick look at how video streaming works today on the internet. Uh what we see here is a broadcaster, could be, you know, from my phone, could be a ca- could be a webcam, or could be a, you know, high quality uh camera from from a news reporter uh sending an RTMP video into a cloud-hosted um media server.

Now, this media server does a few things that are important. One is that it will store the video for a future playback. Another is that it can um optionally interact with a DRM system to encrypt the video so you can preserve the privacy of the video. Um and another really important thing is that the media server will transcode the video into many different bit rates and video formats so so that these video formats can be delivered to the CDN and they can be delivered to the end devices that you're watching the video on, whether it's a mobile phone, a tablet, a computer, a high-definition TV, or even IoT devices, any device that can uh that can connect to the internet. So, here what we have is a workflow called adaptive bitrate streaming.

And this is basically what makes the video streaming experience work on the internet. Um and and what this really means is um the end player is able to pick the right version of the video to play based on his his own network network condition. So, what we're seeing here is we have we were starting off with a cell connection at around 200k connection speed and the best video for that is a 240p video. And as we switch to a 4G connection, the player is able to switch to a 360p video with no interruption in the playback experience. And this is crucial for streaming on the internet because the download speed on the internet can vary throughout time because unforeseen things can happen on the internet.

So, here are all the bit rates and formats that we have to worry about when we are streaming videos. As we can see, there's there's quite a bit of them, which means and this just means for every stream that gets streamed onto the internet, we have to transcode it into all these different formats in order to serve all the devices that are out there. On top of that, other than the bit rates, we also have to think about video codecs. The the most popular video codec today is H.264, but there's a new codec coming out called HEVC.

We're We're not going to go over the details of the difference, but the high-level difference is that HEVC is able to pack a much crisper picture with the same amount of data, right? What what we see in the in your left in my left, your right is HEVC video served in the same same amount of bits as a H.264. And as we see, HEVC is much better. And it just happens that H.

264 and HEVC are proprietary codecs, which means when you're using them, you have have pay a licensing fee to the patent holders. So, um there on the counterpart, there is a open source codec called VP9. Um companies like Google are funding the development of this, and the and and the next generation of that codec is called AV1. So, all of this complexity that I described makes video transcoding and delivery very complex and very costly. To to put some number on that, uh a traditional SaaS uh transcoding service typically costs about $3 $3 per stream per hour.

Um and you can If you want to build your own stack to do this, you'll have to license expensive proprietary technology uh in order to do that because there's no good open source uh media server out there. Um and on the delivery side, it costs about uh 12 cents per gig on the on a regular CDN. Um this might not seem like a lot, but uh regular you know, average Twitch user uses about 6 and 1/2 gigs. Um and YouTube uses a little less, but not that much. And this comes out to be a little less than uh a dollar per user per month.

And if you have millions of users, this you can potentially be paying millions of dollars per month just to the CDNs to relay your your video. And so, when we think about using decentralized solutions to solve these problems, um what we really want is on top of all the nice things that decentralization provides like censorship resistance, we want to have a cheaper and better solution than a centralized service. And this is pretty special because um in a in in the blockchain world currently, we we have pretty um pretty expensive services. Um and what we do but what we're trying to do here is to make the service cheaper and better. So, so what what that really means is we want to change this picture which I showed earlier into this picture.

So, we want to teach Web3 how to do the video transcoding, how to do the encryption, how to do the storage, how to do the video delivery, so that when DApp developers are creating DApps, you don't have to worry about all this stuff, and all that stuff is hidden away from you. So, you you only have to worry about the incoming video and and get the video into your DApp, and that's it. Uh so, this sounds like a pretty daunting task cuz there's a lot of moving parts, but luckily, a lot of these components are being used today. So, for the storage layer, we have projects like Swarm, IPFS storage, all doing decentralized storage in for slightly different use cases. For video delivery, we have projects like BlockCDN and Filecoin.

And within the Swarm project, we have the Swatch spec that addresses specifically for video delivery. Uh for content protection and privacy, we have decentralized key management systems that are coming out. And on the application layer, we're starting to see a lot of interesting app app tokens and DApps that are trying to address the problem for incentivizing the content creators and connecting them directly to their viewers. Uh so, these are projects like the Props project from YouNow, the Stream token project, and the Parity DApp. So, this is all great, but creating protocols are hard, right?

Because you have to create your software, and then you have to create your decentralized protocol so that it can work in a decentralized way. And not on top of that, if you want to create a protocol that scales well, that's even harder. And if you want a protocol that scales well and is cheaper when it's scaled, that's even harder, right? So, today, I want to use Livepeer and video transcoding as an example to show you some of the lessons that we have learned in the past year about about some of the principles. So, on the high level, when I think about the blockchain, I think the most powerful thing there is that we can create completely new economics and realign incentives, right?

And And this is very apparent for video transcoding and in the live in the Livepeer network. So, in the traditional service economy, what we have is a broadcaster sending a video in and the the broadcaster has to pay for the cost of the service plus a margin that these that the the platform is charging. But, in a decentralized in a decentralized world, the protocol itself can create incentives by by releasing the crypto token on a on a predictable schedule to the nodes that are providing the services to these networks so that when the broadcaster is sending the same video into the into the decentralized network, it has to pay for the cost of the service minus the incentive that the blockchain is already providing to these service providers, right? Now, this might be subtle, but it's a pretty important difference because it kicks off this virtuous cycle, right? Where cheaper broadcasting would drive more demand onto the network, which over time increases the token value, and the increase of the token value, as we can see as as we already seen in the Bitcoin and Ethereum mining world, the brings brings in competition for the service providers, and that creates better hardware, better software, and even better cheaper bandwidth.

And all of that increased capacity and increased capability of the network goes back into creating even cheaper broadcasting services. And this is how you kick off this flywheel that makes the makes the service cheaper and cheaper and makes them makes the network scale more and more. Now, this all sound good in theory, right? But, when it comes to practice, we have to make sure the protocol incentivizes reliable service and it creates a a protocol in both from a cryptographic standpoint and a crypto-economic standpoint. So, for the case of Livepeer, what we do for for reliability is we use a delegated proof of stake service protocol where the transcoders, when they become active and join a network, they advertise their rates and stats and their fee shares.

So, that when the token holders see the see that information, they can choose which which transcoder to delegate towards. And in the delegation process, the token holders are essentially protecting themselves against the predictable inflation that's happening in the protocol. And for every round that that happens in the protocol, the top end transcoders become active and they get work in proportion to the stake that they get from the stake from the token holders. Now, this is important because number one, it creates an open an open market where you have open competition and downward price pressure for the transcoding service. And two, it creates some stake for the transcoders so that we can we can create accountability and economic disincentives for for the transcoders who are trying to game the system.

So, let me walk through how the how the Livepeer protocol works to do this. When the broadcaster first wants to broadcast a video, it it creates a job on chain with the smart contract. And and the smart contract uses that uses that pricing information to find a transcoder who's willing to do the work. And when that happens, the broadcaster can start sending the video to the transcoder. When the broadcaster is sending the video, it signs every single video packet so that the transcoder knows exactly and can verify who the broadcaster is.

When the transcoder is doing the work for every video segment, it's creating a it's creating a transcoding claim using the transcoder result hash and the signature from the broadcaster. And it's keeping this it's keeping these claims around and when the job is finished, it creates a Merkle root based on all these claims and it writes that Merkle root back on chain. When that happens, the Livepeer protocol in the smart contract reveals a challenge segment where uh which the uh transcoder has to provide the Merkle proof for. Now, this is important because um the transcoder does not know what the challenge segment is before before the stream is over so that the transcoder is forced to do work for every single segment and it can't cheat. Now, but this is not enough, right?

It just ensures that the transcoder is doing the work for every segment. It doesn't ensure the the work is done correctly. So, to do that, we have to use an off-chain uh computation oracle uh like TrueBit or Oraclize. And what this does is you uh the transcoder can write the the broadcasted segment for the for the challenge segment onto Swarm or IPFS and the the computation oracle will use that information to do the actual transcoding so that um after after it's it does the computation, it'll write the result hash back on chain. So, now on chain we the protocol has the Merkle proof from the transcoder and it also has the result hash from the comp from the computation oracle and it'll it'll compare the two results and make sure they're correct.

And if they're different, it means the transcoder has done something wrong and the transcoder will be slashed. Now, this is how we're able to create a secure or decentralized transcoding market. So, now I'm going to demo how that works. Um So, what I'm doing is I'm connecting to the testnet and I am starting to stream uh from my camera uh to in into the testnet. And the testnet will go through the the tran- transcoding election process and and start transcoding the video.

And what we will see in a little bit is the transcoding results. Um and this is and I said this is really important because we need to have different versions of the same video. So, the big version might be from my laptop. Um the really small version might be from my phone. And the middle version maybe is for uh for uh a tablet or something.

Thank you. Now, the transcoding is only one piece in this whole live streaming uh workflow, right? Another really important piece is delivering the actual content. So, to do that um we created a prototype based on the Swarm node. Uh and the and and we showed this off at the Swarm Summit early this year.

And the way we did this was first we extended the Buzz protocol in Swarm so that uh each Swarm node can relay videos to each other. Uh we also created a Stream DB so that each stream can be searched for and found in the peer-to-peer network. And on top of that, we created a streamer interface so that we uh we can embed the Livepeer media server into the Swarm node and make each Swarm node also a media server so that each Swarm node can take in uh ingest video and can serve uh an outgoing video. And since then, we've been working on scalability solutions to make sure uh not only can we relay videos around, but when thousands of people are watching the same video, this video can be delivered reliably, and these people can all have really good uh viewing experiences. Um So, so let's look at why video delivery is hard in in a decentralized world.

Um so, what we have here is a very naive way to relay a video, right? A broadcaster is sending video into the network, um maybe to a to a few people or to a few nodes or just one node, and this node is relaying the video downstream to the to the nodes that they're trying to watch this stream. And now, this is already much better than the centralized solution because now the broadcaster does not have to provide all the bandwidth for everyone who wants to watch the video, right? It only has to relay to a few nodes, and these nodes will spread the consumption of the of the bandwidth around. But, it has a weakness, right?

Slow upstream bandwidth will cause the downstream viewers to have really bad experience, um and this is this is undesirable. What we really want is a highly connected graph where every node can stream little bits and pieces from every other node. So, instead of one video being relayed down a down a tree, we have this video being swarmed around in this highly connected graph. So, this is why we've been working on this protocol called PPSP, which stands for peer-to-peer streaming peer protocol. I didn't name this.

Uh it's been it's been a RFC spec that's been in the works for for a few years. Um and it has some really great properties, right? Number one, it creates a over overlay network on the base peer-to-peer network for every specific video, so that only the people who care about the video would join these swarms. Um it has very small data chunks. It the recommended chunk is 1024 bytes, which means we can break the video segments down into very small segments and really relay them around and has much more flexibility.

Um, it uses a single Merkle root to represent the entire stream so that when you're relaying the video around, the data can be validated and and it will have integrity. Uh, and you compact multiple messages into one packet. You can have and now you can have many connections to many peers and download the stream from many peers at the same time. Um, and I can let me just walk through the really simple version version of how this works, right? So, node A wants to join the swarm and start viewing the stream.

So, it asks either a centralized tracker or DHT about the swarm connection information. It gets them, it sends handshakes to all these nodes that it wants to connect to. Nodes can either send a handshake back and a have request have request to tell to tell node A which video chunk that it actually has or it can send a choke request back to tell A, you know, I don't have bandwidth or I don't want to serve the video. Um, after that, A now A knows who to request what video chunk from and it's going to do the request and it's going to get the video back with integrity check and this integrity check is basically just the the Merkle proof because we already have the Merkle hash Merkle root that represents the entire the entire stream. Um, so now A is optionally can send act back and now when a new node joins the swarm and and talks to A, A can start relaying the the information that it just got to these new nodes.

And when the choking node wants to start start relaying streams again, maybe it it got some free more bandwidth, it just sends start sending have message or get message again and it start sends a unchoke message so that it can start requesting for data. So, so that was the generic video streaming workflow. To make it live, we need to we need to do a do a few modifications. One is we just make the broadcaster push have informations have packets into the stream into the swarm so that as the new segments become available, the broadcaster just tells the tells the swarm that it has these these packets and the swarm will figure out how to relay it around. And also when during a handshake you can establish a discard window so that you don't have to keep all the video around through the whole live stream.

And instead of now instead of having one Merkle root, we would have a live injector which just means we have a transient Merkle root. And to do the and to ensure that the video that we relay around is still correct and has integrity, we use the Monroe hash which is just a fancy word for saying it's a Merkle root for the new for the new chunks instead of for the entire entire video. So that's basically how the video relaying network protocol works to get around some of the some of the constraints from a tree structure. But what we really want to do here, right, is to incentivize the video delivery. And and I think the Swarm team published this paper called Swarm Swarm Swindle many years ago and they recently generalized that to create a good good framework around this.

And this is a very much open research area and we're very excited to to continue do work in this area. So to to kind of summarize what we talked about, well, the goal here is to teach Web3 to do all the video uh video delivery um video streaming stuff that the traditional web is able to do, right? So, that means adding transcode adding transcoding features through the Livepeer network, using Swarm or IPFS to do the storage for both the the protocol verification process and for the for storing the actual video for a later playback. Um and also, we talked about a few different CDN approaches to deliver the video. Uh and now, since the CDN uh area is very much an open um a open question and a open research area, uh we have a fallback mechanism to um to always go back to a to a centralized CDN.

Um so, so that we can have smooth playback experience right away. Uh the project has been uh in the works for a little over a year. Um we published a white paper early during the year and since then, we've been working on the testnet. Uh the testnet it just went live uh a little less than a month ago and the demos that I just showed uh is running on the testnet right now. Uh and our next goal is to um launch on the mainnet and in production uh either Q4 this year or early next year.

So, this is very exciting, right? Because live streaming in a decentralized context is happening like it's like imminent. Uh and and there are a couple things that you that that we can do to for for everyone to get involved. Uh the easiest thing is to run a node and join a testnet so that you can see how live streaming works in the in a decentralized world. Uh another thing you can do is to build a video-based app, like some of the ideas that we talked about or uh you know, any ideas that you have um that we haven't thought about.

Um and another thing is, if you're interested in P2P video delivery and you want to help us make this a reality, uh come uh out to us. Uh Livepeer works as an open source project, and we work with people all over the globe, and frankly, that's that's part of life that's one of the best things about working in this space is you you're able to work with all kinds of talented people from all kinds of backgrounds. So, uh we're reachable through uh through our Gitter channel. Uh we are on Twitter, we're on GitHub, or you can just send me a message. Um I'm happy to I'm happy to help you um with anything that you need.

So, that is it. I'm Eric, and we are Livepeer, and I think we have 2 minutes to for any questions. So, you talked about um signing transcoded packets um after like for every single packet, is there kind of an sounds like that would be there would be some overhead related to having to sign every single one of those. Is that an issue? Yeah, um so, the the signing the packets would have to happen anyways in a decentralized world, right?

In a peer-to-peer network um where you don't control the peers, uh you are forced to do that. Um the CPU the the CPU overhead is is not that much. Of course, it's better it's better to not sign it and save the CPU cycle, but the security that you get is good because you can scale the network and and overall get a cheaper solution. Yeah. You mentioned that uh there are many different encoding decoding techs, some of which are proprietary.

Uh do you suppose that might be an issue for like distribution on Swarm or something? Yeah, that's an interesting question. Um I think uh the the proprietary codecs uh this is very much um on the application developer to to to answer this question, right? Like um the the even the proprietary even the proprietary codecs are in in these open source softwares. Uh and if you are working if you are a centralized company and you're using these proprietary codecs, uh and it's up to you to have to pay the license fee.

Uh otherwise, the lawyers are going to go after you. Yeah. Yeah. Or you can just use VP9 and it's open source. So you um excuse me.

You mentioned that um the PPSSP protocol, wait, the PPSSP protocol uh has has packets of like 124 bytes. Uh packets of 100 sorry, 1,024 bytes. Yeah, 1,024, yeah. Um have you done any benchmarking on like overhead cost and like the whole system in terms of like where do you foresee the main overheads to come from and how does that compare to like a centralized system? Yeah, that's a good question.

Um there's there hasn't been a lot of um products built around this and as I said, this is a very much uh an an an open research area, but what I can tell you is that um PPSSP uh overcomes the problem of slow bandwidth upstream and that's enough of a benefit to um for for for the peer-to-peer use case. Oh, cool. Uh I'm going to be outside, so uh come and find me. Thank you.