Slashdot Mirror
Researchers Test BitTorrent Live Streaming
An anonymous reader writes "TorrentFreak reports that the Swarmplayer, developed by the P2P-Next research group, is now capable of streaming live video in true 4th generation P2P style using a zero-server approach. With a $22 million project budget from the EU and partners, the P2P-Next research group intends to redefine how video is viewed on the Internet. The researchers have launched a streaming experiment where you can tune in to a webcam in Amsterdam, or a 5 minute weather report (not live) from the BBC. More details about how to set up your own BitTorrent live stream are also available."
Its using BT so it must be piracy, right?
---- Booth was a patriot ----
Is this open source?
There's already a closed source p2p video system that was used, among other things, for the streaming of the Blizzard WWI event (Diablo III announcement). It's called Octoshape. How does this compare?
http://en.wikipedia.org/wiki/Octoshape
http://www.octoshape.com/
Not sure how smooth this would be, since BT usually sends packets in the order of availability, not how it streams... And I am not sure if it is a strange algorithm in my client or I am cursed, but the first file in a torrent is always the last to finish for me.
If you want broadcast, broadcast. Sending countless duplicates of the same data in unicasts is WASTEFUL!
I don't understand why people keep making this association!
Pirates HATE torrents. I can't even tell you how many beautiful vessels we've lost to the fuckers. Ugh.
Sincerely,
The Racketeering Industry Association of America
PS: RAmen.
The entire POINT of torrent-style protocols is to, not just handle, but take advantage of, the Slashdot effect.
The more participants in the torrent, the more robust it is. It is potentially faster for the new participants as well (though this depends on the dynamics of growth and the number of simultaneous downloads per playing node).
)The average latency will increase as the torrent grows. No way to avoid that.)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
They call it Zattoo
it's using encryptet contents over bittorrent.
My ADSL connection is 2.5Mbit out, 23Mbit in. It was 0.5Mbit/8Mbit until the local telco reciently upgraded some central. I can not send as much out as I take in, nor can most other Internet users. Thus; live video streaming will simply not work as long as the large majority simply can't send as much video out as they require in in order to view the video.
It really does not matter that it takes longer to download than it takes to view the video when viewing television series from tv-channels like eztv, which is why BitTorrent is so popular.
This BitTorrent streaming idea is great in theory and it will work great if we upgrade all end-user connections, backbones and so on. The future will be great! But I do not think the tubes are ready just yet.
9/11: Never forget it was a false-flag operation
First off 'broadcast' packets have poor meaning outside of a single layer2 network. In networking, broadcast means to send to everyone, whether they like it or not.
I presume you meant multicast, which is a bit more sane, but at the same time, I haven't been convinced that an at-scale situation would work with networks generally as configured today. I wager a good number of arbitrary routers out there would fubar multicast. This, of course, doesn't get rid of the duplicates, it moves some of the problem to the networking backbone a bit and still you end up with retries for the clients that missed pieces. For streaming, it's particularly interesting if a client misses a packet. Generally, when not dealing with real-time considerations, multicast clients save what they can, then at the end ask for pieces they missed. With streaming, that is going on all the time as a client can't wait til the ill-defined 'end' to be orderly.
Now, with all the networking infrastructure being pretty unicast tolerant, and not guaranteed much else, the p2p stuff makes some sense. Are there some inefficiencies on the host side, probably, but unicast is dead simple for networks to get correct.
XML is like violence. If it doesn't solve the problem, use more.
Apparently, I am watching a live stream in moderate resolution at full frame rate from the roof of a building in the Netherlands.
It works.
I cannot even begin to imagine the ramifications of this if it is adopted by the "pirate" scene. I know its been done with closed source software before, but none of them work as fluently as this trial is. Live streaming television of any channel in the world, or at least, anyone who wants to hook up a capture card, for starters.
I think we're watching the Internet change, fundamentally and dramatically, before our very eyes.
If you want broadcast, broadcast.
When the ISPs all support multicast in a compatible way (or even support it at all) we can switch over to that. Unfortunately many have not chosen to do that - at least so far. (Not surprising, since many of them are broadcast media conglomerates. Multicast-for-the-masses would enable their competition on a shoestring-budget level.) Meanwhile, live torrents do the same job for the users without additional support from the ISPs.
Yes it's not "efficient". But the main cost of the inefficiency falls squarely on the pocketbooks and infrastructure of the ISPs - the very people who have chosen not to provide the more efficient form of transport. How poetic.
Perhaps, as this begins to deploy and places an additional load on the ISPs' infrastructures, they will change their minds about promoting multicast and rush to deploy/enable it.
If they hurry they might head this off. If they wait until it's widely adopted they'll probably be stuck with it. Why should the users switch to something that's more efficient for the ISPs - but incompatible with what they're using now - when what they're using now does the job for themselves just fine?
So if the reduction in latency and upstream traffic from going with multicsast isn't enough to convince the users to switch, the ISPs will be stuck begging the authors to upgrade the code to use multicast distribution where available as a friendly gesture. B-)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
This is hilarious. The transport layer can theoretically handle this perfectly well, via UDP multicast.
But here we are, implementing a multicast-like streaming system higher in the stack to overcome the fact that most ISPs have disabled multicast at their routers. If something like this takes off, maybe this would actually encourage ISPs to enable multicast.
Also, I find this whole development awfully similar to the fact that many firewalls block everything other than HTTP on port 80, so now many apps have just moved to talking HTTP on port 80, or inventing pseudo-protocols on top of HTTP.
Ahhh, the Internet...