4 ms·
This comments on why bittorrent as is isn't used for live streaming, not why P2P shouldn't be used for live streaming > Latency matters. In bit torrent if the
by arghwhat 2y ago
This comments on why bittorrent as is isn't used for live streaming, not why P2P shouldn't be used for live streaming
> Latency matters. In bit torrent if the peer goes away, no big deal, just try again in 5 minutes with another peer, you are downloading in random order, who cares if one piecs is delayed 5 minutes. In a live stream your app is broken if it cuts out for 5 minutes.
First of all, BitTorrent clients do not download in random order or wait 5 minutes. They usually download the rarest block first, but can do whatever they want, whenever they want.
Second, standard HLS sets a nominal segment size of 6 seconds (some implementations will go as high as 10 seconds), and a client will usually cache multiple segments before playing (e.g., 3). This mean that you have 18 seconds before a segment becomes critical.
This is not a difficult thing for a P2P network to handle. You'd adapt things to introduce timing information and manage number of hops, but each client can maintain a connection to a number of other clients and have sufficient capacity to fill a segment if a connection fails. Various strategies could be used to distribute load while avoiding latency penalties.
Low-latency HLS uses much smaller segments and would be more demanding, but isn't impossible to manage.
> BitTorrent punishes people who dont contribute
Private communities punish this behavior, BitTorrent clients do not. Most new downloads will appear as freeriders for a long time, and only over long periods far exceeding the download time will enough compatible seeding opportunities arise for them to contribute in any substantial way.
The network does not need everyone to seed, it only needs enough people to seed.
- PaulHoule 2y agoI have a relatively slow ADSL connection, it's not unusual for me to be able to download 100% of the file at say 95% the theoretical rate without uploading anything. If the network has enough upload capacity to do this, does it really need my upload? (Note my client is still there if somebody needs a rare block) I remember some Bittorrent networks circa 2005 or so which tried to monitor you and punish you for not contributing and this was a disaster for me since my upload is necessarily a small fraction of my download. What I found is that kind of network seemed to perform poorly even when I had a good bidirectional connection. As I saw it, people who have the ability to upload more than they download are a resource that that kind of network can't exploit if everybody is forced to upload as much as they download.
- deleted 2y ago[deleted]
- arghwhat 2y agoYou are not required to seed immediately, nor even the same asset. Unless the rules have changed, you would usually just be required to maintain a particular minimum seed lifetime ratio that is easily achieved by idle seeding a library. The point is to ensure network health with a metric that is simple to understand and verify: that you have been a productive. If you aren't seeding, someone else has to pick up the slack and the network didn't benefit from you obtaining the blocks. The community itself benefits by giving members a guarantee that stuff there is available with abundant bandwidth, instead of relying purely on the unpaid goodwill of others.
- wruza 2y agoYou can't upload much of what's rarely downloaded. The usual way to help the network is to download something popular that you don't need and to seed it. This removes some strain from big seeders and helps them seed other things you don't have. But personally I believe you're not obliged to anything in torrents, especially with adsl. We got you covered with our multi-hundred u/d ratios. Everyone participating honestly and comfortably is enough, even if that means no upload. Just don't turn it off out of unnecessary principle after downloading.
- bavell 2y ago> First of all, BitTorrent clients do not download in random order or wait 5 minutes. They usually download the rarest block first, but can do whatever they want, whenever they want. The problem here is that BT works so well because the clients default to "good behavior" (prioritize rare pieces first) and discourages "bad behavior" (leeching/no upload). This tilts the balance on the whole enough to maintain the health of the network. If you change these, you'd need to introduce other mechanisms to preserve the network incentives.
- arghwhat 2y agoWith streaming, the service provider is generally also controlling the clients, so they should be much better off when it comes to client behavior. In case of bring-your-own-client, the incentives are exactly the same: Clients would likely default to good behavior as network health equals user experience, and exactly like BitTorrent there will be neither punishment nor need for it if some clients disobey.
- mannyv 2y agoIn video streaming the client really controls everything...unless you have your own client and customize its behavior. You should see how people try and get HLS to pick a stream. With the default players it's not possible - the client does it.
- arghwhat 2y agoYes that's the intended behavior of HLS - the content provider advertises which streams are available and at what bitrates, and the client picks which to use based on the current stream performance and its own capability. The server can control the stream by advertising a customized manifest to individual clients, although it's a bit silly. HLS is designed to be extremely easy to load distribute and throw CDN/cache proxies in front, and it's a bad sad that content providers are this bad at load management. :/ Either way, the assumption here is that you would swap out the client doing HLS with a client designed to use a P2P protocol, including the seeding portion and network health management.
- mannyv 2y agoNobody who does live streaming should set their gop to 6 seconds. That's way too big. I set ours to 2 seconds, which lets mobile adjust more quickly to their bandwidth limits. And as a note, video segments for live are usually set to no cache, as are vod segments. The CDN does the caching. The client should keep segments around if you're doing rewind, but that's a client thing.