5 ms·

The issue with using it for Netflix isn't privacy, it's that bittorrent is simply not any good for streaming video content when compared with current technologi

The issue with using it for Netflix isn't privacy, it's that bittorrent is simply not any good for streaming video content when compared with current technologies already used by streaming broadcasters. * It's slower to deliver video since you're reliant on upload connections of end users * It's less reliable (same reason as above) * You have no guarantee that chunks will arrive in the right order to actually stream data (ie the end of the file might download first) * You cannot send multiple different video qualities in the same stream and have the client dynamically pick the right bitrate for their connection (this is what current streaming services do and why you often see Netflix / Prime video / etc switch between quality mid-stream without having to restart that stream. I can write more in this if people are interested) * It's harder to debug network problems if you are experiencing issues with video quality (been in enough stressful emergency meetings with network guys over the years - I can't imagine how much worse it might have been if we couldn't do a full end to end trace of the delivery) * Time to start playing a new stream is longer (which end users might care about) * It couldn't support live services where the video data is being generated near real time The current methods for video delivery are actually really good, bittorrent would be a major step backwards. However for delivering other kinds of assets - such as patches to computer games - protocols conceptually similar to bittorrent are used.

deadalus 8y ago
Hence the reason why bitchute.com(uses Webtorrent protocol) is so slow.
abraae 8y ago
It's all about economics. Yes, torrents have some downsides - forever they can be worked through at some cost of quality. I might see some delays occasionally for example while I wait for an it is sequence chunk to arrive. However for some content/use cases, perhaps that will be acceptable. Right now the economics favor a dedicated and reliable changes from the source - e.g Netflix. Perhaps one day another use case will appear where the massive cost benefits of piggybacking off other people's resources comes into its own.
- laumars 8y ago
  I've done some work on with broadcasters distributing video assets over IP and honestly I can't see bittorrent ever being used. Once multicast over RMTP becomes reliable (which broadcasters are working towards) then the one advantage bittorrent has (reducing bandwidth from source) becomes moot for live services. Video on demand services would still have bandwidth issues but its less "spikey" and you'd factor that into the running cost of the service (and thus what you charge customers / advertisers). But I guess "never say never?"
  - canhascodez 8y ago
    Well, do you think that BT might have the potential to reduce bandwidth costs? And what difference might that make to the overall cost of doing business?
    - laumars 8y ago
      I think ISPs might quickly stop P2P video delivery if it became the norm because there's no way they would want to pay for the bandwidth. Or those costs will just get passed onto the consumers. Either way, it's not free bandwidth. In terms of video streaming services, there's other ways to reduce bandwidth costs without resorting to P2P. Multicast being the prime candidate as that's where you send one IP packet which targets multiple different endpoints (rather than unicast which is the typical point to point method of IP comms)
remcob 8y ago
Your argument is completely valid in the current context, which is the only that matters. Just FYI, In other contexts these points are more nuanced: > It's slower to deliver video since you're reliant on upload connections of end users. This has been scaling really well for small unfunded projects that need to deliver big binaries, such as open source distributions. > It's less reliable (same reason as above) If you have large corporate or state level actors trying to censor the content, then this becomes the more reliable method. > You have no guarantee that chunks will arrive in the right order to actually stream data (ie the end of the file might download first). This is not fixed by the protocol, but by clients optimizing for total download speed. I think some clients allow you to download more sequentially. > You cannot send multiple different video qualities... Video torrents often come in 720p, 1K and sometimes even 4K versions. So you could pick in advance. But that's not dynamic mid-stream like you mention. Since you offered to write more: Is there such a thing as a progressive codec for audio/video? I vaguely remember video chat codecs doing something like this, where you get progressive degradation if you loose packets. > It's harder to debug network problems... oh yes... I think this is the main reason Skype and Spotify moved away from the P2P tech that they used initially. I hope this becomes less of an issue when projects like LibP2P and IPFS mature and become as reliable and common as TCP/IP and TLS. > Time to start playing a new stream is longer... You can solve many of the issues mentioned above by having high quality sponsored seed servers. This is basically a hybrid approach. The seeds would guarantee good services and the P2P part would reduce load on the seed servers where possible. > It couldn't support live services where the video data is being generated near real time Not Torrent, but there's community of P2P television streams, quite popular for big sports matches. And from what I hear great quality. This is a completely different P2P model, more like a multicast stream. Can not do the sort of on-demand streaming that Netflix would require.
- laumars 8y ago
  I already acknowledged that torrents are good for some non-video applications. :) I just can't ever see it being practical for video deployment. At least not in its current guise (thus whatever P2P model might succeed in the future wouldn't be authentically bittorrent). If anything, with AWS and other "clouds" offering services for video delivery (Media Live, CloudFront supporting RMTP etc), I can see bittorrent becoming ever more irrelevant for video distribution. At least thats the trend Ive been observing recently. But tech can move in unpredictable directions so never say never.
tjoff 8y ago
> It's slower to deliver video since you're reliant on upload connections of end users Doesn't really matter, it is fast enough. If it isn't you back it up from a datacenter. > It's less reliable (same reason as above) Shouldn't be any real difference in reliability. > You cannot send multiple different video qualities in the same stream and have the client dynamically pick the right bitrate for their connection (this is what current streaming services do and why you often see Netflix / Prime video / etc switch between quality mid-stream without having to restart that stream. I can write more in this if people are interested) Sure you can. You only have to have a small map between play time and file offset for the different streams, the client will then pick whatever it wants. > You have no guarantee that chunks will arrive in the right order to actually stream data (ie the end of the file might download first) The client can decide this. There are torrent clients that do this already. Buffer 2 minutes, if some chunk is missing when 20 seconds remains pull it from a datacenter instead. > Time to start playing a new stream is longer (which end users might care about) No, you start streaming from the datacenter. > It couldn't support live services where the video data is being generated near real time Not sure, but if a minute is acceptable delay (depends on what is being broadcasted) it should be feasible. A live webcam for a tourist resort should be fine, a sports event, maybe not. Spotify even used to work this way. When a user clicked play (or seeked to a different part of the song) the first (if I remember correctly) 15 seconds was fetched from their CDN. After that it used its own torrent-like system to continue and pre-fetch the next song.
- laumars 8y ago
  > Doesn't really matter, it is fast enough. If it isn't you back it up from a datacenter. Sorry but no it really isn't. You'd have to rely so much in your own data centre that you'd loose the benefit of bittorrent. Plus many services will use a commercial CDN, none of which current support bittorrent. So you'd end up having to build your own infrastructure there, which would be a great deal more expensive. > Shouldn't be any real difference in reliability. Home connections might drop off due to power cuts, router failure or any of the other numerous conditions that datacenters battle against. Home connections might get throttled by ISPs. Where I work we offer 5 "9s" of reliability on some services, good luck asking consumer broadband to offer the same ;) > The client can decide this. There are torrent clients that do this already. Buffer 2 minutes, if some chunk is missing when 20 seconds remains pull it from a datacenter instead. 2 minutes is an excessively long buffer compared to.how long most RMTP segments are (often 15 seconds or below). > No, you start streaming from the datacenter. So then why bother with bittorrent at all? > Not sure, but if a minute is acceptable delay (depends on what is being broadcasted) it should be feasible. A live webcam for a tourist resort should be fine, a sports event, maybe not. A minute isn't even close to acceptable delay. Imagine if you're watching a sports match and Twitter is ahead of your video fees, you wouldn't be grateful for the spoilers. This is a real world problem with video streaming and why they talk about getting the latency down to 5 seconds or less. > Spotify even used to work this way. When a user clicked play (or seeked to a different part of the song) the first (if I remember correctly) 15 seconds was fetched from their CDN. After that it used its own torrent-like system to continue and pre-fetch the next song. Spotify is audio only. People love to compare video streaming to audio streaming but they don't realise that HD video is an order of magnitude more complex to stream - in terms of bandwidth, syncing, dropped frames, etc. It's one of those problems that seems easy to solve from a superficial level but when you start getting to the broadcaster level it's actually a great deal more complex than even Plex and other self-hosted streaming services would lead you to believe. (Disclaimer, I've worked at the broadcaster level)
deleted 8y ago
[deleted]

deadalus 8y ago

Hence the reason why bitchute.com(uses Webtorrent protocol) is so slow.

abraae 8y ago

It's all about economics. Yes, torrents have some downsides - forever they can be worked through at some cost of quality. I might see some delays occasionally for example while I wait for an it is sequence chunk to arrive. However for some content/use cases, perhaps that will be acceptable. Right now the economics favor a dedicated and reliable changes from the source - e.g Netflix. Perhaps one day another use case will appear where the massive cost benefits of piggybacking off other people's resources comes into its own.

laumars 8y ago
I've done some work on with broadcasters distributing video assets over IP and honestly I can't see bittorrent ever being used. Once multicast over RMTP becomes reliable (which broadcasters are working towards) then the one advantage bittorrent has (reducing bandwidth from source) becomes moot for live services. Video on demand services would still have bandwidth issues but its less "spikey" and you'd factor that into the running cost of the service (and thus what you charge customers / advertisers). But I guess "never say never?"
- canhascodez 8y ago
  Well, do you think that BT might have the potential to reduce bandwidth costs? And what difference might that make to the overall cost of doing business?
  - laumars 8y ago
    I think ISPs might quickly stop P2P video delivery if it became the norm because there's no way they would want to pay for the bandwidth. Or those costs will just get passed onto the consumers. Either way, it's not free bandwidth. In terms of video streaming services, there's other ways to reduce bandwidth costs without resorting to P2P. Multicast being the prime candidate as that's where you send one IP packet which targets multiple different endpoints (rather than unicast which is the typical point to point method of IP comms)

remcob 8y ago

Your argument is completely valid in the current context, which is the only that matters. Just FYI, In other contexts these points are more nuanced: > It's slower to deliver video since you're reliant on upload connections of end users. This has been scaling really well for small unfunded projects that need to deliver big binaries, such as open source distributions. > It's less reliable (same reason as above) If you have large corporate or state level actors trying to censor the content, then this becomes the more reliable method. > You have no guarantee that chunks will arrive in the right order to actually stream data (ie the end of the file might download first). This is not fixed by the protocol, but by clients optimizing for total download speed. I think some clients allow you to download more sequentially. > You cannot send multiple different video qualities... Video torrents often come in 720p, 1K and sometimes even 4K versions. So you could pick in advance. But that's not dynamic mid-stream like you mention. Since you offered to write more: Is there such a thing as a progressive codec for audio/video? I vaguely remember video chat codecs doing something like this, where you get progressive degradation if you loose packets. > It's harder to debug network problems... oh yes... I think this is the main reason Skype and Spotify moved away from the P2P tech that they used initially. I hope this becomes less of an issue when projects like LibP2P and IPFS mature and become as reliable and common as TCP/IP and TLS. > Time to start playing a new stream is longer... You can solve many of the issues mentioned above by having high quality sponsored seed servers. This is basically a hybrid approach. The seeds would guarantee good services and the P2P part would reduce load on the seed servers where possible. > It couldn't support live services where the video data is being generated near real time Not Torrent, but there's community of P2P television streams, quite popular for big sports matches. And from what I hear great quality. This is a completely different P2P model, more like a multicast stream. Can not do the sort of on-demand streaming that Netflix would require.

laumars 8y ago
I already acknowledged that torrents are good for some non-video applications. :) I just can't ever see it being practical for video deployment. At least not in its current guise (thus whatever P2P model might succeed in the future wouldn't be authentically bittorrent). If anything, with AWS and other "clouds" offering services for video delivery (Media Live, CloudFront supporting RMTP etc), I can see bittorrent becoming ever more irrelevant for video distribution. At least thats the trend Ive been observing recently. But tech can move in unpredictable directions so never say never.

tjoff 8y ago

> It's slower to deliver video since you're reliant on upload connections of end users Doesn't really matter, it is fast enough. If it isn't you back it up from a datacenter. > It's less reliable (same reason as above) Shouldn't be any real difference in reliability. > You cannot send multiple different video qualities in the same stream and have the client dynamically pick the right bitrate for their connection (this is what current streaming services do and why you often see Netflix / Prime video / etc switch between quality mid-stream without having to restart that stream. I can write more in this if people are interested) Sure you can. You only have to have a small map between play time and file offset for the different streams, the client will then pick whatever it wants. > You have no guarantee that chunks will arrive in the right order to actually stream data (ie the end of the file might download first) The client can decide this. There are torrent clients that do this already. Buffer 2 minutes, if some chunk is missing when 20 seconds remains pull it from a datacenter instead. > Time to start playing a new stream is longer (which end users might care about) No, you start streaming from the datacenter. > It couldn't support live services where the video data is being generated near real time Not sure, but if a minute is acceptable delay (depends on what is being broadcasted) it should be feasible. A live webcam for a tourist resort should be fine, a sports event, maybe not. Spotify even used to work this way. When a user clicked play (or seeked to a different part of the song) the first (if I remember correctly) 15 seconds was fetched from their CDN. After that it used its own torrent-like system to continue and pre-fetch the next song.

laumars 8y ago
> Doesn't really matter, it is fast enough. If it isn't you back it up from a datacenter. Sorry but no it really isn't. You'd have to rely so much in your own data centre that you'd loose the benefit of bittorrent. Plus many services will use a commercial CDN, none of which current support bittorrent. So you'd end up having to build your own infrastructure there, which would be a great deal more expensive. > Shouldn't be any real difference in reliability. Home connections might drop off due to power cuts, router failure or any of the other numerous conditions that datacenters battle against. Home connections might get throttled by ISPs. Where I work we offer 5 "9s" of reliability on some services, good luck asking consumer broadband to offer the same ;) > The client can decide this. There are torrent clients that do this already. Buffer 2 minutes, if some chunk is missing when 20 seconds remains pull it from a datacenter instead. 2 minutes is an excessively long buffer compared to.how long most RMTP segments are (often 15 seconds or below). > No, you start streaming from the datacenter. So then why bother with bittorrent at all? > Not sure, but if a minute is acceptable delay (depends on what is being broadcasted) it should be feasible. A live webcam for a tourist resort should be fine, a sports event, maybe not. A minute isn't even close to acceptable delay. Imagine if you're watching a sports match and Twitter is ahead of your video fees, you wouldn't be grateful for the spoilers. This is a real world problem with video streaming and why they talk about getting the latency down to 5 seconds or less. > Spotify even used to work this way. When a user clicked play (or seeked to a different part of the song) the first (if I remember correctly) 15 seconds was fetched from their CDN. After that it used its own torrent-like system to continue and pre-fetch the next song. Spotify is audio only. People love to compare video streaming to audio streaming but they don't realise that HD video is an order of magnitude more complex to stream - in terms of bandwidth, syncing, dropped frames, etc. It's one of those problems that seems easy to solve from a superficial level but when you start getting to the broadcaster level it's actually a great deal more complex than even Plex and other self-hosted streaming services would lead you to believe. (Disclaimer, I've worked at the broadcaster level)

deleted 8y ago

[deleted]