It's interesting that Bram (I assume it's still Bram's show over there) has finally gone with a new streaming-optimized protocol design. We argued about it years ago.
In the comments, "streamerp2p" is discussed, which I used as the basis for a proposal for live radio station streams along with Speex, back ~2005, when bandwidth was expensive. It's still around, apparently: http://www.streamerp2p.com/
Bittorrent itself can do streaming of static content: just request the blocks in order. It can also do streaming of live content if you chunk the live content and have an out-of-band way to update the torrent you're looking for, but that's not great.
In my proposal I mention some other systems as well:
Onion Networks' Swarmstreaming (defunct and blocked)
The proposal isn't worth posting any more; all the assumptions and business cases are obsoleted.
Today, rather than use a client at all, I'd probably push for WebRTC P2P support, funding patches in all the browsers and their mobile versions, incentivize people to upgrade their browsers, host with cheap bandwidth for everyone else, and just hold on until enough of the market has upgraded.
I agree with you that WebRTC is the obvious choice when it becomes available. It's simply too hard to get people to install a client. For users to install a client, the uses for it must be compelling enough to go through the trouble of installing an application. Dropbox is one example of how people will install software because the product offers something useful enough.
It seems like live streaming client programs simply don't have the critical mass of content available to force people to go to the trouble of installing specialized software.
The web is going to be a very exciting place indeed, once the webRTCPeerConnection.createDataChannel actually works and we can use application logic to send arbitrary payloads to peers over the internet.
Can someone create a WebRTC web app in this way, so one person can broadcast to millions through P2P technology? Or would the browser vendors need to make certain API's available before they can do that?
Once arbitrary data can be sent through peer connections via a browser javascript application, then there is no reason why the BitTorrent Live protocol (or some other similar P2P streaming protocol) could not work over WebRTC.
One difficulty I see is actually getting the binary data into a <video> element. It would be in theory possible to write to the file in the HTML5 FileSystem API and point the video element to it, but that would require transmitting the stream in a way that is ameliorable to seeming like a static video on disk.
A number of things have changed since I made that post. Streaming downloads are long since supported. Peoples's net connections are much faster than they used to be. Flash can be relied on to do playback. And I've just plain figured out a whole bunch of new techniques, reworking from the ground up, to actually get latency under control.
Here's Bram in 2004 arguing that live streaming is a niche market: http://bramcohen.livejournal.com/4294.html
In the comments, "streamerp2p" is discussed, which I used as the basis for a proposal for live radio station streams along with Speex, back ~2005, when bandwidth was expensive. It's still around, apparently: http://www.streamerp2p.com/
Bittorrent itself can do streaming of static content: just request the blocks in order. It can also do streaming of live content if you chunk the live content and have an out-of-band way to update the torrent you're looking for, but that's not great.
In my proposal I mention some other systems as well:
Peercast: http://web.archive.org/web/20060207013338/http://www.peercas... (defunct, Internet Archive link)
P2P-Radio: http://p2p-radio.sourceforge.net/ (defunct)
Allcast: http://web.archive.org/web/20060805040005/http://allcast.com... (defunct, Internet Archive link)
Chaincast (dead and blocked from IA)
Abacast: http://web.archive.org/web/20061017041905/http://www.abacast... (IA link, they're still around but now cloud-based)
Xiph's IceShare: http://wiki.xiph.org/IceShare (defunct)
Robert Haarman's StreamDist prototype: http://inglorion.net.nyud.net:8090/software/#streamdist
Andrew Brampton's research and prototype: http://web.archive.org/web/20100325135652/http://www.lancs.a... (IA link)
Onion Networks' Swarmstreaming (defunct and blocked)
The proposal isn't worth posting any more; all the assumptions and business cases are obsoleted.
Today, rather than use a client at all, I'd probably push for WebRTC P2P support, funding patches in all the browsers and their mobile versions, incentivize people to upgrade their browsers, host with cheap bandwidth for everyone else, and just hold on until enough of the market has upgraded.