Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Researchers Test BitTorrent Live Streaming

ScuttleMonkey posted more than 6 years ago | from the pirating-without-the-pesky-evidence-trail dept.

Networking 129

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."

cancel ×

129 comments

Sorry! There are no comments related to the filter you selected.

Arrgh Matey (4, Funny)

nurb432 (527695) | more than 6 years ago | (#24248469)

Its using BT so it must be piracy, right?

UGH (5, Funny)

pxc (938367) | more than 6 years ago | (#24248835)

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.

Re:Arrgh Matey (3, Funny)

dreamchaser (49529) | more than 6 years ago | (#24250639)

Indeed. I am waiting for a P2P technology that is so stealthy, nobody knows it even exists. Then I can be a Ninja and not a Pirate.

Re:Arrgh Matey (1)

speilberg0 (1144645) | more than 6 years ago | (#24251377)

And yet if you are the only person to know about said P2P tech, then there will be no peer on the other end to share / dl from

Open source? (4, Insightful)

jaxdahl (227487) | more than 6 years ago | (#24248517)

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 [wikipedia.org]
http://www.octoshape.com/ [octoshape.com]

Re:Open source? (2, Interesting)

geogob (569250) | more than 6 years ago | (#24248801)

I've been using octoshape for quite while now. Although the concept is interesting and the image quality is fairly good compared to analogue-SDTV, the system doesn't behave flawlessly.

Quite often, the systems simply doesn't work. At some point, the client kept its connection up on the P2P network. Of course, this happened while I was out of town (I'm not the single user of the system) and didn't catch the issue until I came back home. In 3 days, it ate over 60% of my HS cable internet cap (100 GB up+down).

Re:Open source? (1)

Hurricane78 (562437) | more than 6 years ago | (#24249021)

> my HS cable internet cap (100 GB up+down).

There's your problem. ;)

Truly no cap here in Germany. At least I know huge p2p users that never hit any potential limit.
I hope that soon you can get a cap that is so large that it becomes irrelevant.

Re:Open source? (2, Insightful)

geogob (569250) | more than 6 years ago | (#24250835)

Canada's not the best place to have a decent communication plan.

I see some issues here... (5, Interesting)

houstonbofh (602064) | more than 6 years ago | (#24248543)

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.

Re:I see some issues here... (1)

Scotteh (885130) | more than 6 years ago | (#24248595)

Also, how would sharing work? Would the video be automatically seeded when it's done being watch? The article says it's a "zero server" method, so it couldn't be relying on numerous servers to increase streaming speed. I don't want to watch a video and then have it take up my bandwidth to seed for a while.

Re:I see some issues here... (2, Insightful)

vanDee28 (1198791) | more than 6 years ago | (#24248665)

This system seems more usable for topset boxes than internet, in the long run. So your bandwith woudn't be affected. Assuming your internet connection is a differtent internet connection from your digital tv (as it is here in the netherlands).

Re:I see some issues here... (3, Interesting)

Grey Ninja (739021) | more than 6 years ago | (#24248891)

I just installed the player and watched the videos. I'm running Linux, so it might work different in Windows (probably not a whole lot different though). When you open up the torrent with their player, it essentially functions like a normal bittorrent client, with a lot of automation. It will buffer for a bit, and then open up VLC (or whatever your default player is?) and start playing the stream. You don't actually see a list of all the torrents you are currently distributing, but it saves them to a cache somewhere, and seeds them even after you are done watching them. It just sits in the system tray and does its thing. Which is probably a necessity for this to work.

Re:I see some issues here... (3, Informative)

camperdave (969942) | more than 6 years ago | (#24248933)

So, like all torrents, only the popular stuff will play well. I'm not going to get a stream of Tales of the Gold Monkey in anything like real time.

Re:I see some issues here... (1)

Bodrius (191265) | more than 6 years ago | (#24250869)

As an exclusive P2P solution, that would be the case.

But what would really be interesting is seeing this complemented with other distribution schemes - even if it were just a matter of allocating guaranteed peers dynamically.

I could see this lowering the barrier of entry for scalable on demand video (as in iptv, not video blogs) - which can make things really interesting.

It would allow a startup content provider to stream, and scale, to a very large audience without breaking the bank... and - given decent competition - ensuring adequate service for unpopular content in your catalogue would be good for business, if not plain necessary.

Re:I see some issues here... (3, Informative)

SEWilco (27983) | more than 6 years ago | (#24251225)

There is no "video", there is but a stream.

In the example, the streaming is actually taking place from 15 minute pieces. When enough of the current piece has been collected, the video starts playing on your machine. While you're watching the stream, the rest of the 15 minute piece is collected and shared. The next 15 minute piece is collected/shared when it appears. A while (I don't remember if it was 15 or 30 minutes) after you saw it, the older pieces are deleted from your machine.

This is similar to how some Internet radio streams work. You're actually listening to a bunch of short streams encoded in some audio format. The major difference here is that a slightly modified BitTorrent protocol is being used.

Re:I see some issues here... (5, Interesting)

Grey Ninja (739021) | more than 6 years ago | (#24248601)

You can set priorities on the files, and your client will request those pieces first. In a streaming situation, I would imagine that everyone's client would be set to prioritize the chunks in order. Which I think would actually probably work really well. Everyone's client would become really bottom heavy as they watched the movie, and download speeds would start out really fast, and gradually taper off. If you had enough clients, I would imagine that it wouldn't be an issue.

Very interesting concept, and I'm surprised nobody thought of it sooner. It could start a new p2p video service like the world has never seen. Instead of taking 2 hours to download the movie, then watching it, you can watch any movie on pirate bay, right now. The trick is just that everyone needs to be using a streaming client.

Re:I see some issues here... (1)

molo (94384) | more than 6 years ago | (#24248735)

Also the video file format itself has to support streaming. MPEG-2 would be fine. AVI wrappers would not work too well, as there are indexes or some such at the end of the file.

-molo

Re:I see some issues here... (1)

Grey Ninja (739021) | more than 6 years ago | (#24248845)

Actually, I just watched the BBC weather report, and it was in an AVI. VLC was a little confused when it started playing it, and asked if I wanted to repair it, but I declined, and it played it anyway.

The live streaming video didn't work all that great on my computer. Reason is probably that my internet connection right now is very substandard. The BBC weather report actually worked really well. It stuttered a little bit when it started, but as it went on, it never did it again. I would again attribute this to my internet connection more than anything. But it was smooth as silk after the first little bit.

Re:I see some issues here... (1)

smoker2 (750216) | more than 6 years ago | (#24248945)

Well xvid streams fine in an avi container. Drag this link [headru.sh] to your media player. Works fine using xine on FC4 and vlc on xp.

Re:I see some issues here... (0)

Anonymous Coward | more than 6 years ago | (#24249159)

Has anyone used Vuze [google.com] ? it works farily well, and does stuff kind of like this. You find a video you want to watch, cick play, then it starts downloading and begins to play as soon as enough of it is downloaded. It does not work that way for all file formats, but it works farily well for the content thats on there.

Re:I see some issues here... (1)

SanityInAnarchy (655584) | more than 6 years ago | (#24249773)

You could always have the torrent client compensate for that, too -- the indexes aren't that big. Just have the client fetch the end of the file first.

Re:I see some issues here... (2, Interesting)

DeadDecoy (877617) | more than 6 years ago | (#24248779)

Hmmm...I wonder how long it will be then, until we see isp's whining about how we're clogging up their inter-tubes. If the wait time to view a streaming video is reduced, I imagine that it will increase the preference or desire to see such a video online versus not watching it or seeing it through some other medium.

Re:I see some issues here... (1)

Wildclaw (15718) | more than 6 years ago | (#24251197)

In a streaming situation, I would imagine that everyone's client would be set to prioritize the chunks in order.

The key here is to maintain a good balance between earlier blocks that are more immediatly needed and later blocks that are less common and therefore easier to trade.

and download speeds would start out really fast, and gradually taper off

The biggest misconception of bittorrent is that seeders are somehow what makes it good. That couldn't be further from the truth.

Bittorrent is about using trading to ensure that you get bandwidth equal to what you give. This can only be done while you are actually downloading. When you have finished downloading, good netizens will usually seed back as much as they downloaded, but the problem is that seeders have little possibility of differentiating between people who share and leechers beyond using statistics from before they become a seeder (which I don't know any client that does).

In a swarm with only downloaders and no seeders and where the swarm as a whole have access to the whole file, each client should optimally download at the same rate as they upload. With a low upload rate you will simply not be able to download very fast.

There are ways to encourage seeding back what you take. The simplest way is what bittorrent trackers use, getting the statistics from each client and using that to determine ratios. This can however be cheated. Also, ratios are only useful in bittorrent situations where you are willing to ban those with bad ratio.

Allowing clients to track other clients in the long term is another more technical way to handle it. E-mule is known for this and technologically a good example. Still, as the e-mule priority system has been implemented in a way to discourage trading, which basically conflicts with the whole point of using credits in the first place, it is not a good practical example.

Re:I see some issues here... (1)

pouwelse (118316) | more than 6 years ago | (#24248627)

It works now, but can it handle the Slashdot effect?

The detailed statistics on their page [p2p-next.org] indicate "viewing quality: 99.79% pieces played, 0.21% lost.

It seems that the testers use broadband that can handle the 600 Kbps requirements + this algorithm is holding.

With front-page coverage the next 24h will be a make or break I guess...

The entire POINT is to handle slashdot effect (2, Insightful)

Ungrounded Lightning (62228) | more than 6 years ago | (#24248867)

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.)

Re:The entire POINT is to handle slashdot effect (1)

SanityInAnarchy (655584) | more than 6 years ago | (#24249903)

The more participants in the torrent, the more robust it is.

Assuming the tracker can handle it.

Re:The entire POINT is to handle slashdot effect (1)

Hyperspite (980252) | more than 6 years ago | (#24250563)

Well the point is that the tracker can handle requests much more efficiently than a full on fileserver. While that doesn't give you an unlimited amount, its still waaaay better than a traditional server when you're getting hit hard.

Re:The entire POINT is to handle slashdot effect (1)

SanityInAnarchy (655584) | more than 6 years ago | (#24250633)

Well the point is that the tracker can handle requests much more efficiently than a full on fileserver.

Yes, I understand how BitTorrent works.

its still waaaay better than a traditional server when you're getting hit hard.

And it's still going to implode when you're Slashdotted if you're not careful.

It's not as bad as hosting that file locally, but it may well be as bad as hosting a webpage locally. When websites get hit, they still get Slashdotted, so I have every reason to expect that most torrents would.

Re:I see some issues here... (1)

camperdave (969942) | more than 6 years ago | (#24248871)

Well, all they have to do is swarmcast their webpage, and voila, slashdot effect handled.

Re:I see some issues here... (4, Insightful)

Hatta (162192) | more than 6 years ago | (#24248973)

Why don't they just use multicast? This is what it was designed for.

Re:I see some issues here... (1)

vanyel (28049) | more than 6 years ago | (#24249213)

multicast requires that everyone be watching it at the same time. What I don't understand is why everyone keeps trying to s..t...r.e...a....m stuff over the internet. Maybe you don't have to have the disk space to cache it, but give me a quality download any day...

Re:I see some issues here... (2, Interesting)

SanityInAnarchy (655584) | more than 6 years ago | (#24249939)

multicast requires that everyone be watching it at the same time.

If it's a live stream, isn't that a given?

Otherwise, it could follow the same model as pay per view -- start a new multicast session every hour or so.

And assume it isn't a stream -- Multicast is still an advantage. Imagine they simply replay it over and over, at a reasonable download speed -- then bandwidth costs are close to zero, for everyone involved.

What I don't understand is why everyone keeps trying to s..t...r.e...a....m stuff over the internet.

Two reasons.

First, if it's actually live, it kind of has to be a stream. Otherwise, well, it wouldn't be live. Kind of the point, and that one's a "duh".

I don't care for most things, but it's not difficult to imagine wanting audience participation, or simply putting up a live stream of whatever's going on in a particular area right now -- thus, whenever you tune it, it's there, but no point even caching it on the server.

Second, it helps protect against piracy. Well, not really, but it means you have to reverse engineer the app doing the streaming and/or the protocol, not just a file sitting somewhere in the cache.

Re:I see some issues here... (2, Insightful)

vanyel (28049) | more than 6 years ago | (#24250187)

OK, RTFA ... Uggh. p2p'ing 1 minute buffers. What a hack. But the problem with multicast is that it requires isp support (which I know *we* don't have setup, and I doubt many do or are willing to do --- it's hard enough to get people to think about ipv6 and it has a lot more compelling justification), or non-trivial tunnel setup, where as this just works as is. On that basis, I have to admit grudging admiration for cleverness, but ugggh! It's still s..t..r.e.....a.m...i.n.g...

Re:I see some issues here... (3, Funny)

Joe U (443617) | more than 6 years ago | (#24249231)

Mod parent down. Proper use of Internet protocols (except HTML) is frowned upon here.

Seriously, for some reason people don't like multicast, I really don't know why.

Re:I see some issues here... (1)

myz24 (256948) | more than 6 years ago | (#24251085)

Many don't understand it

Re:I see some issues here... (4, Informative)

RayNbow (1328637) | more than 6 years ago | (#24249389)

Standard BitTorrent works because of the Tit-For-Tat incentive mechanism. The whole idea is that a peer exchanges pieces with another peer, so it can achieve a higher download rate than just getting pieces from the seed.

Now, I won't go into details, but the reason you get your files in some arbitrary order is because a BitTorrent swarm is just like a marketplace. Certain pieces are rare and might have long queues, i.e. many peers are interested in it and are competing for it. Other pieces are so common, most peers are not interested in it and can thus be exchanged with fewer peers. So the trick to achieving high download speeds is to obtain the right pieces that are still valuable for further trade, while not spending too much time on obtaining such a valuable piece.

Now, with video-on-demand (and live streams), the whole Tit-For-Tat system no longer works. In this situation, peers must obtain pieces in order for playback. The problem now is that a peer that wants the next minute of the video can only get it from a peer whose playback position is further ahead. The latter peer however is not interested in pieces from the former (since it already has these) and thus no exchange will take place.

So, the solution the Tribler team came up with is the Give-to-Get incentive mechanism. A peer will only receive pieces from others if it sends its pieces to those that are interested, i.e. peers that have seen even less of the video. This requires some feedback, so a peer that receives some pieces will have to inform others that it recently has received data from a certain sender. Thus, you could say that the Give-to-Get incentive mechanism is based on reputation.

Re:I see some issues here... (1)

Wildclaw (15718) | more than 6 years ago | (#24251279)

Now, with video-on-demand (and live streams), the whole Tit-For-Tat system no longer works. In this situation, peers must obtain pieces in order for playback.

Not completly true. With video-on-demand it is enough that you get the occasional later piece that you can trade for more common earlier pieces. Of course, as clients are prioritizing the earlier pieces the tit-for-tat will be less efficent. Not useless though.

Still, give-to-get is is a natural extension of tit-for-tat when you are seeking to improve trading efficency and can't rely on evenly distributed information among peers.

Re:I see some issues here... (1)

Smauler (915644) | more than 6 years ago | (#24250179)

I don't know which client you're using, but most BT clients allow you to specify file priorities now (I use uTorrent). Seriously, if you can't prioritise individual files within your client, it's time to get a new client.

Re:I see some issues here... (1)

Jurily (900488) | more than 6 years ago | (#24250691)

Any video file above 60% plays well in mplayer.

However none of those are meant for streaming, and above all else, not via torrent. Torrents are not for sequential viewing, period.

(At least, not while downloading)

Welcome to (1)

TheDarkener (198348) | more than 6 years ago | (#24248557)

the future of how we do things.

$22 billion for what? (3, Insightful)

Anonymous Coward | more than 6 years ago | (#24248583)

If you want broadcast, broadcast. Sending countless duplicates of the same data in unicasts is WASTEFUL!

Re:$22 billion for what? (1)

sveard (1076275) | more than 6 years ago | (#24248715)

That's 22 million

Re:$22 billion for what? (0)

Anonymous Coward | more than 6 years ago | (#24249025)

Sorry, I got carried away. It is one thing when people who have no influence over the implementation of multicasting look for a substitute, but no grant money should be wasted on realtime P2P distribution. That's just dumb.

Re:$22 billion for what? (1)

liquiddark (719647) | more than 6 years ago | (#24248745)

um...22 million. Three orders of magnitude lower. Lot of money, but still...3 full (decimal) orders lower.

Re:$22 billion for what? (2, Informative)

Arterion (941661) | more than 6 years ago | (#24248865)

You realize that even traditional "broadcast" (e.g. streaming from youtube) has to send countless duplicates of the same data, right?

Re:$22 billion for what? (0)

Anonymous Coward | more than 6 years ago | (#24249015)

(e.g. streaming from youtube)

That is not broadcasting at all.

Re:$22 billion for what? (1)

Junta (36770) | more than 6 years ago | (#24249017)

He did explicitly call out unicast, which youtube is doing. He's not advocating the likes of youtube, or even saying this isn't an improvement. He's saying that networking explicitly designed multicast as an architecture for 'getting it right'. On a theoretical level, I have to see his point, on a more pragmatic level, good luck fixing all the stuff in the middle instead of just the endpoints..

Re:$22 billion for what? (1)

Arterion (941661) | more than 6 years ago | (#24249179)

Right, but there really isn't a broadcast solution available right now. So if we think of "wasteful" as a relative term, neither way is more wasteful than the other.

Actually, with P2P, smart ISP's could keep peers on their side of the fence, and not have to clog up the tubes connecting them to others. I don't remember if that's what Sandvine is supposed to do or not, but I remember reading about it somewhere.

Of course, we could all use a proxy server to the same effect, but I don't think anyone wants to go through the hassle. ISP's could also do some advanced sort of caching, but that's a legal can of worms I'm sure they don't want to get into.

Re:$22 billion for what? (1)

paulthomas (685756) | more than 6 years ago | (#24249393)

Maybe he meant multicast.

Re:$22 billion for what? (0)

Anonymous Coward | more than 6 years ago | (#24250431)

When hell did "traditional broadcast" have anything to do with Youtube? What are you 11 years old?

Not so simple.. (2, Informative)

Junta (36770) | more than 6 years ago | (#24249001)

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.

Re:$22 billion for what? (1)

FlyingBishop (1293238) | more than 6 years ago | (#24249037)

Strictly speaking, that's why BitTorrent is a good thing: You only send duplicates to nearby nodes, who in turn send it to other nodes. In the broadcast model, huge amounts of bandwidth are eaten up by the host sending out the same data to every client, in its entirety. Making clients share the burden reduces the strain on the network, because clients can get the data from the nearest node. Unless that's what you meant, I'm not sure why you were modded insightful.

Re:$22 billion for what? (0)

Anonymous Coward | more than 6 years ago | (#24250057)

If you only know unicast, you will implement only unicast solutions. TV is broadcast. Radio is broadcast. There is one sender, one signal, many receivers. The internet doesn't do "broadcast", but multicasting ("subscribed broadcast") is a possibility. Instead of wasting money on unicast kludges, they should use the money to promote the implementation of multicasting.

Well that depends on the ISPs, doesn't it? (2, Insightful)

Ungrounded Lightning (62228) | more than 6 years ago | (#24249097)

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-)

Re:Well that depends on the ISPs, doesn't it? (0)

Anonymous Coward | more than 6 years ago | (#24250117)

It is much more likely that the ISPs will complain and then the millions of dollars which have been invested in P2P streaming will be rendered useless by new legislation which prevents users from engaging in such P2P networking. ("We need to be allowed to throttle this traffic so that the users of our VoIP product don't suffer...") Those 22 million dollars are money down the drain, plain and simple.

Re:Well that depends on the ISPs, doesn't it? (1)

Ungrounded Lightning (62228) | more than 6 years ago | (#24250789)

It is much more likely that the ISPs will complain and [provoke] legislation which prevents users from engaging in such P2P networking.

Oh, I'm sure they'll try that.

But by the time it gets to that point there will be a lot of users of live feed swarms. Unlike file sharing, it will be a lot harder for the networks to claim that they're all pirates stealing "content" and thus deflect the users' counter-lobbying efforts.

At that point the politicians will count the money from the ISPs and the votes from the users. I suspect the outcome will be more user-friendly than it has been for file transport.

Re:$22 billion for what? (1)

Wildclaw (15718) | more than 6 years ago | (#24251325)

Multicast would work very well with incredibly popular streams. If a 1000000 people in a country are watching something it makes perfect sense.

However, when you have a 1000 streams with 1000 people watching each it no longer makes as much sense. WHen the clientele becomes spread out enough the efficency wins from multicast is countered by the restrictions it imposes.

Looking for quality kiddie porn (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#24248589)

Any good leads?

Come on! I know someone here knows!

Re:Looking for quality kiddie porn (0)

Anonymous Coward | more than 6 years ago | (#24248787)

I hear it's all over the alt.* newsgroups... better get it while you can!

Only the latest and greatest (1)

liquiddark (719647) | more than 6 years ago | (#24248727)

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.

Can you say... (1)

pxc (938367) | more than 6 years ago | (#24248813)

Puh-puh-puh-PRIVATE tracker?

sweet (0)

Anonymous Coward | more than 6 years ago | (#24248775)

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?

How is this different? (1)

grishnav (522003) | more than 6 years ago | (#24248907)

Is it actually a standard torrent? How is this different from something like Peercast [peercast.org] ?

Re:How is this different? (1)

jd (1658) | more than 6 years ago | (#24249043)

The summary says it's 4th generation. Most bittorrent clients are in C or Java, not Forth. (Ok, that was bad. But even so, I'd call bittorrent a first generation true peer-to-peer protocol, same with Gnutella and ED2K. Freenet, Tor and X-Bone might be considered second generation, and that's a push, but there frankly isn't anything out there I'd consider third generation, never mind fourth. You need to have something that is significantly different to qualify for a whole generation in tech jargon, which is why even the latest multi-core multi-way hybrid architecture CPUs are not considered to be running millionth-generation languages.)

Re:How is this different? (1)

pembo13 (770295) | more than 6 years ago | (#24250851)

I don't see how you can be on slashdot and not think of one area where it must be different by yourself. Hint: torrents don't normally download the first part of a file first, and people tend to watch things from the start.

Already existing (2, Interesting)

Anonymous Coward | more than 6 years ago | (#24248915)

They call it Zattoo
it's using encryptet contents over bittorrent.

Re:Already existing (0)

Anonymous Coward | more than 6 years ago | (#24249431)

btw there once was a mplayer plugin for the alternate http source including cracked encryption
it never made it into main, because of coding style
see here http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2007-March/050179.html [mplayerhq.hu]
worth an efford because of grown number of channels and true bittorrent source

Re:Already existing (4, Informative)

freelunch (258011) | more than 6 years ago | (#24249967)

They call it Zattoo
it's using encryptet contents over bittorrent.

I watched the World Cup Futbol championship on Zattoo [zattoo.com] and it was sometimes more "real time" than broadcast TV. How do they do that? This bittorrent prototype buffers for a full minute. And I notice the live stream isn't even doing any sharing (according to the status page).

Maby a good idea for the future, forget it today (4, Interesting)

xiando (770382) | more than 6 years ago | (#24248925)

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.

Re:Maby a good idea for the future, forget it toda (1)

FlyingBishop (1293238) | more than 6 years ago | (#24249113)

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.

Re:Maby a good idea for the future, forget it toda (1)

FamineMonk (877465) | more than 6 years ago | (#24249149)

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.

Upload is capped, but mostly unused (1)

Alwin Henseler (640539) | more than 6 years ago | (#24249471)

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).

Re:Maby a good idea for the future, forget it toda (1)

josh82 (894884) | more than 6 years ago | (#24249659)

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.

Re:Maby a good idea for the future, forget it toda (0)

Anonymous Coward | more than 6 years ago | (#24250171)

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.

This will lead to child porn! (0)

Anonymous Coward | more than 6 years ago | (#24248995)

Think of the children!

It works. (3, Interesting)

lkypnk (978898) | more than 6 years ago | (#24249011)

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.

Re:It works. (0)

Anonymous Coward | more than 6 years ago | (#24250863)

Well, start worrying. The internet age is bringing to "the mainstream" streaming Youtube videos, which are compressed and low quality, but ubiquitous, in a way.

If you want the next step up, at this point, without paying for 25MB fiber connections, you need to download or cache movies. It will take long for today's 50% broadband (United States, a firs world country w/ 300 million inhabitants) to modem home-user ratio to catch up to near 100%. When that is done, picture a new layer of waiting and infrastructure rebuilding for it to catch up to fiber.

On the same side of the bandwidth battle, we got packet shaping, net neutrality and HDTV content from television and camcorders that will be heavier to upload to sites uncompressed (2012 is the year the US plans to force channels to transmit in HD over the air.) And let's not talk about having to hack TV's and DVD's just to get this content out --the new police-state reality will kick in so slowly you won't even notice the DRM. Does anyone even notice XP and Vista's activation schemes anymore ? but I digress.

The point is, if you think content will get easier to stream, you're wrong. Those streaming television aren't quite legal now. When HD kicks in worldwide as a mainstream (I give it 15 years at least) we'll have only slightly better DSL networks, but several times more data to move. And the police force is getting stronger by the year. "Bandwidth waste" trees will be chopped off by the root.

Youtube's days are numbered too, be it by HD bandwidth costs in the far future, or copyright madness catching on, or some kind of blanket bandwith police thing coming from every ISP... Just look at the Usenet vs. child porn article on the /. frontpage.

Re:It works. (1)

FamineMonk (877465) | more than 6 years ago | (#24251371)

I'm pretty sure google is smart enough to change with the times. They could write like a youtube client that did the same thing. Sure there might be a little more waiting time before the loading of the video but i think people would be ok with it for the quality.

Re:It works. (2, Insightful)

SanityInAnarchy (655584) | more than 6 years ago | (#24251301)

I cannot even begin to imagine the ramifications of this if it is adopted by the "pirate" scene.

That's because there really aren't any.

Ramifications, that is. Seriously, piracy is all about redistributing existed content. What would we have a live stream of, PirateBryan's ass?

Live streaming television of any channel in the world, or at least, anyone who wants to hook up a capture card, for starters.

Any show that people care about is online within an hour of airing. Maybe two.

And this wouldn't be as reliable as a straight download, either -- a straight download can die for a few minutes, and you lose nothing. You can download something in three hours that has a running time of two hours, for better quality. But this has to be realtime, and it's going to be hurt by the asynchronous/throttled nature of most connections.

I think we're watching the Internet change, fundamentally and dramatically, before our very eyes.

I think that's a vacuous statement -- the kind of thing a PHB or a politician would say to make himself sound in touch.

The Internet is always changing. It's always dramatic, and often fundamental -- or never fundamental, depending on how you look at it (we still use TCP, IP, UDP, ICMP...) That's the nature of the beast.

Moore's Law, and similar properties -- simple raw numbers changing, in terms of bandwidth, storage, processing power, and mobile power/size/weight/features/battery life -- all of these proceed, for months or years at a time, simply making our lives easier.

Then, suddenly, someone realizes that this extra capacity has made something new possible. Suddenly, the Internet is ubiquitous enough that Google Docs is acceptable. Suddenly, bandwidth is fast enough that YouTube is possible. Suddenly, Google has enough sheer CPU hours to do a search engine via voice recognition.

There are other ways in which change happens, but it is the nature of the beast for technology to change.

In other words, what you just said is roughly equivalent to this. [xkcd.com] I'm not so much disagreeing with you as saying "Duh!"

So no, I don't think that "streaming BitTorrent" will be that earth-shattering. It will be cool -- it might even become as cool as YouTube. But if you have some perspective, YouTube is hardly the biggest thing that ever happened to the Internet.

Will this ever be usable in the US? (1)

LM741N (258038) | more than 6 years ago | (#24249083)

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?

Re:Will this ever be usable in the US? (1)

lattyware (934246) | more than 6 years ago | (#24249249)

Europeans? I don't know if you are aware, but Europe is not generally that great either. Some places have it good, but the UK, for example, has worse connectivity than the US by a long shot, and they throttle and traffic shape.

Re:Will this ever be usable in the US? (1)

SanityInAnarchy (655584) | more than 6 years ago | (#24251319)

Given that it appears to be actually using BitTorrent (though I don't know for sure), I suspect it'll be no better (or worse) than ordinary BitTorrent.

2 things (1)

smoker2 (750216) | more than 6 years ago | (#24249089)

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 ?

Interesting parallels (5, Insightful)

cheekymatt (175255) | more than 6 years ago | (#24249143)

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...

Re:Interesting parallels (2, Insightful)

Relic of the Future (118669) | more than 6 years ago | (#24249245)

I'm just reply so that my signature is attached to this.

Re:Interesting parallels (0)

Anonymous Coward | more than 6 years ago | (#24249873)

Hmm, I'm running a SSH listener on port 80 on one of my servers, so I can always get to my own machines. Quite annoying really.

Re:Interesting parallels (1)

Duncan3 (10537) | more than 6 years ago | (#24250279)

Shhhhh! They charged then 22M for something they think is new. It's hard to pull off a scam of that scale these days.

How often can you charge that much for something that's available on Wikipedia?

Re:Interesting parallels (1, Interesting)

Anonymous Coward | more than 6 years ago | (#24250977)

This is hilarious. The transport layer can theoretically handle this perfectly well, via UDP multicast.

Correct. Except for the fact that it is not just theoretical problem they're fixing. You forget that

1) they want a "serverless" medium for their lowered accountability in case of copyright violations (and the downloaders for "anonymity" due to the same thing)

2) UDP doesn't ensure delivery. /.ers testing this say there's little drops on this. UDP doesn't give you that. Realplayer UDP-casting for videos died a long time ago. Video streaming is mostly flash and WiMP. Mainstream people are suckers for dropped-frame-free videos linked to these concepts: "delivery" and "guarantee". Note that pauses for buffering don't count as dropped frames. Your next frame comes right after the pause... guaranteed ;)

3) Most importantly: lack of "repeat" bandwidth costs. Owner seeds once, and people download several times the cost of that seed at the expense of the buyers/users. Without torrenting you transmit the whole movie every time a new downloader comes aboard your UDP swarm. Money talks

Re:Interesting parallels (1)

SanityInAnarchy (655584) | more than 6 years ago | (#24251347)

If something like this takes off, maybe this would actually encourage ISPs to enable multicast.

Given that they haven't done this with BitTorrent -- that they've decided to throttle it instead -- I wouldn't get my hopes up.

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.

I haven't seen a lot of that with desktop apps, but I will say two things:

First, read up on REST. There are many things for which HTTP actually isn't a bad idea.

Second, I think most of this isn't done because of firewalls. I think it's done either because people like HTTP/REST, or because they're forced into it by browsers. I'm not sure if XMLHttpRequest limits things to Port 80, but it certainly insists on sending real HTTP, rather than implementing anything resembling a real socket API for web apps.

Download is better (1)

aaaaaaargh! (1150173) | more than 6 years ago | (#24249167)

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.

Nice job (0)

Anonymous Coward | more than 6 years ago | (#24249203)

They must have a pretty awesome job if they can watch a fetish amsterdam webcam during company time.

Come to China! (0)

Anonymous Coward | more than 6 years ago | (#24249491)

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.

Re:Come to China! (1)

SanityInAnarchy (655584) | more than 6 years ago | (#24251357)

No offense, but as it looks like there's a (somewhat) English version, I'd rather stay here. Things aren't looking good for net neutrality in the US, but it's not quite sunk to Golden Shield [wikipedia.org] status yet.

So what. (1)

Doomedsnowball (921841) | more than 6 years ago | (#24249859)

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?!

What would be really great... (0)

Anonymous Coward | more than 6 years ago | (#24250239)

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.

Legal Status (0)

Anonymous Coward | more than 6 years ago | (#24250261)

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.

PPLive / PPStream / et cetera (0)

Anonymous Coward | more than 6 years ago | (#24250465)

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"

It's only a test, but... (1)

Memroid (898199) | more than 6 years ago | (#24250615)

The player doesn't look like it supports seeking (or it wasn't working), and the audio is out of sync.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>