[zeptomu]

> In addition subtitles, secondary audio, descriptive video, and multi-view video etc. are all things which we mandate by law which do not work well in a file base expierenced.

That's just not true - VLC has many more features than all the web-based (or "app"-based) popular streaming players. Granted, I checked and my VLC does not have "thumbnail scrubbing", but although that is nice, I don't think this is a big deal and if it's really popular, it will be added to VLC (or it may already be there, I did not check).

[JohnBooty]

I'm a big fan of torrents and would prefer them to streams! I'm a bit of a data hoarder. But there are clear reasons why Netflix et al don't simply have you downloading massive files. It would definitely be simpler, but that doesn't mean it's an adequate engineering choice. Lot of smart people working there and they don't jump through all those extra hoops just for fun.

1. You can't play a torrented file until the download is 100% complete. (Well, maybe 95% complete, depending on how tolerant you and your software are when it comes to malformed files)

That's the way it was designed to work. Otherwise, the bits at the beginning of the file would be much more common amongst your non-seeding peers and the bits at the end would be much rarer amongst your non-seeding peers. Your downloads would start crazy fast and would get progressively slower.

Some clients let you abuse the protocol and "stream" torrents sequentially, but if significant percentages of torrenters (such as literally every Netflix user, in an imaginary world where Netflix simply served everything via torrents) did that it would be an issue.

That's a great way to deliver big files in their entirety via P2P, but that is pretty much the pathological opposite of what is requred for streaming.

For streaming you obviously need that sequential access. You need to optimize for the beginning of the file, since people want to start watching right away. People do not want to wait 60 or 30 or even 10 seconds for a YouTube vid to start streaming.

2. Think about your actual viewing habits. How many times have you watched the first 1% of a video on YouTube or Netflix, and then decided to watch something else instead? Even if we (probably generously) assume most users watch an average of 50% of a given video (I suspect it's much less) that's still 2x wasted bandwidth per video, on average, if video providers blasted out entire files. Netflix's infrastructure (or rather, their AWS monthly bill) is massive already. Imagine it being asked to blast out 2 or 5 or 10x as much data per video as it's already doing.

3. There's also the rather important matter of many (most?) playback devices not having huge gobs of local storage with which to hold complete movie downloads. I've got probably 20TB of hard drives scattered around this place, but that's not the norm.

4. Can't adapt to changing bandwidth conditions by scaling video quality up and down midstream. Personally, I wish I had more control over this as a customer, as sometimes I'd rather just wait than watch a compromised stream, but Average Joe is not going to want to muck around with that sort of choice, or even understand what it means.

[butteroverflow]

Of course you can. Every modern BitTorrent client allows you to download file pieces by their order. IIRC it has been a solved problem for at least 8 years.

[JohnBooty]

That's abuse of the protocol. If a small number of people do it, no problem.

If everybody did it, that would be a big problem.

More to the original poster's point, my post answer's the posters question of "why doesn't YouTube just offer file downloads like Bittorrent?"

There are many clear reasons why; my post gave one of the more prominent ones.

[rakoo]

That is just not true, ever since PopcornTime has shown us that getting pieces in order is a viable strategy, especially at relatively large scale (for the BitTorrent network). There hasn't been any significant shortage of availability linked specifically to that way of downloading.

[cyberbanjo]

Why is that abuse of the protocol?

[JohnBooty]

Imagine a file split into 100 blocks.

You're the seeder. Initially you're the only one with all 100. And everybody's gonna download things sequentially.

Imagine 300 peers grab block 1 from you. Gonna be pretty slow, each peer gets 1/300th of your bandwidth.

Imagine those 300 peers finish block 1 and move onto block 2. Same bandwidth crunch. Although new peers can at least get block 1 from that initial cohort of 300 peers. But nobody can blocks 2 through 100 from anybody but you. Not ideal.

Now repeat the process for 3 through 100. You're gonna be the bottleneck for a loooooooong time for those remaining pieces.

...

...

...now imagine we do it differently. Those 300 peers each grab a random block. This part's just as slow.

But once they have their initial randomly-chosen blocks, our bandwidth explodes. Each of those 100 blocks is now available from ~4 sources (you, and roughly 3 others). And you could even log off at this point, since there is a complete (distributed) copy of your file out there.

As more blocks are exchanged, the effective aggregate bandwidth rapidly increases even farther.

[reacweb]

You are assuming all the peers start at the same time. It would be more fair to assume that the peers start regularly. In this case, the order does not cause issue.

[tripzilch]

No really, if this is such a big deal then why did Popcorn Time ever work in the first place? It was (is?) also hugely popular.

[Rychard]

Bittorrent tries to maximize the benefit of its P2P nature by not sending the same blocks to more than one peer.

i.e. I'll send block 1 to one peer, block 2 to another peer. Then I can send blocks 3 and 4 to them (respectively), while they each send each other blocks 1 and 2.

[zzo38computer]

If the protocol does not require it to be downloaded in order (I don't know much about the protocol), then presumably you should also be allowed to disable that feature if you do not want to play back the file immediately.

[paulddraper]

> You can't play a torrented file until the download is 100% complete.

That's just not true.

I've used uTorrent, and I recall deciding whether I wanted to stream or not. It worked well too.

[afiori]

This is addressed as "abusing the protocol"

[paulddraper]

And given that most popular clients allow you to, this because worthy of the "95% theoretical problem" title.

[m-p-3]

How is it abusing the protocol if it allows you to do it?

[zzo38computer]

"You can't play a torrented file until the download is 100% complete." Doesn't it depend on the file format in use? Some file formats are streamable, and in that case if the file is being downloaded in order then presumably it can be played (assuming the torrent software stores the file in a streamable way, and the playback software is capable of working with a file that is not yet complete but will get filled up over time).

(In the case of ZIP archives, 7-Zip can't open partial files, but bsdtar can. Although in my case it was from a damaged floppy disk rather than torrent, but the same thing would do, if you are downloading ZIP files from torrent. But if you are downloading music, then presumably bsdtar is irrelevant.)

[jayjader]

> 1. You can't play a torrented file until the download is 100% complete. (Well, maybe 95% complete, depending on how tolerant you and your software are when it comes to malformed files)

Theoretically, yes. But in practice, especially with "modern"/high-speed internet, I can open my torrent in VLC after the first few MB are present on my computer and read the entire file as it comes in, without me the user encountering stuttering or buffering of any kind.

In effect, from the user's perspective, you're streaming the torrent - without running into the often present decrease in quality from the "traditional" stream's encoding.