6 ms·

> 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 fro

by 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)
- tjoff 8y ago
  I just can't address this further. I'm not convinced you have the slightest clue what bittorrent is (how on earth does not having 5 9s matter for a consumer connection? If a node drops noone will notice). I'm not saying there won't be problems. A major problem is the asymmetric nature of many consumer connections. Not only is the upload often a fraction of the download (that is the easy part), but the download speed can be greatly sacrificed if upload is utilized. Add to that issues that home users might want to use the connection for other stuff. The nightmare and confusion surrounding "I can't game because someone is watching torrent-tube" will be real and add to that issues with ISPs that have a fixed quota or people on mobile (or tethering a mobile connection to laptop). Netflix et al would not like to deal with that kind of FUD spreading around. And all this is before considering local ISP bottlenecks as it isn't what the network was designed for. A vastly superior option is to put a proxy on the ISP network itself (but yes, hard to do for small players). Those alone are probably a magnitude worse than the technical issues you speak of. Even spotify got much flak for it, and no, I don't think anyone on earth think the bandwidth requirements of audio and HD video are similar.
  - laumars 8y ago
    I actually did cover that point (albeit at a much higher level) and of course I know what bittorrent is. Just because I don't agree with you it doesn't mean I don't understand the problems. Quite the opposite, I happen to work in the video delivery industry so it's my job to understand these problems. Like I said, it's ever so easy being an armchair critic but try deploying this stuff at scale with SLAs covering 5 "9s" and paying customers then tell me you've got all the kinks in bittorrent solved ;)
    - tjoff 8y ago
      Arguably, no, you contrive issues that don't make any sense. Such as presenting the issue that the end of the file might be downloaded first. Or that you can't have different quality versions and dynamically switch. The end will only be downloaded if the client requests it, which won't be unless the user is watching the credits...

by tjoff 8y ago

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)

tjoff 8y ago
I just can't address this further. I'm not convinced you have the slightest clue what bittorrent is (how on earth does not having 5 9s matter for a consumer connection? If a node drops noone will notice). I'm not saying there won't be problems. A major problem is the asymmetric nature of many consumer connections. Not only is the upload often a fraction of the download (that is the easy part), but the download speed can be greatly sacrificed if upload is utilized. Add to that issues that home users might want to use the connection for other stuff. The nightmare and confusion surrounding "I can't game because someone is watching torrent-tube" will be real and add to that issues with ISPs that have a fixed quota or people on mobile (or tethering a mobile connection to laptop). Netflix et al would not like to deal with that kind of FUD spreading around. And all this is before considering local ISP bottlenecks as it isn't what the network was designed for. A vastly superior option is to put a proxy on the ISP network itself (but yes, hard to do for small players). Those alone are probably a magnitude worse than the technical issues you speak of. Even spotify got much flak for it, and no, I don't think anyone on earth think the bandwidth requirements of audio and HD video are similar.
- laumars 8y ago
  I actually did cover that point (albeit at a much higher level) and of course I know what bittorrent is. Just because I don't agree with you it doesn't mean I don't understand the problems. Quite the opposite, I happen to work in the video delivery industry so it's my job to understand these problems. Like I said, it's ever so easy being an armchair critic but try deploying this stuff at scale with SLAs covering 5 "9s" and paying customers then tell me you've got all the kinks in bittorrent solved ;)
  - tjoff 8y ago
    Arguably, no, you contrive issues that don't make any sense. Such as presenting the issue that the end of the file might be downloaded first. Or that you can't have different quality versions and dynamically switch. The end will only be downloaded if the client requests it, which won't be unless the user is watching the credits...