Comment by bbarrows | Hacker News Reader

Comment by bbarrows | Hacker News Reader

After working for Bittorrent (I recently left for job that fit me a little better) on the Live team for almost two years (more so on all the software supporting the actual core protocol itself which Bram himself works on mostly..) it is awesome to see Live finally being released to the public. I cannot wait to see how the public will use it (I am sure anyone with an imagination can think of a thousand ways a P2P Live streaming protocol could be useful and powerful..). It will be interesting to see how usable people find it and if they end up adopting it or sticking with the current RTMP server client style architecture.

One thing I always found interesting while working on Live is that although in some ways it really seems like 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 ( http://en.wikipedia.org/wiki/PPLive ).

Another interesting thing to check out if this Live Video streaming stuff interests you is that some guys proposed a Live Video streaming protocol VERY similar to Live's sometime recently:

http://tools.ietf.org/html/draft-ietf-ppsp-peer-protocol-02

Just compare the BitTorrent Live Protocol and this proposal..

One interesting thing that Brams implementation does is actually speed up and slow down the playback of traffic depending on the latency and whether or not Live figures you need to buffer more or can afford to have less of a delay/buffer. Talk to Bram and you'll quickly figure out he is obsessed with low latency..

This ends up being funny in implementation too, as you will notice when watching a stream that the playback will speed and slowdown while you watch it...

This is detailed in the patent but I did not see anything similar in the ppsp protocol..

> 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

I actually was just trying to provide some context and show that there are already some well developed P2P live video streaming solutions around.

I am not trying to say BitTorrent Live is proven or correct in anyway.

By saying that Live does that funny playback thing and PPSP dosen't I was not trying to say that I think it is correct or that that particular feature belongs in the network protocol at all. Just trying to point out a feature that I thought was interesting and unique to Bram's implementation.

PPSP and LibSwift both look like amazing, well developed and thought through projects made by very talented individuals. It blows me away how the ppsp protocol really takes everything into account (huge fan of the NAT traversal section in that draft..)

>For HD quality live streaming with P2P, users need to donate also bandwidth when not watching.

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?

Bitcoin pretty much requires that everyone in the network be aware of all the transactions, to make sure no one can double-spend. I guess the overhead for using a broadcasted transaction for every T4T iteration would be quite large, but maybe that could work. An interesting thought anyway, thanks for bringing this up.

Reply on news.ycombinator.com