Hey, founder of the p2p service described in the article here (www.streamroot.io)
This is exactly what we are doing :) We have have a hybrid p2p model that fetches video segments from others peers as long as it can, and switches back to CDN on urgency cases. And our tracker uses geoIp data, ISP and some network topology elements to connect the best candidates together
Hey, what you describe what clearly the case with old peer-to-peer systems, but things changed a lot.
With webRTC and ICE/STUN, the p2p connection takes less than 5s on average and goes through NATs in 95% of the cases.
As for the bandwidht issues, it is not a problem as the solution is hybrid and doen't need every peer to be a full seeder.
If you don't beleive me you can always try by yourself, with a Chrome/Firefox/Opera browser : http://demo.streamroot.io
one connection takes 5s, but using a stun server means you don't understand peer locality. This means you as the service owner has to map the network to find correct peer placement.
How do you asses the bandwidth available now, and in the future? is the bandwidth between two peers inside and ISP greater than two peers from different ISPs. How do you manage peer re-routing when one disappears. What happens if more than one peer disappears?
webrtc is designed for 1 to 1 mapping, and not 1 to many paid for content delivery. Sure you can do it, but your users arn't going to be happy you chose to engineer your way out of a bad idea. (You don't want buffering during an expensive movie/tv/sports game)
The main difference with the solution the article describes and Popcorn time is that the former can be used by the online broadcaster for their own videos and integrates seamlessly in their webpage, whereas for Popcorn time you need to install the soft, and can only download torrents.
I am the founder of the company providing the pluginless peer-to-peer video streaming service the article is talking about (www.streamroot.io).
>-- residential/mobile internet service has asymmetric upload/download speeds.
Indeed, but it is not so much of an issue: 1. the average video stream bitrate today is 1.5 Mbps, which is closer to the upstream limits than the downstream limits. 2. Our solution is hybrid, so if you can't get all the data from other peers, you just get the rest from the CDN, so even if someone has a 100 kbps uplink, he still contributes to the swarm. 3. With fiber there are more and more people having 100+ Mbps uplink, and these people can serve dozens of others peers, and this balances the asymmetry partially.
>-- ISPs are suspicious of heavy uploads originating from residential homes and could be flagged as "servers" in violation of ISP's TOS or reclassified as "business" thereby increasing the billing amount.
This must be different depending your country and ISP, but the upside comparing to some full P2P service like Bittorent is that you share video segments only while you are on the streamer webpage (as soon as you close your tab the p2p stops), and also all the communications are encrypted with DTLS provided by WebRTC, so it is not so easy for ISPs to figure out what is exchanged.
And finally, we actually help the ISPs by connecting the peers that use the same ISPs, and are on the same sub-networks first, so they have less peering issues.
>-- too much latency for live mega events (World Cup, etc) because of asymmetry mentioned above. (Your neighbor tweets that Spain scored the winning goal before your P2P stream received the last packets showing that it happened.) Latency for bittorrent is ok, but for live megaevents, no.
I think that this where our technology really differentiates with the old peer-to-peer systems : we don't add any additional latency to the stream, but just use the latency already generated by HTTP streaming protocols like HLS or MPEG-DASH. So with or without our system, you will still have a 20-30 seconds latency with the encoder, as it is already the case with all the professional live streams like the ones used during Superbowl or the World Cup.
As for CDNs cooperating to broadcast a live stream, it is not really the spirit of the CDN market right now, instead what happens is that the Broadcaster can contract one or several backup CDNs for their biggest events, and use them in case the primary CDNs breaks down. This is what happened for the Superbowl stream : NBC had Akamai as their primary CDN, and Level3 as a backup. In the end they didn't have to use the backup, but still paid both CDNs for the event !
Hi, my company operates in the same area (viblast.com)
I would like to add on Rodi's answers above:
- Yes, for mobile (data-plan based) connections P2P puts a heavy load, but WiFi-connected smartphones/tablets are not a problem to serve.
- Latency is not the issue being discussed here (from the Twitter example above), even Twitch latency is no less than 12 seconds: http://www.reddit.com/r/Twitch/comments/2j8b4c/has_the_strea... It seems that you are talking about asynchronous viewing, and that is something that can be made to work better so viewers at least watch with the same delay.
- The real value of P2P streaming is mostly seen by Broadcasters who wish to send their online linear signals at high and uninterrupted quality, but low cost as their traditional model.
We do p2p communications. A big issue is network interruption. Somebody walks around with a laptop or mobile device, roams, link broken and a gap in your experience as it scrambles to reroute. Or somebody else in the house starts to use the network, and your negotiated link drops available bandwidth/congests.
If its free or just for fun, then yes you can go this route. But people paying for an experience are, in our experience, intolerant of any interrupt or quality drop.
Networks interruptions happen a lot, this is why our system is hybrid: if you didn't have time to get the segment from the peer-to-peer, you dynamically switch back to the CDN to get the missing parts of your video segments, so in practice the quality can't be worse than what you have with the CDN only.
I have to wonder at the claim of no added latency then? By the time the peer fails, and the CDN is queried and responds, the replay stream would have passed the point where it needed that frame. Unless the reassembly/replay engine is running substantially behind realtime.
Streamroot | Fulltime | Paris | pluginless Peer to Peer assisted video streaming technology. www.streamroot.io
We are a French startup planning to revolutionize the world of online video delivery. We have participated in Le Camping Paris and Techstars Boston accelerating programs, and are growing very quickly !
We are looking for :
- an experimented Scalability Engineer who will help us scale our trackers to sustain millions of concurrent connections.
- A Media Player engineer to build and adapt our p2p module to all the major web video players, on desktop, set top boxes and mobile.
