Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You've hit the nail on the head. A set-top box that would keep a torrent active through normal seeding configurations out of band of the client worked wonders, because your ability to participate in the CDN wasn't determined by code you loaded in the player. You also have that it was targeting longer form content (>10min), so even if that was being shipped through these web based P2P clients, a person committed to a TV series or a movie would suffer through slightly more buffer jank.

Even then though, your average content viewer has different standards. We're opting for 1080p/4K content over the much more common smaller feeds. Netflix loads the first few segments of even the most esoteric content not in your local ISP cache in 100's of milliseconds, users flit from YouTube video to YouTube video randomly, and scroll TikTok like we used to scroll through the Twitter firehose back in the hey-day of the PopcornTime. More content is consumed on mobile devices than set-top boxes, which brings power and data constraints, both from metered data and with networks that are both highly latency variable and not tuned for upstream bandwidth, that make participation in a P2P swarm not ideal.

While content protection is certainly a core tenant of why content is centralized, if the big players at YouTube, Netflix, Hulu, et al, haven't figured out a way to shirk their highest cost center in lieu of putting it on the backs of someone else even cheaper than ISPs without causing a substandard consumer experience with P2P, then you can be darn sure that this is a tough nut to crack.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: