Bringing Peer-to-Peer Streaming to the World. • Hacker News Board

Re: Bringing Peer-to-Peer Streaming to the World.

#31

Post by jsonified » Fri, Feb 28, 2014, 12:47 AM UTC

DanBlake wrote: post #30

jsonified wrote: post #28

Earlier quoted context omitted.

Please read the PPSP protocol more carefully, your statements are invalid. #1 if Jose is streaming to Sue, there's no middle server here. PPSP doesn't mandate a "central server", and I hope on the swirl website I can make this use case clear too. I'd love us to be able to stream from our devices to friends etc and not need to store everything on youtube or dropbox or some other indexed/sliced/diced/resold for profit…

I feel like you are avoiding the glaring problems with P2P streaming for live video. With that, for your first point, let me give you a scenario and please explain Joe is on his laptop and has 5mb/s upstream connection. He wants to stream a 1080p video at 1mb/s to 10,000 people. In the case above, without a relay server (as you suggest), How delayed will the data be for viewer 10,001, assuming every peer has the same…

Hi Dan,

good points -- but they're not the scenarios I'm referring to, and they're extremes around a perfectly usable for 90% of use cases & users.

If Joe wants to stream to Barney and a handful of people then his laptop is fine. If he want to push 10k, then obviously he'll need some help, the maths doesn't stack up any other way. Your original example (and my response to it) mentioned a pair of users with a need for low latency. 10k is obviously going to be different, and we both know that. Let's not be disingenuous here.

PPSP-TP (the tracker protocol) doesn't force Joe's laptop to be the seeder for the entire 10k, it can be managed as discrete swarms, and the tracker protocol can segment or insulate the seeding peer from a larger community if required. But as you rightly point out in this case, help is needed. There's a limit on how much can be streamed based simply on packet size & transfer, even though PPSP is much more efficient than existing protocols due to the way it handles hash management (merkle trees and munro hashes) bandwidth is bandwidth, (latency & asymmetric aside).

Again, PPSP is a transport protocol, not just a live video stream. There are applications even in areas where bandwidth is 100Kb/sc or worse.

If you're really interested in this, please read up on the protocol and contribute some much-needed real world feedback to its development. The next IETF session is, as always, publically accessible, https://datatracker.ietf.org/meeting/89/agenda/ppsp/ next Tuesday 16h10 GMT. It would be great to have you join us!

Re: Bringing Peer-to-Peer Streaming to the World.

#32

Post by teraflop » Fri, Feb 28, 2014, 1:19 AM UTC

DanBlake wrote: post #25

_zen wrote: post #19

Please please please let this lead to a P2P version of Twitch.tv. It would be amazing if gaming broadcasters could stream directly to their subscribers/followers, with very little latency (not the 30 second video lag Twitch adds). Broadcaster monetizing could be tricky, but definitely doable.

The 30 seconds is not because twitch sucks. They do encoding/decoding/sampling And honestly, if you were streaming a 1080p video over p2p, I see no physical way that it would be below a 30s delay if there was 1k+ people watching it. You are limited by peers outbound bandwidth and for most in the US that is going to be sub 5MB/s. With that in mind, you can really only have a maximum of 5 or less streams per user. That…

If each peer can retransmit to 5 other users, then a simple tree-structured fanout gets you to more than 1000 users with only 5 hops of delay.

Obviously in practice you wouldn't get a perfectly balanced tree, but I don't see where your "50+ users" is coming from.

Re: Bringing Peer-to-Peer Streaming to the World.

#33

Post by nitrogen » Fri, Feb 28, 2014, 1:31 AM UTC

DanBlake wrote: post #27

True P2P streaming is more trouble than its worth. Take it from a guy who streams petabytes a month and has looked into it more times than most. P2P has 2 main advantages, both of which are voided by this implementation: 1: Better latency. If Joe talks directly to Sue, that is the fastest connection possible, as opposed to Joe -> Server -> Sue 2: The host saves on bandwidth costs Now, point #1 is moot because this ne…

Things like transcoding for different sizes / mobile as well as DVR style seeking/recording.

Ogg Vorbis was designed with bitrate shedding in mind (drop bits from packets to get a lower bitrate), though I'm not aware of it being used. Are there any bitrate shedding video codecs? If not, one could be developed that allows low-bandwidth clients to request only a percentage of the blocks of a stream and decode a low-resolution/low-quality image therefrom.

Re: Bringing Peer-to-Peer Streaming to the World.

#34

Post by wmf » Fri, Feb 28, 2014, 1:36 AM UTC

nitrogen wrote: post #33

DanBlake wrote: post #27

True P2P streaming is more trouble than its worth. Take it from a guy who streams petabytes a month and has looked into it more times than most. P2P has 2 main advantages, both of which are voided by this implementation: 1: Better latency. If Joe talks directly to Sue, that is the fastest connection possible, as opposed to Joe -> Server -> Sue 2: The host saves on bandwidth costs Now, point #1 is moot because this ne…

Things like transcoding for different sizes / mobile as well as DVR style seeking/recording. Ogg Vorbis was designed with bitrate shedding in mind (drop bits from packets to get a lower bitrate), though I'm not aware of it being used. Are there any bitrate shedding video codecs? If not, one could be developed that allows low-bandwidth clients to request only a percentage of the blocks of a stream and decode a low-res…

There's Scalable Video Coding.

Re: Bringing Peer-to-Peer Streaming to the World.

#35

Post by wmf » Fri, Feb 28, 2014, 1:44 AM UTC

jsonified wrote: post #28

DanBlake wrote: post #27

True P2P streaming is more trouble than its worth. Take it from a guy who streams petabytes a month and has looked into it more times than most. P2P has 2 main advantages, both of which are voided by this implementation: 1: Better latency. If Joe talks directly to Sue, that is the fastest connection possible, as opposed to Joe -> Server -> Sue 2: The host saves on bandwidth costs Now, point #1 is moot because this ne…

Please read the PPSP protocol more carefully, your statements are invalid. #1 if Jose is streaming to Sue, there's no middle server here. PPSP doesn't mandate a "central server", and I hope on the swirl website I can make this use case clear too. I'd love us to be able to stream from our devices to friends etc and not need to store everything on youtube or dropbox or some other indexed/sliced/diced/resold for profit…

For #2 I'm not sure you understood DanBlake's point. Datacenter bandwidth is cheap and reliable while last-mile bandwidth is expensive and unreliable; that's why centralized services almost completely replaced P2P over the last decade. I'm willing to use a slightly more expensive system in exchange for autonomy and privacy, but that argument hasn't been well articulated here.

Re: Bringing Peer-to-Peer Streaming to the World.

#36

Post by wmf » Fri, Feb 28, 2014, 1:47 AM UTC

DanBlake wrote: post #25

_zen wrote: post #19

Please please please let this lead to a P2P version of Twitch.tv. It would be amazing if gaming broadcasters could stream directly to their subscribers/followers, with very little latency (not the 30 second video lag Twitch adds). Broadcaster monetizing could be tricky, but definitely doable.

The 30 seconds is not because twitch sucks. They do encoding/decoding/sampling And honestly, if you were streaming a 1080p video over p2p, I see no physical way that it would be below a 30s delay if there was 1k+ people watching it. You are limited by peers outbound bandwidth and for most in the US that is going to be sub 5MB/s. With that in mind, you can really only have a maximum of 5 or less streams per user. That…

Can you explain why delay matters? AFAIK TV usually has over 1 minute of delay for live events.

Re: Bringing Peer-to-Peer Streaming to the World.

#37

Post by na_da » Fri, Feb 28, 2014, 1:47 AM UTC

jsonified wrote: post #31

DanBlake wrote: post #30

Earlier quoted context omitted.

I feel like you are avoiding the glaring problems with P2P streaming for live video. With that, for your first point, let me give you a scenario and please explain Joe is on his laptop and has 5mb/s upstream connection. He wants to stream a 1080p video at 1mb/s to 10,000 people. In the case above, without a relay server (as you suggest), How delayed will the data be for viewer 10,001, assuming every peer has the same…

Hi Dan, good points -- but they're not the scenarios I'm referring to, and they're extremes around a perfectly usable for 90% of use cases & users. If Joe wants to stream to Barney and a handful of people then his laptop is fine. If he want to push 10k, then obviously he'll need some help, the maths doesn't stack up any other way. Your original example (and my response to it) mentioned a pair of users with a need for…

Again, PPSP is a transport protocol, not just a live video stream. There are applications even in areas where bandwidth is 100Kb/sc or worse.

So PPSP is not just for video streaming. What would other possible applications be?

Re: Bringing Peer-to-Peer Streaming to the World.

#38

Post by e12e » Fri, Feb 28, 2014, 1:58 AM UTC

DanBlake wrote: post #25

_zen wrote: post #19

Please please please let this lead to a P2P version of Twitch.tv. It would be amazing if gaming broadcasters could stream directly to their subscribers/followers, with very little latency (not the 30 second video lag Twitch adds). Broadcaster monetizing could be tricky, but definitely doable.

The 30 seconds is not because twitch sucks. They do encoding/decoding/sampling And honestly, if you were streaming a 1080p video over p2p, I see no physical way that it would be below a 30s delay if there was 1k+ people watching it. You are limited by peers outbound bandwidth and for most in the US that is going to be sub 5MB/s. With that in mind, you can really only have a maximum of 5 or less streams per user. That…

So, lets assume every viewer can broadcast to three others, so the first one reaches 3 that reaches 9 etc. You'd be "behind" 7 others for "up to" 2187 viewers. This is assuming no "super hubs" in between. Or am I missing something? Even if every peer on average is only able to reach two "new" peers, that's still just 10 hops for 1024 users...?

Re: Bringing Peer-to-Peer Streaming to the World.

#39

Post by blantonl » Fri, Feb 28, 2014, 2:17 AM UTC

panabee wrote: post #20

_zen wrote: post #19

Please please please let this lead to a P2P version of Twitch.tv. It would be amazing if gaming broadcasters could stream directly to their subscribers/followers, with very little latency (not the 30 second video lag Twitch adds). Broadcaster monetizing could be tricky, but definitely doable.

how would you monetize?

In this case, this is like asking how you would monetize TCP. This specification is a transport protocol and could apply to multiple use cases, not including video.

Re: Bringing Peer-to-Peer Streaming to the World.

#40

Post by jamii » Fri, Feb 28, 2014, 2:19 AM UTC

I had some fun implementing binmaps a while ago - http://scattered-thoughts.net/blog/2012/01/03/binmaps-compre...

I originally encountered them in http://libswift.org/ which was the predecessor to http://datatracker.ietf.org/doc/draft-ietf-ppsp-peer-protoco.... Both are very elegant simplifications of bittorrent and the IETF draft is pretty readable.