![]() So you'd end up having to build your own infrastructure there, which would be a great deal more expensive. Plus many services will use a commercial CDN, none of which current support bittorrent. You'd have to rely so much in your own data centre that you'd loose the benefit of bittorrent. If it isn't you back it up from a datacenter. ![]() > Doesn't really matter, it is fast enough. After that it used its own torrent-like system to continue and pre-fetch the next song. When a user clicked play (or seeked to a different part of the song) the first (if I remember correctly) 15 seconds was fetched from their CDN. A live webcam for a tourist resort should be fine, a sports event, maybe not. Not sure, but if a minute is acceptable delay (depends on what is being broadcasted) it should be feasible. > It couldn't support live services where the video data is being generated near real time No, you start streaming from the datacenter. > Time to start playing a new stream is longer (which end users might care about) Buffer 2 minutes, if some chunk is missing when 20 seconds remains pull it from a datacenter instead. There are torrent clients that do this already. > You have no guarantee that chunks will arrive in the right order to actually stream data (ie the end of the file might download first) ![]() You only have to have a small map between play time and file offset for the different streams, the client will then pick whatever it wants. I can write more in this if people are interested) > You cannot send multiple different video qualities in the same stream and have the client dynamically pick the right bitrate for their connection (this is what current streaming services do and why you often see Netflix / Prime video / etc switch between quality mid-stream without having to restart that stream. Shouldn't be any real difference in reliability. > It's less reliable (same reason as above) > It's slower to deliver video since you're reliant on upload connections of end usersÄoesn't really matter, it is fast enough. However for delivering other kinds of assets - such as patches to computer games - protocols conceptually similar to bittorrent are used. The current methods for video delivery are actually really good, bittorrent would be a major step backwards. * It couldn't support live services where the video data is being generated near real time * Time to start playing a new stream is longer (which end users might care about) * It's harder to debug network problems if you are experiencing issues with video quality (been in enough stressful emergency meetings with network guys over the years - I can't imagine how much worse it might have been if we couldn't do a full end to end trace of the delivery) * You cannot send multiple different video qualities in the same stream and have the client dynamically pick the right bitrate for their connection (this is what current streaming services do and why you often see Netflix / Prime video / etc switch between quality mid-stream without having to restart that stream. * You have no guarantee that chunks will arrive in the right order to actually stream data (ie the end of the file might download first) * It's less reliable (same reason as above) * It's slower to deliver video since you're reliant on upload connections of end users The issue with using it for Netflix isn't privacy, it's that bittorrent is simply not any good for streaming video content when compared with current technologies already used by streaming broadcasters.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |