Nile.js – A Peer-to-Peer Live Video Streaming Library built on WebTorrent | Hacker News Reader

Nile.js – A Peer-to-Peer Live Video Streaming Library built on WebTorrent

hackernoon.com

114 pointsthmslee20 comments

Open articleView on HN

Does someone have a working instance of this where we could test-run it?

came here for the same question

they have nice hover buttons but they seem to have no effect here.

PS: const nileServer = require('nile.js/nileServer')(server); seriously?

See also https://www.peer5.com/faq

And the sticker shock with the pricing https://www.peer5.com/pricing

"Only data delivered via P2P counts against your video CDN plan"

lol, this is ridiculous. So they basically charge me for the bandwidth of my users?! :D

As well as: https://streamroot.io/demo

There is also Phenix: https://phenixp2p.com/#technology

I am not affiliated with these guys in any way.

So one thing I've noticed with peer5 (and I assume their competitors do this as well) is they seem to charge for the bandwidth supplied by the peers. There is/was a plugin for clappr.io that provided p2p HLS playback and now there's Nile.js. So I don't really get what the value prop for peer5 and its competitors is?

Hi, I'm the co-founder of Peer5. The difference is that Peer5 is a hosted solution with coordination and analytics. It's an "enterprise" product with support and everything a large media company would need.

http://www.libtorrent.org/dht_store.html could be of interest for this project.

It's a proposal for an extension the bittorrent to store arbitrary data.

Through this it could be possible made possible/easier to create a livestream.

Sadly it's (afaik) only a proposal, but I think it's a very interesting one.

Also so good information on it http://www.bittorrent.org/beps/bep_0044.html

It is not just a proposal. In fact the two most common bittorrent implementations, uTorrent and libtorrent, added support for it for a few years ago. The proposal was adopted as BEP 44 which you can find at http://bittorrent.org/beps/bep_0044.html .

Not sure I understand the point of this. Is it to lessen loads from the distributing servers or the actual broadcaster? I can't see how this would help a broadcaster at least.

Network costs I am assuming. Wonder how bad the latency is going be though?

It doesn't really matter all that much if some viewers of a live stream are ~30-60s behind others. Heck, ESPN's online offerings can have 2-3minutes of lag. As long as this isn't used for real-time chat / video conferencing, there's really no need for super low latency

Well real-time is often not a requirement like radio talk show there's often a 7-10 seconds delay before next audio is emitted (usually to beep on inapprioiate lanuage) But being able to have most viewers watching the same frame almost simultaneously would be awesome.

But what about spot betting during a sports game?

It uses HLS or DASH so the latency should be no worse than through a CDN since those systems are already quite delayed compared to RTSP or some other more immediate protocol

Is this similar to RTMFP / P2P Multicast?

(which adobe flash supported since ~2008 -_-, it's great to see some opensource competition in the "HTML5" field)

No. RTMFP is more akin to WebRTC - it provides a way to transport video and data in a P2P manner, but not any of the higher levels needed to behave like a CDN.

Reply on news.ycombinator.com