Hacker News new | past | comments | ask | show | jobs | submit login

If you're placing cache servers at the ISP then they will charge Netflix for the seeding bandwidth, which would work out more expensive than running traditional RMTP streams because the BT protocol has much more overhead (TCP vs UDP, CRC checks, tracker syncing, etc). And that's without factoring in the likelihood that the cost of bandwidth per GB from a CDN would be much lower than from an ISP.

So what would Netflix gain in doing so? They'd need to build new clients, convince content owners that P2P is secure[1], convince ISPs to seed content, pay for new infrastructure, etc. And the final product would be more expensive and _at best_ equivalent to what they already have - though realistically it will be worse on all but the top end viewing platforms (ie laptops and desktops). And for added bonus this infrastructure "upgrade" then removes the possibility of Netflix running live services and dynamic ad injection, etc.

So it's more expensive, less future proof, less performant on low end internet connections and wouldn't work on any of the existing smart TVs or streaming HDMI sticks.

Like I've said in other comments, BT is fine for hackers and pirates - for people who want to run something for free, willing to run it on a laptop or even willing to be inconvenienced a little for the sake of running something different. But it simply couldn't compete once you start scaling it out as a commercial platform with all of the customer expectations from non-techies and the unseen requirements / complications that happen with professional video delivery platforms behind the scenes. Plus for all of this talk about how good BT could be, people seem to miss the key point I made right from the start: that existing delivery platforms actually aren't that bad.

[1] I actually have no qualms with the security side of P2P in terms of protecting copyrighted content. But content owners are notoriously slow to adapt to change and hard to please. Getting them on side might prove an even tougher problem than engineering BT to compete with RMTP at the commercial scale.




RMTP license is pretty interesting as it among other things prohibits circumvention of "technological measures for the protection of audio, video and/or data content"

Also things like ad injection are not features for the end user.

RMTP is a proprietary protocol developed by Adobe so it's a good fit when you want to screw your customer with DRM and other stuff.


I don't disagree with your points however it's content owners who decided if content should be DRMed or not, not the end user. Thus you'd find videos delivered via any other protocol (Inc Bittorrent, if that ever became a commercial platform) would also be subject to DRM.

Similar point for as injection. You might consider it anti-user however in many cases ads are what pays the bills and thus in traditional "over the air" broadcastering it's actually more important to avoid down time during as as spots than it is during a programme airing because the cost of compensation is greater.

Ultimately in professional video delivery you'd have more than one type of customer; obviously you have the consumers watching the content but there is also the people paying for ad slots. Plus in many cases you wouldn't be the content owner so you'd have a third customer who is the person paying for your services to deliver the video.

So the features you might consider to be anti-user (and to an extent I don't disagree with you) are still there for paying customers. Or to out things a different way, video engineers would prefer not to add the complication of DRM and as injection into their infrastructure if they didn't have to.

As for RMTP being Adobe owned, there are other video delivery protocols around but RMTP tends to be the preferred platform for B to C (broadcaster to consumer). Or at least that is the case in the places I've worked. Eg it wouldnt surprise me if Apple / iTunes did their own thing.




Join us for AI Startup School this June 16-17 in San Francisco!

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

Search: