Calling All Broadcasters(blog.bittorrent.com)
blog.bittorrent.com
Calling All Broadcasters
http://blog.bittorrent.com/2012/11/20/calling-all-broadcasters/
Do you have a Ustream channel? A justin.tv following? A webcam, and a dream? Do you want to help invent the next generation of live streaming? Cool. We’re looking for people like you.
18 comments
There's a lot of times that I'm watching something on YouTube that's broadcast live (like presidential debates) when I wish there was a less corporate, ad infested version where it was available. I think a P2P solution for events like this would be really cool. I've seen BitTorrent live evolve over the last few years and it's really beginning to mature. It still hasn't seen a swarm at that kind of scale, though.
I never understood why torrent clients are not built into browsers and the defacto means of download. Would be huge cost savings.
Opera has (had?) one built in. The difficulty is the necessity of hashing the entire file. Torrents are great for snapshots of large files.
I think one of the reasons the torrent protocol is not built-in is that it's simply more complicated and the user experience is not as good.
Or perhaps it is because there is a certain stigma attached to using a technology that enables distribution of data, even when it is against the wishes of the creator of the data.
I think one of the reasons the torrent protocol is not built-in is that it's simply more complicated and the user experience is not as good.
Or perhaps it is because there is a certain stigma attached to using a technology that enables distribution of data, even when it is against the wishes of the creator of the data.
Note to anyone planning on using Opera's client: it's terrible, out of spec, and banned on many bittorrent sites.
I don't think the complexity and user experience issues are completely intrinsic to the protocol - BitTornado (sadly, another client that misbehaves, and hasn't been updated in 6 years) was hands-down the easiest for less techy people to use and understand. (Each download has its own window and instance of the program, making it look and feel very similar to downloading in Internet Explorer)
Why do you say the difficulty is in hashing the entire file? BitTorrent divides the files into small chunks and hashes those, so downloading lots of small files vs downloading one big one doesn't make a lot of difference
(with a few caveats - some clients support an additional hash on each file, which can save you re-downloading data if two files share a block and only one is changed, and some clients add padding data so there is only one file per block. In practice, these are both very rare)
I don't think the complexity and user experience issues are completely intrinsic to the protocol - BitTornado (sadly, another client that misbehaves, and hasn't been updated in 6 years) was hands-down the easiest for less techy people to use and understand. (Each download has its own window and instance of the program, making it look and feel very similar to downloading in Internet Explorer)
Why do you say the difficulty is in hashing the entire file? BitTorrent divides the files into small chunks and hashes those, so downloading lots of small files vs downloading one big one doesn't make a lot of difference
(with a few caveats - some clients support an additional hash on each file, which can save you re-downloading data if two files share a block and only one is changed, and some clients add padding data so there is only one file per block. In practice, these are both very rare)
[deleted]
> I think one of the reasons the torrent protocol is not built-in is that it's simply more complicated and the user experience is not as good.
That's self-fulfilling - if it were built into the browser, there's no reason you'd really have to know.
(Presumably you wouldn't run into the "zero-seeders" problem if the servers acted as seeders - they're currently serving 100% of the file anyway (without torrenting), so torrenting would only reduce that.)
That's self-fulfilling - if it were built into the browser, there's no reason you'd really have to know.
(Presumably you wouldn't run into the "zero-seeders" problem if the servers acted as seeders - they're currently serving 100% of the file anyway (without torrenting), so torrenting would only reduce that.)
I'm not sure it would be so much a net gain in cost savings so much as moving those costs around to the users and local ISPs who'd upstream traffic would increase. Personally I'd rather the content providers eat those costs.
I remember reading about a P2P API inside Chrome, but that may have been just an experimental mode for WebRTC at the time. Having a built-in bittorrent technology would be a big addition to browsers, especially if they intend to use the technology for broadcasts to a lot of people in the future through WebRTC.
It seems like in about 6 months or so (crystal ball reading) this will be available in chrome stable. (createDataChannel is not yet implemented even in Chromium trunk)
It's already possible to participate in BitTorrent swarms in pure javascript with only websockets and typed arrays. (https://github.com/kzahel/jstorrent) It of course requires that BitTorrent clients know how to accept websocket connections and use websocket frames to emulate raw socket data (which is not yet the case, but very well could be)
It's already possible to participate in BitTorrent swarms in pure javascript with only websockets and typed arrays. (https://github.com/kzahel/jstorrent) It of course requires that BitTorrent clients know how to accept websocket connections and use websocket frames to emulate raw socket data (which is not yet the case, but very well could be)
BitTorrent is associated almost exclusively with piracy, and the protocol is actively blocked on many networks.
It also chokes networks - an open seeding torrent client significantly increases latency, even with the number of connections limited.
It's a problem we have in my house with Spotify, which utilises P2P to lower costs - it has a negative effect on anyone else who is gaming.
It's a problem we have in my house with Spotify, which utilises P2P to lower costs - it has a negative effect on anyone else who is gaming.
Doesn't qos alleviate that, though?
Check out Torque, tiny torrent client in the browser written in Javascript:
https://github.com/bittorrenttorque/btapp
https://github.com/bittorrenttorque/btapp
It's actually not written in the browser. It's a javascript API that interfaces with a headless local process (communicating with AJAX over 127.0.0.1. It has issues with mixed secure-content warnings, though)
I'd like to see people streaming demonstrations etc using this.
And then others could make the stream more resilient.
I installed the client in Debian and live.bittorrent.com worked well with Chrome at least.
Once I see open source clients and streamers, then I'll be really excited.
And then others could make the stream more resilient.
I installed the client in Debian and live.bittorrent.com worked well with Chrome at least.
Once I see open source clients and streamers, then I'll be really excited.
I hope YouTube et al are asleep at the wheel long enough for this to take control of large scale live events away from them - the Baumgartner jump, the debates, it'd be nice to see these handled by P2P technology...
Well, maybe. In reality they really only need their hands on the control channel (whatever that is here) and can leave the bulk data delivery to peer-to-peer routing like the internet was designed for.
Seems like a viable solution for a lot different content producers. NASA included:
http://nasaweb.ideascale.com/a/dtd/Cut-Costs-By-Using-BitTor...
http://nasaweb.ideascale.com/a/dtd/Cut-Costs-By-Using-BitTor...
Maybe this way they won't get their video taken down for copyright infringement next time they land something on another planet.
Bittorrent always makes me think about transfer-capped Internet connections. It feels like even wireline-based Internet connections in the USA are moving toward being transfer-capped. I don't see how Bittorrent works in that world.
This seems like a very useful tool for people who cannot afford big servers.
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.
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.
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.
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.
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.
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.
Possibly the MediaSource api, which allows writing to media elements: http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/m...
It may be necessary to paint it via canvas, however that opens up a can of worms that completely bypasses the video element.
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.
http://www.sopcast.com/
mac/win/nix/droid. we use it around olympics/world cup time. nix client is open source, anyone know an open source server?
mac/win/nix/droid. we use it around olympics/world cup time. nix client is open source, anyone know an open source server?
The Linux client is not open-source afaik.
Seems to be https://launchpad.net/sopcast-player
Is this not the sort of thing IP multicast is for?
IP multicast is turned off on the Internet.
Depends on which bit of the Internet - the BBC transmits (or at leat used to) live streams via Multicast to a number of UK ISPs.
Can this be further developed to replace Facetime and Skype? /cross fingers.
Facetime and Skype and Hangouts are mostly for 1-1 communication or small group communication. I think the aim for this is to enable anyone to a live broadcast to as large an audience as they wish. Like justin.tv, or ustream
There is a 10 year old PeerCast that does (or was intended to do) something very similar. The only difference, which is crucial, is that BT sits on a massive userbase that they may be able to repurpose for bootstraping their project... Though Skype was in a similar position and look how well their Vienna Project is doing (it's dead).
Where's the linux client? Where's the source for the client?
if I get it right, BitTorrent live is a centralized server with a proprietary (?) client?
I don't think that's the lesson to take from BitTorrent.
I don't think that's the lesson to take from BitTorrent.
AFAIK, the centralized server is not a strict necessity in terms of the functionality of the core protocol. It is more of a business decision to require the central server to authorize the stream (I believe each stream has a key that must be signed by the central server). This way, DMCA can be respected and liability issues are less of a concern.
Stream Torrent works pretty well too.
http://stream-torrent.en.softonic.com/
http://stream-torrent.en.softonic.com/
windows only, and disclaimers about it being unsupported on that site.
I love the idea, I'd like to stream but I have about 256kb/s of upload speed and using TwitchTV or so it's impossible.
I'm super excited by this but where are the specs?
streemig for freedom, long live the live-bittorrent.