3 ms·

Except you only managed to disprove one point, every other counter argument you gave I was able to offer problems with. I honestly think privacy is the least o

Except you only managed to disprove one point, every other counter argument you gave I was able to offer problems with. I honestly think privacy is the least of the problems. A bigger issue is just getting content owners on board to begin with Edit: sorry to read you've had a rough few days. Hope things improve soon

tjoff 8y ago
I thought I pretty much disproved every point you made. Here are some further comments but honestly the issues you bring up doesn't make much sense. > If you have to rely so much in your own data centre Not sure if we are talking 15 second gifs or full-length films here. The thread started with netflix as an example and that's the context I've assumed. The startup-cost on a full-feature film or even a series episode is barely a fraction in the context so I really don't get your comment here. But I would go even further and expect constant backing from your data center to help with distribution, depending on how incentivized people are to keep the client alive after they've seen something. I would also not, both for network performance and common decency+courtesy, try to squeeze everything out of my customers internet connections. > 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. None of that applies here, that's a huge point of bittorrent to be resilient against that so it just doesn't make any sense to bring it up. A datacenter is centralized so it needs to deal with it. Thousands of clients spread throughout the world will likely even have better reliability than a datacenter. All in all, no reliability lost. Throttled by ISPs are a real issue and I really highlighted those issues earlier. > 2 minutes is an excessively long buffer compared to.how long most RMTP segments are (often 15 seconds or below). I just made that number up, but yes, a torrent solution will need a larger buffer. That really isn't a problem in this context. What is a much bigger problem is the storage needed for seeding depending on how you want to solve that and how reliant you want to be on your clients (again, your points doesn't make sense, why complain about the buffer when the cache is orders of magnitude worse). > So then why bother with bittorrent at all? I wouldn't, and I never said I would. But the protocol would work for it, consumer ISPs and other factors might not for such a large scale operation. And the privacy implications are also bad, it would leak information to your competitors as well. Bandwidth costs clearly aren't that big of a deal either so the potential gain isn't worth it (talking netflix scale here). Also proxys at ISPs are a superior solution. > A minute isn't even close to acceptable delay[...] You can not possibly have read what I wrote. > A bigger issue is just getting content owners on board to begin with Content owners are notoriously irrational so I wouldn't argue against that. But torrents could still be encrypted.
- laumars 8y ago
  I suspect some of the issues you're having understanding my comments is I've assumed you had a working knowledge of RMTP. Basically the protocol comprises of multiple streams of various bit rates. These streams are chunked into blocks of n seconds. This is often around 15 seconds or less. The client will hot swap between each stream if one chunk takes too long or downloads too quick. This ensures that the video quality dynamically scales to the best bitrate your bandwidth will handle and it does so quickly and with minimal buffering. It works for video on demand services but it also works for live feeds as well and the whole thing can be served over multicast or UDP for further savings at either the DC or across the wire. Bittorrent is nowhere near optimised enough to compete on that level. The 2minute buffering you guessed at would easily look terrible in side by side comparisons with RMTP deliveries. Not to mention a whole boat load of hardware encoders (rack mountable gear used in broadcasters) are built for spitting out RTMP streams yet none (at least that I'm aware of) exist for BT. So you'd have to build your own gear as well as content delivery network. That alone would cost you far more than any savings P2P deployment might earn you.
  - tjoff 8y ago
    That is a good point. I still argue you can do the same but with worse results with a torrent solution. If you have 2 minutes of buffer but realize you can't keep it up you can still switch to a lower bitrate, that will allow you to get any missing chunks and maintain the buffer going forward. So you can still adapt (from the networks point of view much quicker than the 2 minutes), but not nearly as fast and the end result (quality change) might lag quite a bit.
p1necone 8y ago
They haven't explicitly 'disproved' all of your points because as mentioned previously most of what you said is nonsense. (Someone already mentioned this, but seriously - this has been done - it works really well - as a polished commercial product it would probably work even better: https://en.wikipedia.org/wiki/Popcorn_Time https://en.wikipedia.org/wiki/Popcorn_Time)
- laumars 8y ago
  I've already addressed Popcorn time several times in this discussion. The fact that you've acknowledged that it's not as polished as a commercial product should be a big hint that perhaps commercial products choose RMTP over BT for a valid reason. Perhaps even for the reasons you initially dismissed as nonsense. Perhaps you might need to read up a little more about how professional video deployment actually works before you assuming you understand video deployment better than all those engineers who do this shit for a living. Just because something conceptually works it doesn't mean it's any good when dealing with the expectations of paying customers who might want SLAs of 99.999% uptime, low latency live services (like less than 10 seconds), near zero buffering times etc. The Dunning–Kruger effect is overwhelming in this thread but trust me when I say video engineers are not stupid people and if their lives could be made easier by using BT then we would definitely be seeing commercial uses of BT for video deployment. https://en.m.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect https://en.m.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effec...

tjoff 8y ago

I thought I pretty much disproved every point you made. Here are some further comments but honestly the issues you bring up doesn't make much sense. > If you have to rely so much in your own data centre Not sure if we are talking 15 second gifs or full-length films here. The thread started with netflix as an example and that's the context I've assumed. The startup-cost on a full-feature film or even a series episode is barely a fraction in the context so I really don't get your comment here. But I would go even further and expect constant backing from your data center to help with distribution, depending on how incentivized people are to keep the client alive after they've seen something. I would also not, both for network performance and common decency+courtesy, try to squeeze everything out of my customers internet connections. > 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. None of that applies here, that's a huge point of bittorrent to be resilient against that so it just doesn't make any sense to bring it up. A datacenter is centralized so it needs to deal with it. Thousands of clients spread throughout the world will likely even have better reliability than a datacenter. All in all, no reliability lost. Throttled by ISPs are a real issue and I really highlighted those issues earlier. > 2 minutes is an excessively long buffer compared to.how long most RMTP segments are (often 15 seconds or below). I just made that number up, but yes, a torrent solution will need a larger buffer. That really isn't a problem in this context. What is a much bigger problem is the storage needed for seeding depending on how you want to solve that and how reliant you want to be on your clients (again, your points doesn't make sense, why complain about the buffer when the cache is orders of magnitude worse). > So then why bother with bittorrent at all? I wouldn't, and I never said I would. But the protocol would work for it, consumer ISPs and other factors might not for such a large scale operation. And the privacy implications are also bad, it would leak information to your competitors as well. Bandwidth costs clearly aren't that big of a deal either so the potential gain isn't worth it (talking netflix scale here). Also proxys at ISPs are a superior solution. > A minute isn't even close to acceptable delay[...] You can not possibly have read what I wrote. > A bigger issue is just getting content owners on board to begin with Content owners are notoriously irrational so I wouldn't argue against that. But torrents could still be encrypted.

laumars 8y ago
I suspect some of the issues you're having understanding my comments is I've assumed you had a working knowledge of RMTP. Basically the protocol comprises of multiple streams of various bit rates. These streams are chunked into blocks of n seconds. This is often around 15 seconds or less. The client will hot swap between each stream if one chunk takes too long or downloads too quick. This ensures that the video quality dynamically scales to the best bitrate your bandwidth will handle and it does so quickly and with minimal buffering. It works for video on demand services but it also works for live feeds as well and the whole thing can be served over multicast or UDP for further savings at either the DC or across the wire. Bittorrent is nowhere near optimised enough to compete on that level. The 2minute buffering you guessed at would easily look terrible in side by side comparisons with RMTP deliveries. Not to mention a whole boat load of hardware encoders (rack mountable gear used in broadcasters) are built for spitting out RTMP streams yet none (at least that I'm aware of) exist for BT. So you'd have to build your own gear as well as content delivery network. That alone would cost you far more than any savings P2P deployment might earn you.
- tjoff 8y ago
  That is a good point. I still argue you can do the same but with worse results with a torrent solution. If you have 2 minutes of buffer but realize you can't keep it up you can still switch to a lower bitrate, that will allow you to get any missing chunks and maintain the buffer going forward. So you can still adapt (from the networks point of view much quicker than the 2 minutes), but not nearly as fast and the end result (quality change) might lag quite a bit.

p1necone 8y ago

They haven't explicitly 'disproved' all of your points because as mentioned previously most of what you said is nonsense. (Someone already mentioned this, but seriously - this has been done - it works really well - as a polished commercial product it would probably work even better: https://en.wikipedia.org/wiki/Popcorn_Time https://en.wikipedia.org/wiki/Popcorn_Time)

laumars 8y ago
I've already addressed Popcorn time several times in this discussion. The fact that you've acknowledged that it's not as polished as a commercial product should be a big hint that perhaps commercial products choose RMTP over BT for a valid reason. Perhaps even for the reasons you initially dismissed as nonsense. Perhaps you might need to read up a little more about how professional video deployment actually works before you assuming you understand video deployment better than all those engineers who do this shit for a living. Just because something conceptually works it doesn't mean it's any good when dealing with the expectations of paying customers who might want SLAs of 99.999% uptime, low latency live services (like less than 10 seconds), near zero buffering times etc. The Dunning–Kruger effect is overwhelming in this thread but trust me when I say video engineers are not stupid people and if their lives could be made easier by using BT then we would definitely be seeing commercial uses of BT for video deployment. https://en.m.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect https://en.m.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effec...