Show HN: A JavaScript SDK to reduce video streaming costs(api.peervadoo.com)
api.peervadoo.com
Show HN: A JavaScript SDK to reduce video streaming costs
https://api.peervadoo.com/test
51 comments
> when 2 people are watching the same video a WebRTC data channel is opened for streaming video content
Is this enabled by default in modern browsers?
Is this enabled by default in modern browsers?
Yes
Flag it then.
Yes that's a pretty interesting point.
Datachannels by themselves are secure since all videoconferencing software use the same technology to connect users and there are no visible security concerns.
Also we make sure the data being transferred is not malicious by having checks for data consistency
Datachannels by themselves are secure since all videoconferencing software use the same technology to connect users and there are no visible security concerns.
Also we make sure the data being transferred is not malicious by having checks for data consistency
That's a bad comparison, since they're fundamentally different applications.
Video conferencing is multicast, video streaming is broadcast. I can essentially opt in to opening a data channel to a peer because its core to the technology and feature set. I don't expect opening a link to a video exposes me to another random person or computer watching the same video.
Another fundamental difference is that video conferences are temporary. Hosted videos are persistent. I can just have a machine hang out watching a video on loop and sniff peers coming in, quite reliably if the video is popular.
Another point I'd bring up is that video conferencing apps' threat model is essentially around unauthorized access. It's dealt with by obscuring the video stream's link, making it temporary, and securing it behind an authorization protocol (on Zoom you have login, password, and manual admitting by the host, for example). That doesn't really fit if you're hosting videos to be persistent.
Video conferencing is multicast, video streaming is broadcast. I can essentially opt in to opening a data channel to a peer because its core to the technology and feature set. I don't expect opening a link to a video exposes me to another random person or computer watching the same video.
Another fundamental difference is that video conferences are temporary. Hosted videos are persistent. I can just have a machine hang out watching a video on loop and sniff peers coming in, quite reliably if the video is popular.
Another point I'd bring up is that video conferencing apps' threat model is essentially around unauthorized access. It's dealt with by obscuring the video stream's link, making it temporary, and securing it behind an authorization protocol (on Zoom you have login, password, and manual admitting by the host, for example). That doesn't really fit if you're hosting videos to be persistent.
Huh? All WebRTC is unicast.
Well first thing even in the case of video streaming the url changes with time with the current security measures and hence valid only for certain time
My second point w.r.t comparison is regarding the security of data channels of webrtc which is a pretty secure channel which is used in video conferencing as well but there is no known security loopholes in that and thus no concern
My second point w.r.t comparison is regarding the security of data channels of webrtc which is a pretty secure channel which is used in video conferencing as well but there is no known security loopholes in that and thus no concern
There's been an explosion in P2P CDN space ever since u/feross' PeerCDN hit the scene [0]. At least one was funded by YC [1]. Some of the others are opensource [2][3].
Some day webtorrent itself would be capable of streaming large files [4]. And of course, there's peertube [5].
[0] https://gigaom.com/2013/03/28/peercdn-p2p-cdn/
[1] https://www.ycombinator.com/companies/1559
[2] https://p2p.cdnbye.com/en/
[3] https://p2pcdn.io/
[4] https://github.com/webtorrent/webtorrent/issues/86
[5] https://en.wikipedia.org/wiki/PeerTube
Some day webtorrent itself would be capable of streaming large files [4]. And of course, there's peertube [5].
[0] https://gigaom.com/2013/03/28/peercdn-p2p-cdn/
[1] https://www.ycombinator.com/companies/1559
[2] https://p2p.cdnbye.com/en/
[3] https://p2pcdn.io/
[4] https://github.com/webtorrent/webtorrent/issues/86
[5] https://en.wikipedia.org/wiki/PeerTube
[2] is not open-source as well. It is a paid service.
They've seemed opened up a bunch of things if not everything: https://github.com/cdnbye
Interestingly, your GitHub table on compatibility matches exactly with theirs. I guess both of you are hitting into the same limitations.
Interestingly, your GitHub table on compatibility matches exactly with theirs. I guess both of you are hitting into the same limitations.
The internal technology is webrtc which has issues with Safari
As a user, I block and personally hate those traffic leeches. They don't reduce streaming costs, they just push them onto unsuspecting users. I'll be billed for the additional upload by my ISP if I open their video on my phone. Plus the idea isn't even new. There have been streaming video BitTorrent clients implemented in Javascript for some years already.
As an admin, if anyone in my wifi opens a page using this technology, their increased upload traffic will slow down or potentially even block more important things like off-site backups.
That's why companies and universities tend to block p2p "CDN"s. Or at the very least, they heavily throttle it, which means your watching experience suffers.
As an admin, if anyone in my wifi opens a page using this technology, their increased upload traffic will slow down or potentially even block more important things like off-site backups.
That's why companies and universities tend to block p2p "CDN"s. Or at the very least, they heavily throttle it, which means your watching experience suffers.
This is not true. As a matter of fact many companies enable p2p cdn via eCDN to reduce network bottlenecks
Many companies push p2p CDNs for their online software products, on the premise that load on their edge servers/centralized CDN providers will be reduced if their users get data from peers.
However, I believe GP was referring to companies blocking such CDNs on their internal networks (used by their employees). That corroborates my experience and that of my colleagues (healthcare, education, defense).
However, I believe GP was referring to companies blocking such CDNs on their internal networks (used by their employees). That corroborates my experience and that of my colleagues (healthcare, education, defense).
Yes, I was talking about internal networks. And I have since remembered the name of the service that stumbled over this: veoh.com
They were quickly blocked for using P2P in pretty much every company firewall. I remember sending a funny video link around, but nobody could watch it in their lunch break. Also, so many regular users reported their "Giraffic Video Accelerator" for suspicious behavior (high CPU usage, high network usage) that antivirus companies started flagging it as a Trojan.
Then, Veoh went bankrupt. And eventually, they were acquired.
They were quickly blocked for using P2P in pretty much every company firewall. I remember sending a funny video link around, but nobody could watch it in their lunch break. Also, so many regular users reported their "Giraffic Video Accelerator" for suspicious behavior (high CPU usage, high network usage) that antivirus companies started flagging it as a Trojan.
Then, Veoh went bankrupt. And eventually, they were acquired.
It's an interesting idea, but I don't think it really works at scale. Reminds me of Spotify starting out with peer to peer and then abandoning it. Especially since your users won't accept the costs being shifted to them and their streaming experience being most likely negatively affected if you're apparently a big player. Not to mention the myriad of technical hurdles you'll run into once you start to try to use this world wide. Perhaps if you're only streaming from and to free spirited people who understand what's going on and want to share the burden.
Hey thanks for bringing this up. The user experience won't take a hit since video streaming especially live streaming has a lot of issues with cdn and a hybrid architecture of cdn+p2p eases the traffic and reduces the bottlenecks in the network.
Similarly for people accessing content from remote locations always face a lot of issues since the cdn centers stay away in metro cities. Their experience would be enhanced too since they can now fetch the content from a nearby peer than a far-away cdn
Users who wish to be part of the network for better experience streaming the content can be part of the network. Also there are options available to enable/disable p2p for 4g/wifi/based on location and various other constraints to take care of user experience.
Similarly for people accessing content from remote locations always face a lot of issues since the cdn centers stay away in metro cities. Their experience would be enhanced too since they can now fetch the content from a nearby peer than a far-away cdn
Users who wish to be part of the network for better experience streaming the content can be part of the network. Also there are options available to enable/disable p2p for 4g/wifi/based on location and various other constraints to take care of user experience.
> Similarly for people accessing content from remote locations always face a lot of issues since the cdn centers stay away in metro cities. Their experience would be enhanced too since they can now fetch the content from a nearby peer than a far-away cdn
This is an interesting idea. If this gets widespread-enough adoption, and if non-metro folks can, on average, find a nearby peer for $whatever they're looking for (and those are very big "if"s), I still imagine some problems might crop up:
Determining "distance" is quite tricky, and the trickiness goes up substantially the further onto rural/less normal latency distribution networks/ISPs you get--and that's just in the first world. If latency is the main signal used to inform distance, you could end up inflicting a pretty punishing upload-bandwidth cost on users/ISPs because of, for example, a fortuitous peering agreement upstream.
There may also be a significant penalty paid for "medium distance" non-hub-routed peers: situations in which the presence of many uploaders congest the last-mile/backhaul infrastructure of small-scale providers that are least capable of managing the unexpected surge in consumption (least capable as in: most congestion-prone infrastructure and fewest technical solutions on hand to mitigate unexpected long-term congestion).
And in places where small-scale providers don't control much of the market and mobile networks are the main bandwidth providers, expect a swift no-warning traffic block. There are ways to circumvent those, but they get expensive (in engineering time, user experience, and user bandwidth) fast.
This is an interesting idea. If this gets widespread-enough adoption, and if non-metro folks can, on average, find a nearby peer for $whatever they're looking for (and those are very big "if"s), I still imagine some problems might crop up:
Determining "distance" is quite tricky, and the trickiness goes up substantially the further onto rural/less normal latency distribution networks/ISPs you get--and that's just in the first world. If latency is the main signal used to inform distance, you could end up inflicting a pretty punishing upload-bandwidth cost on users/ISPs because of, for example, a fortuitous peering agreement upstream.
There may also be a significant penalty paid for "medium distance" non-hub-routed peers: situations in which the presence of many uploaders congest the last-mile/backhaul infrastructure of small-scale providers that are least capable of managing the unexpected surge in consumption (least capable as in: most congestion-prone infrastructure and fewest technical solutions on hand to mitigate unexpected long-term congestion).
And in places where small-scale providers don't control much of the market and mobile networks are the main bandwidth providers, expect a swift no-warning traffic block. There are ways to circumvent those, but they get expensive (in engineering time, user experience, and user bandwidth) fast.
The users are paired based on metrics like location/network speed etc. Also users in same ISP are paired
And it is a swarm based network which by default will never overload a single peer and shares the bandwidth across all the peers in general
And it is a swarm based network which by default will never overload a single peer and shares the bandwidth across all the peers in general
I remember when Skype was trying out a similar feature for P2P video, where user devices would be used to help forward other connections and calls. My phone left a scorch mark on my (admittedly cheap) countertop because the battery was running so hot.
As a user, battery life and bandwidth limits are super important to me, and this seems like a thing that will eat through both.
As a user, battery life and bandwidth limits are super important to me, and this seems like a thing that will eat through both.
Ideally the only addition is few network requests which should not consume a lot of battery. In our experiments we have seen not much of a difference in consumption of battery
With regards to bandwidth there are options to limit upload and disable it for 4g/for certain location
With regards to bandwidth there are options to limit upload and disable it for 4g/for certain location
I’m sorry maybe I misunderstand the tech but how does a user have the choice when a site pushes this on them? The average user won’t know what peer to peer is or understand that they’re sharing their bandwidth with strangers.
It is up-to the site to enable/disbale p2p. Incase the user wants to disable himself/herself they can do from browser.
No comment on the actual tech (yet), just pointing out you've got a few different numbers floating around on different pages.
The title here mentions reducing costs by 90%, but on the homepage you list reducing cost by 50% (twice), reducing bandwidth by 99%, and offloading 90% of bandwidth. On the github page it lists reducing costs by 30%
From a first-read perspective those are vastly different numbers (30-99%), for what all sound like the same thing (reducing bandwidth by 99% sounds like it should reduce my costs by 99%).
Might want to be more specific (or pick a single number).
The title here mentions reducing costs by 90%, but on the homepage you list reducing cost by 50% (twice), reducing bandwidth by 99%, and offloading 90% of bandwidth. On the github page it lists reducing costs by 30%
From a first-read perspective those are vastly different numbers (30-99%), for what all sound like the same thing (reducing bandwidth by 99% sounds like it should reduce my costs by 99%).
Might want to be more specific (or pick a single number).
Hey thanks for pointing out. We should probably be more specific w.r.t numbers. The bandwidth savings depend on the number of concurrent users.
As more users watch a single stream concurrently the savings increase proportionately. We have seen max bandwidth savings of up-to 90% in live streaming scenario with 100 users concurrently watching the stream.
As more users watch a single stream concurrently the savings increase proportionately. We have seen max bandwidth savings of up-to 90% in live streaming scenario with 100 users concurrently watching the stream.
Hi everyone
I am working on a web sdk which can reduce video streaming costs of CDN by up-to 90% using a hybrid decentralized load sharing technology. I have opened it up for beta-access for developers to try it out. Looking for feedback w.r.t the technology and any features you would want to have.
A web demo is available here https://api.peervadoo.com/test . Click on Add new peer to see the tech in action
Sdk link :- https://github.com/vadootvpeer/sdk-javascript
Happy to answer any queries
I am working on a web sdk which can reduce video streaming costs of CDN by up-to 90% using a hybrid decentralized load sharing technology. I have opened it up for beta-access for developers to try it out. Looking for feedback w.r.t the technology and any features you would want to have.
A web demo is available here https://api.peervadoo.com/test . Click on Add new peer to see the tech in action
Sdk link :- https://github.com/vadootvpeer/sdk-javascript
Happy to answer any queries
Is this another WebRTC thing? How do I explain to my users that pay $20-30 per 1GB of data when it starts automatically "contributing" to reduce my costs?
There are options in dashboard to disable the service for certain sets of users say users on 4g and enable it only for users on wifi or say enable it only for free customers and disable it for subscribed customers.
LTE routers with GB limits. You are connected via Wi-Fi or Ethernet cable.
If I've found out some website is using my upload bandwidth without my consent I would just quit using it.
It's a dick move to utilize user's resources.
If I've found out some website is using my upload bandwidth without my consent I would just quit using it.
It's a dick move to utilize user's resources.
Pretty much this, I've noticed quite an uptick of traffic since WFHdemic started from mobile networks presenting non-mobile user agents. If you're on a typical 5G hotspot and suddenly start mass uploading, congrats, you've either run up a bill horrendously within minutes or run out of data for the month.
In addition, there are many countries (like India for example) where wired internet is not the norm and instead 3G/4G/LTE sticks or hotspots are.
Not to mention data caps are a thing on wired internet anyway, like Comcast in US.
In addition, there are many countries (like India for example) where wired internet is not the norm and instead 3G/4G/LTE sticks or hotspots are.
Not to mention data caps are a thing on wired internet anyway, like Comcast in US.
There seem to be an option in Windows that let you specify you are on a metered connection. Probably one could check if the "saveData" option is selected to disable p2p.
As cloudy as Windows is, it doesn't seem to automatically detect/set that flag (and then you have the problem where people don't want to turn on datasave mode - like how I don't want iOS to only download updates over WiFi because I don't have any, I just want it to download it all over LTE), and getting all your website users to "opt in" to setting it is kind of an exercise in frustration to not automatically be using their bandwidth
Who would this save money if the videos are hosted in a p2p platform? We need to pay for CDN + P2P network, right? This assumes people are watching the same video at the same time but the moment they close the browser tab, you would fallback to the CDN.
Are you using WebRTC with a torrent like network (ex:Filecoin)? I can imagine people renting a percentage of their existing home servers.
Are you using WebRTC with a torrent like network (ex:Filecoin)? I can imagine people renting a percentage of their existing home servers.
It would save money for the streaming platforms since the CDN costs are reduced now and the load is distributed across peers.
See also PeerTube, which is Free and Open Source software, discussed 10 days ago.
https://news.ycombinator.com/item?id=24856243
https://joinpeertube.org/
https://news.ycombinator.com/item?id=24856243
https://joinpeertube.org/
Putting the burden on the user for significantly higher $/gb. Doesn't just shift the total cost, it actually increased it quite a bit.
It's be nice if webrtc was somewhat more opt in.
It's be nice if webrtc was somewhat more opt in.
It is up-to the site owner to inform the user to opt-in for a better streaming experience.
That is sadly a bad idea. Eventually every site is incentivized to do what benefits them. mark my words, browsers will eventually make this experience opt in, not the site. See notification popups etc. Browser controls them.
Otherwise, I think the project has good potential. I have known peercdn and we torrent almost since the inception, and I cheer the possibility of peer to peer projects from browser without a special client.
I was just looking into how hard it would be to build a Twitch clone, given that Twitch is declaring war on it's viewers by forcing unblockable pre-roll ads.
Many people including me have just stopped watching Twitch because of the new ads, but I'd love to help build a movement towards a no-advertising-ever streaming site.
If we can bring the cost of streaming the video content down I think it's doable.
Many people including me have just stopped watching Twitch because of the new ads, but I'd love to help build a movement towards a no-advertising-ever streaming site.
If we can bring the cost of streaming the video content down I think it's doable.
The technology to build a live streaming platform is not the major thing here. It would be difficult to move all the streamers accustomed to streaming on Twitch to a completely new platform just for the sake of ads.
Right?
Hey creators, because Twitch is forcing viewers to watch ads that give you money, move over to this other platform!
You could suggest that by removing ads, they'll get more of other revenue streams, but that doesn't seem to be the case with Twitch, people chuck money at streamers anyway. So there is no real incentive for creators to move, or even be worried about these changes by Twitch.
You could suggest that by removing ads, they'll get more of other revenue streams, but that doesn't seem to be the case with Twitch, people chuck money at streamers anyway. So there is no real incentive for creators to move, or even be worried about these changes by Twitch.
Does the typical ratio of ad-support to subscriber-support work out in such a way that an ad-free Twitch would be economically feasible for both the site and the streamers?
That's putting aside the huge community inertia that Twitch has. Neither Microsoft nor Google nor Facebook have neen able to make headway with their game streaming services.
That's putting aside the huge community inertia that Twitch has. Neither Microsoft nor Google nor Facebook have neen able to make headway with their game streaming services.
Peertube is working on live streaming this year. They just hit their funding goal.
The idea is sexy on paper, and it's been tried several times since webRTC came out. But the execution, both technically and commercially, is really hard to get right. I wish you good luck.
Kudos, looks really good. What is the pricing?
It's free of cost for access to developers. Enterprise customers can reach out to [email protected] for pricing.
For businesses, the price of growth need to be predictable.
Adopting any new technology takes time and effort, which translates to invested money that need to make sense in the long run.
Adopting any new technology takes time and effort, which translates to invested money that need to make sense in the long run.
Yes the pricing would be a tiered based pricing and depends on the traffic of the enterprise. Higher traffic will have discounts
Have spent only a couple of minutes looking at it but it works by connecting to a websocket server where everyone who watches the video announces themselves, when 2 people are watching the same video a WebRTC data channel is opened for streaming video content.
Have you guys considered the security aspect of such a service? Specially a data channel open between 2 anonymous party is a very nice attack vector imo.