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.
the future of how we do things.
It is pitch black. You are likely to be eaten by a grue.
If you want broadcast, broadcast. Sending countless duplicates of the same data in unicasts is WASTEFUL!
Does it authentically recreate the experience of searching for hours to completely fail to grab anything that I care about? Because, let me tell you, that is the only thing I'm looking for in media casts - only being able to download Britney's bare crotch shots at anything like a reasonable speed.
i was waiting for this technology to become available... now how long before webpage data is stored using a distributed bittorent network? and how long before wireless networks become available with roaming agreements for cell-phones?
I hear it's all over the alt.* newsgroups... better get it while you can!
Puh-puh-puh-PRIVATE tracker?
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
Is it actually a standard torrent? How is this different from something like Peercast?
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
Think of the children!
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.
US ISP's are throttling (oh, excuse me- giving the customer a "better experience") ordinary BT now. What are they going to do when this comes around to fruition? Will only Europeans be able to use it?
Firstly, you'd better hope that somebody is seeding the stuff you want to watch.
Also, is it really necessary to have an encrypted link to the streaming instructions ?
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
For those of us on university networks, it's another story though. If even like 10 people on a campus were watching a stream, they'd experience far better times than if they were streaming from a server. And of course, a sizable portion of the watchers could be on campus networks.
Also, though the majority of the internet is as you describe, the Internet 2 pipes running through universities mean that anyone on a college network effectively is living on the internet of the future.
So, though for fare appealing mostly to older viewers, yes, this isn't feasible. But if a reasonable number of students at a reasonably distributed number of universities are watching, they should have near real-time viewing, and anyone outside the network has a nearby server on a campus, which is far better than a single server farm that could be on the other side of the country. I don't know about the EU and Asian networks, or if those even would affect this too much.
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...
Yea but you can send out 2.5Mbit and thats more than enough to stream low-mid quality video. Sure your not going to be streaming some 1080 but its still a start. I thought shoutcast worked a little like this but i could be wrong.
What a shame. If they had hired me for one million dollar, I'd have told them that simply downloading the video is better than streaming it, so they could have saved $21 million.
They must have a pretty awesome job if they can watch a fetish amsterdam webcam during company time.
You're assuming your upload capacity must be sufficient to keep another viewer happy? Not necessarily. You only need sufficient upload capacity at the point where the stream originates. Everywhere else, each viewer can download some chunk of the stream from one peer, and other chunks from another peer. Say, 0.5 Mbit/s from 3 different peers, to view incoming 1.5 Mbit/s continuous.
For this to work for all viewers, only the total upload capacity (for all peers combined) needs to exceed the total of what's currently streamed to downloading clients. I think current networks are good enough for that to work, for a number of reasons:
Although limited, much of that upload capacity isn't used. There may be plenty users out there who don't mind streaming data to others, as long as it doesn't interfere with their own internet use. Also, they wouldn't be downloading all the time: if you watch P2P streamed video 2 hours a day, and you have your box switched on 8 hours a day, that leaves 6 hours a day where you can stream data out, while not using much up/down bandwidth yourself. This improves if you have a dedicated box, like an always-on BT download / MythTV box or similar.
Oh, and besides: a near DVD-quality DivX stream (~700M in 90 minutes) is just over 1 Mbit/s, so that would go easily as upload over your line. What you have as upload may appear limited, but still exceed what others have as download. And: there are better codecs than DivX today, and lower quality streams may be fine for many applications (compare the average YouTube vid).
They've been doing it for aaaaaaaaaaaages.
It's called "PPLive" and it's not great, but it works.
And it if works, wtf not?
You've got 1000000Mb down and 1Mb up? So what? Fuck you.
It's using maybe 2-4Mb/user/stream. If you have up even close to that and are watching the same video, you're probably adding a user to the pool. And that's how it works, and HAS for quite some time for Chinese users based in international locations.
Though as long as you leave your client open while you're not watching said video, you (in conjunction with others) will be providing more than enough upstream throughput to provide enough for other(s) downloading.
Enough people doing this consistently en masse is fairly unlikely, though. Tragedy of the commons and all.
So they got BitTorrent to do what VLC has been able to do all along? BFD. I think someone is drinking a little too much Kool-Aid. I can also do math in the sand with pebbles and sticks, but different isn't necessarily better. It's just a different way of solving an already solved problem. Weeeeee! When will this roller coaster of excitement end?!
7h3$3 4r3n'7 7h3 Ðr01Ð$ ¥0 4r3 £00|{1n9 f0r. M0v3 4£0n9. --OB1
Your logic is flawed. So long as your upload is enough to serve a stream or few, which for compressed video I think 2.5MBPS is, the torrent system would work just fine. You don't need to be maxing out your downstream constantly.
CAPTCHA is deliver.
if this could run in a browser without people having to install it, say as a Flash applet. The problem I see is that Bittorrent has its scaling issues already - popular torrents (which should in theory be faster) take forever to download.
So, Swarmplayer does video playback using VLC. You can see all the relevant files in the Swarmplayer install directory. Of interest to me is this in the plugins: libdvdread_plugin.dll.
As far as I'm aware, the DVD reading bit of VLC isn't quite legal in the US in some fashion or other. I don't think downloading it is a problem, but the VLC FAQ advises one to consult a lawyer.
I, myself, use VLC already anyway, but I think folks should probably know. Or maybe some of the extra plugins should be stripped out of this VLC install.
These systems have been running like this for years... http://en.wikipedia.org/wiki/PPLive for more info an links but... This really isn't news. Maybe that it uses the "official" BitTorrent protocol, but, erm, that's a pretty minor detail. "Peercasting"
The player doesn't look like it supports seeking (or it wasn't working), and the audio is out of sync.
What's so exciting about this "research"? Peercast has been around for over 6 years now. I was watching streaming P2P video with it myself, a good 4+ years ago. It's based on the Gnutella protocol rather than BT, but in the case of sequential live streams, the difference is sure to be minimal, anyhow.
Despite having much more focus on audio, I count 15 video channels listed in the YP right now... Peercast is open source as well.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
For instance, my Virgin Media cable has upstream of about 7kbytes/second (yes, seven kilobytes) and downstream of 230kbytes/sec. Woot! Anyone want to calculate how many peers will be needed to watch real-time video? I am not really knocking Virgin Media, they are doing a real good job, for instance their email service has a whopping 30Mb limit (this is for _all_ sent and received, not 30Mb filesize). And all for the low low Virgin Media price of $36 per month.
Oh, and they traffic shape, and inspect all your packets and report filesharers.
As soon as a rival company digs the whole country up and lays cable, I will be tempted to switch suppliers.
They whose government reduces their essential liberties for temporary security, receive neither liberty nor security.
When I first discovered BitTorrent, I implemented a protocol called streamdist, which does something like this. It allows streaming of data to an arbitrary number of clients with only a single client getting the data from the server.
Of course, streamdist was just a primitive proof of concept, but this story sounds like I missed out on a couple of millions in funding.
Oh well.
Please correct me if I got my facts wrong.
Of course you could never achieve your full download capacity an a swarm composed by people with similar connections. The average download speed will come down to maybe your upload speed, maybe more depending on how many users leave the client running after watching.
A two hour movie / two CD movie encoded with Xvid that comes in at 1.6Mbps should be watchable on your connection - and that's already pretty decent quality. The quality could go near-HDTV if AVC is used and a speed of 4-5 Mbps is possible.
Remember that intelligent Bittorrent clients reward other clients that give them chunks. So on your 2.5Mbps upload you could participate in a HDTV torrent, while someone with 5Mbps/512kbps could not, although apparently he would have enough bandwidth. People with weak uploads will just disconnect, frustrated by the jerky video.
All this is theoretical, and has to be tuned in a an actual implementation. For example, it's very clear that tit-for-tat comes in conflict with the fast buffering a streaming-bittorrent client must exhibit.
With 5Mbit down I can download a recently released 350MB tv show avi in about 15 minutes. Though this does depend on the shows demographics and popularity. This is easily fast enough to watch while it's downloading, you just need a client that will prioritise blocks that need to be shown soon.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
2.5mbit/s video is very high quality already. It's double the DVD quality and on its way towards HD quality. So consider a p2p streaming system that lets people with at least 2mbit/s upload tune in, that's at least good enough to have DVD quality, basically the same quality as all those DivX movies you can find on the Internet.