this is very misleading. the bittorrent protocol is not optimized for video streaming. try building a tik-tok style client that has a near 0 time to first frame latency for multiple videos. with bittorrent there is a lot of gossip overhead.
Discussion
i literally talked to bram cohen about this in person. this is why he was developing bittorrent live which unfortunately became closed source.
Bram didn't make WebTorrent, Feross did.
its still the bittorrent protocol, over the web. I don't see how that changes anything I said
i think we just have different definitions of performance. if you think webtorrent beats youtube in terms of performance I don't know what to say.
Youtube is performant because its http to a geographically close datacenter.
WebTorrent layered over a traditional CDN is the same exact thing
I'm not sure what's so hard to understand, WebTorrent is regular CDN capable with regular HLS chunking... same exact performance, it's additive when it reduces bandwidth costs by shedding chunks over RTC to peers.
Yahoo literally used this for their content delivery at massive scale already, your assumptions are wrong.
It's not Bittorrent, it's still http and HLS... WebTorrent as additive not subtractive.
I'm afraid you're misinformed. We've been using it for years for precisely the performance reason
The web-seeding nature of WebTorrent is beyond than normal Bittorrent
The chunking and ordering is the exact same as HLS, WebTorrent then adds onto that the ability to chunk over RTC in the browser to handle swarm events.
I wonder if it would be a proper solution to fetch the first X chunks of a video from a blossom server, possibly at a lower quality, and then switch to something else if the user continues on that video instead of swapping again.
I mean, that should give you both low latency withoug giving up on lower distribution costs, just need to work out the complexity cost of such a solution that is.
That's exactly what WebTorrent does by using webseeds. It's providing a redundant source for chunks while maintaining the raw performance of a traditional source.
An array of webseeds in the magnet also allow it to download chunks from disparate CDN's without a load balancer to handle that in the back-end, if one gets rugged your links still *just work*
I think the “near zero latency” is still a valid UX concern.
Do you know if it’s possible to setup a webtorrent library in a way that it is forced to try fetching from HTTP the first couple of chunks and only after a short delay fire up the lookup for seeders?
It's already doing that, there's no round-trip to a tracker required before hitting the webseed directly to get the mov atom and first chunks.
It's just a client that makes use of additional data.