| > Live Video streaming is more or less an undeveloped field there is actually already a super successful P2P live video streaming implementation called PPLive that is BIG in China Indeed, so the situation is now for 'future of TV': - 1+ million of users of proven technology (PPLive) - patented technology after 5 years of dev work released (Bittorrent) - Open Source reference implementation of open upcoming IETF Internet standard (PPSP) > One interesting thing that Brams implementation does is actually speed up and slow down the playback of traffic depending on the latency > This is detailed in the patent but I did not see anything similar in the ppsp protocol.. Why link the network with the codec? From an architecture viewpoint I would consider this a 'layering violation'.
For many years VLC has support for dynamic playback speed:
http://forum.videolan.org/viewtopic.php?t=50581 Why is live streaming not more popular? In my opinion due to lack of quality. If we put the average upload capacity of Internet users at 800 kbps, that is the maximum donation you get. User donations limit the bitrate and quality of the live stream. Video quality at 800 kbps is unacceptable on HD laptop displays and 1080p televisions. As Prof. Keith Ross wrote many years ago: we need upload-view decoupling (http://cis.poly.edu/~ross/papers/VUDSystemMini.pdf). For HD quality live streaming with P2P, users need to donate also bandwidth when not watching. Unfortunately, going beyond T4T is an open scientific problem. Discaimer: I'm part of the PPSP streaming team.
Note that -02 is outdated, latest: http://tools.ietf.org/html/draft-ietf-ppsp-peer-protocol-06 Shameless plug; Open Source competitor: https://github.com/Tribler/libswift
Android view/inject client available |
How is that compatible with being live? To supply bandwidth for a live stream you would have to be downloading it simultaneously with uploading it, so if that node is not watching the video then it would be more efficient to have the node it's receiving from and sending to just connect directly.
I suppose if some subset of nodes can upload at a rate faster than the bitrate then you can gain some efficiency by consuming all of their available bandwidth, but unless those nodes have several times more upload bandwidth than the stream bitrate, that would tend to be pretty inefficient.
It seems like the better solution is just to increase the upload capacity for the average peer -- either through political pressure on the telcos to expand capacity, or through market pressure by just enforcing T4T and then offering both high and low quality streams but only offering high quality streams to the users with sufficient upload capacity to keep up with them, which would spur those who can to subscribe to a more expensive internet package with greater upload capacity.
>Unfortunately, going beyond T4T is an open scientific problem.
It seems like something bitcoin-like could work pretty well: Make it so that to get a download credit you either do some serious computation that requires a nontrivial amount of computing resources, or you upload to someone who has credits, and then they lose them and you get them. Which is basically T4T with accounting, except that it scales better because you can adapt to shortages and surpluses of credits by adjusting the amount of computing resources necessary to generate new credits.
It also solves the T4T bootstrap problem. Peers that newly join the network, or who had credits but spent them on something nobody else wants and so can't earn any upload credits because there is no one to download what they have, can crunch for credits instead of uploading and get back into the network.
Any reason you can think of why that wouldn't work?