Hacker News new | past | comments | ask | show | jobs | submit login
[flagged] YouTube alternatives: P2P video hosting that uses up to 60% less bandwidth [pdf] (oregonstate.edu)
25 points by 1vuio0pswjnm7 on July 11, 2021 | hide | past | favorite | 34 comments




Thx. It wont let me edit the URL to fix.


Disclaimer: I work on YouTube's video players. But I don't speak for the company in any way (this is my personal account on my personal computer on my time off from work).

If I understand this correctly, it's worth clarifying that "60% less bandwidth" is for the website host, not the client. Which yeah, is expected if you're using a P2P protocol to offload your bandwidth costs to your users. But it's not a 60% bandwidth savings for the consumer.

I know some might think that's obvious but it's always worth clarifying whose bandwidth you're talking about.


As I understand it, when you want to save bandwidth for the clients you're always limited by the video codec, or you have to take a tradeoff in lowering the quality.

So you're stuck with either VP9, or HEVC which is not royalty free, because nothing better exists at the moment.


AV1 exists, and is actively used for serving a good chunk of YouTube content.

But yeah, codecs and smart format selections/ABR are critical to reducing bandwidth.


How much security savings do I get?


Unrelated to this link, but youtube is WAY slower than pretty much any other video alternatives. Note I even use the embed link for the video and have ublock, so it's not the youtube UI boggling it down.

Don't feel like writing more right now, but just felt like saying youtube is terrible in performance to my eyes.


GP is not referring to the UI side of things. He is essentially saying that clients need 100% of the video, while under this P2P scheme, 60% of your outgoing video packets can be offloaded to other users in the system. Regardless of scheme, the same amount of data needs to be moved around, it's just a semantic perspective on who is "saving" bandwidth. If your consumer internet plan has caps, your p2p uploads might count against your quota, so you are in effect "losing" bandwidth.


Without proper discovery mechanisms any P2P solutions will be DOA. This paper focuses on the technical aspects, which is very warranted, but the reason YouTube is winning isn't technical per se.

Any solution would:

1. Need to have unique content.

2. Have a mechanism to incentivize new content being created.

3. Make it easy to discover (1).

These problems can be addressed, but I believe it will inevitably result in centralization.


Could the index of video checksums (discovery) be decentralised. Could hosting and discovery be treated as separate problems. Or must they be controlled by the same entity, a company with a monopoly on search, promoting its own hosting service in search results, funded by billions in ad sales and conducting mass surveillance on its users, with the costs of transferring data to Google paid for by those being surveilled. Is there more than one way to do it. Is it possible.

Does video sharing even have to be a business for every single person who participates. P2P is funded by people paying for internet service. Some folks might just want to share video with a small audience, and not for profit. Friends, family, colleagues, etc. Is every single internet user desperate for traffic. Does every internet user have to imagine themselves as a "tech" company, serving ads, asking for fees to "remove" ads, and collecting data about other people. Not to mention using opaque algorithms to generate "recommendations" that favor an online ad services business model.

In any event, P2P might reduce hosting costs, which is obviously a barrier to entry for anyone wanting to host their own video. Even better, it might allow those costs to be financed by other people without:

1. Signing up for anything (submitting personal data)

2. Viewing online ads

3. Facilitating data collection and tracking by "tech" companies


Could the index (discovery) be decentralised. Cold hosting a discovery be treated as separate problems. Or must they be controlled by the same entity, a company with a monopoly on search, promoting its own hosting service, funded by billions in ad sales and condicting mass data collection about its users, with the costs of transferring data to Google paid for by the user. Is there more than one way to do it.

Does this even have to be a business for every single person who participates. P2P is funded by people paying for internet service. Some folks might just want to share video with a small audience, and not for profit. Friends, family, colleagues, etc. Is every single internet user desperate for traffic. Does every internet user have to imagine themselves as a "tech" company, serving ads or charging cryptocurrency, and collecting data about other people.


oh heart.

Not going to happen.

> Current video streaming and storage systems such as YouTube, are based on the client-server model, thus do not scale well in terms of bandwidth and computation.

YouTube seems to be doing just fine as-is, as well as all the millionaires using the system as is.

> The recent development of Peer-to-Peer (P2P) networks..

Wait, what year was this written? 1996?



How in the world is the #1 front page story a 404 not found? I mean, I see people posting working links in comments, but as of writing this comment, it only has 15 points!? Really makes me question the HN algorithm for determining top stories :) 15 points no matter how fast it happens should never propel something to #1 in my opinion.


Asking the right questions


Hmmm... 1. Requires new routing protocol/network protocol. (multipath routing) 2. Relies on storage and network capacity with no reliability guaranties. 3. Limited ability to detect bad actors - because of network coding you don't know a) if you have a bad block until you decode it, b) who gave you the bad data until unless you get more redundant copies than you would need to decode the data.

Just point 1 alone would require the entire internet backbone to be upgraded. We're still trying to get that done for IPv6, so don't expect to be able to use this in the near future.

The other points would make it vulnerable to DoS attacks and even without bad actors it needs large scale and a slowly changing network base to work reliably.

But it got published.... So I guess that's worth something?


Their multipathing is just swarming with multiple TCP connections so it requires no changes to the network. I agree that having no "permanent" storage is really risky and overall this paper looks pretty complex and overengineered compared to something like WebTorrent.


Decentralized internet proponents won't like to hear this, but network operators would much rather have CDNs for distributing popular content than any P2P approach. It just uses less overall network bandwidth.


I'm not a networking expert, but this doesn't sound right. How would using a CDN use less bandwidth?

My understanding is that a CDN for video improves performance and reduces traffic for the host but the total bandwidth doesn't change for the client, so for a network operator it wouldn't make any difference.


POP servers and the Telcos pushing that out even further (into neighborhood servers) with partnerships with major content sites. Once they finally switch all of the TV content to packets we'll see a lot more bandwidth overall because the Telcos can take advantage of this locality. In essence it is a distributed system with the majority of the P2P benefits. The Telco can be a major hub in the "P2P network" largely because it saves them money in the long-run


Total bandwidth reduces because the files get cached at the edge. E.g. if I'm watching a Netflix movie from the UK that is originally hosted in the US, the stream has to move to the UK, where it can then be cached, then it is also sent to me. For the first stream there is no bandwidth savings. Any additional person that watches the same only needs to get the file from the cached location, thus saving bandwidth between Netflix's hosting location, and UK.

In contrast with p2p, bandwidth may or may not be saved for the ISP. If my peers are close to me, sure, but if all my peers are US based, then there is no bandwidth savings. Furthermore, when I stop stream the video, and I don't have parts any more, and another in my area is still watching, they now have to connect to US peers and/or origin server.

This is obviously oversimplified. In reality, the best solution likely includes a CDN combined with P2P, which would maximise bandwidth savings for hosters and maximise performance.


The host can put their CDN inside the operator's network. And, generally, a centrally operated CDN can be smarter than p2p.


This is the idea behind theta token https://www.thetatoken.org/

Google is 1 of the sponsors, but I don’t think that means too much.


Even if you implemented this how are you going to replace the ad money and the viewers?


Ads are even more unreliable with peer to peer than with regular Youtube.

However, you could make money like many professional youtubers: sponsorships for companies. Getting a sponsorship requires a certain amount of fame and viewers in the first place, though. It'd be near impossible to start a Youtube-like career, but for existing Youtubers who can use this system as a secondary/alternative video host, the problem wouldn't be so big.


There's also more direct payments like either BAT, or what Nebula is doing. But that's harder to realistically achieve than sending ads to everyone.


> how are you going to replace the ad money and the viewers?

ads can be implemented but I'm not sure why you are saying that you couldn't get viewers...


network effect, as in people networks, not traffic networks.


Don’t have ads.


(BA)Nano or similar crypto currencies? I am also a proponent of the bitclout concept to being able to purchase creator coins.


Is that a nano fork? No thanks.


What are your concerns? I find it interesting, because there is a vibrant community and it Banano specifically ties into Folding at Home (FAH).


I get a 404 from this link





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: