Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Networking Media

Researchers Test BitTorrent Live Streaming 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."
This discussion has been archived. No new comments can be posted.

Researchers Test BitTorrent Live Streaming

Comments Filter:
  • Arrgh Matey (Score:5, Funny)

    by nurb432 ( 527695 ) on Friday July 18, 2008 @05:02PM (#24248469) Homepage Journal

    Its using BT so it must be piracy, right?

  • Open source? (Score:5, Insightful)

    by jaxdahl ( 227487 ) on Friday July 18, 2008 @05:06PM (#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? (Score:5, Informative)

      by Anonymous Coward on Friday July 18, 2008 @05:24PM (#24248699)
    • Re: (Score:2, Interesting)

      by geogob ( 569250 )
      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)
      • > 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.

  • by houstonbofh ( 602064 ) on Friday July 18, 2008 @05:08PM (#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.
    • by Scotteh ( 885130 )
      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: (Score:2, Insightful)

        by vanDee28 ( 1198791 )
        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).
      • by Grey Ninja ( 739021 ) on Friday July 18, 2008 @05:41PM (#24248891) Homepage Journal
        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.
        • by camperdave ( 969942 ) on Friday July 18, 2008 @05:44PM (#24248933) Journal
          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.
          • by Bodrius ( 191265 )

            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 c

      • by SEWilco ( 27983 ) on Friday July 18, 2008 @11:25PM (#24251225) Journal
        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.

    • by Grey Ninja ( 739021 ) on Friday July 18, 2008 @05:14PM (#24248601) Homepage Journal
      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.
      • by molo ( 94384 )

        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

        • 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 attrib
        • by smoker2 ( 750216 )
          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.
        • 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.

          • by maharg ( 182366 )

            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.

            except in live streaming, the end of the file doesn't exist

            • If it's actually live, then the discussion is moot -- you can't seek through a live stream, either, as the index hasn't been built yet, but a good player should be able to at least play straight through, or generate its own index.

              If it's only "live" as in "a pre-recorded file that everyone's watching", then the end of the file (and the index) does exist.

              • by maharg ( 182366 )
                good point, well made, although I'd still like to see 'seek forward into future of live stream' in the next release ;o)
      • Re: (Score:3, Interesting)

        by DeadDecoy ( 877617 )
        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.
      • by Wildclaw ( 15718 )

        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 b

      • Very interesting concept, and I'm surprised nobody thought of it sooner.

        In fact, they did.
        http://www.peercast.org/ [peercast.org]
        http://p2p-radio.sourceforge.net/ [sourceforge.net]
        http://www.streamerp2p.com/ [streamerp2p.com]

        The only difference here is the budget. Not to be a prick, but I don't see anything inovative here. Except maybe the bittorent roots (22m for a modded BT client with an embbeded media player ? who's to say that a bittorent type algo is better than a p2p algo specifically designed for the task of streaming ?)
        This development will not change much. People prefer to have the files on their computer and build co

        • by njh ( 24312 )

          This development will not change much. People prefer to have the files on their computer and build collections, not stream them.

          I don't see how being able to watch a stream is incompatible from being able to save that stream to disk. I wonder what that 'save' button on the bottom right hand side does?

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

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

          Assuming the tracker can handle it.

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

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

      • Well, all they have to do is swarmcast their webpage, and voila, slashdot effect handled.
    • by Hatta ( 162192 ) on Friday July 18, 2008 @05:49PM (#24248973) Journal

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

      • by vanyel ( 28049 ) *

        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: (Score:3, Interesting)

          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 d

          • Re: (Score:3, Insightful)

            by vanyel ( 28049 ) *

            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: (Score:3, Funny)

        by Joe U ( 443617 )

        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.

        • by myz24 ( 256948 )

          Many don't understand it

        • by hatchet ( 528688 )
          Because it's very hard to get it to work correctly over NAT.
          • Re: (Score:2, Informative)

            by asnare ( 530666 )

            If I understand multicast (in particular IGMP) correctly, it is one of the few IP-related protocols where NAT is irrelevant.

            The real problem is that multicast requires routers to support it, and the vast majority don't. This includes both your ISP and most consumer modem/router devices. The main reason for this these days is due to what economists call network-effects. No pun intended.

      • Because every router in the route needs to support multicast. And ISPs turn off multicasting, so thats just not gonna happen.

    • by RayNbow ( 1328637 ) on Friday July 18, 2008 @06:45PM (#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.

      • by Wildclaw ( 15718 )

        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.

    • by Smauler ( 915644 )

      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.

    • by Jurily ( 900488 )

      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)

  • the future of how we do things.

  • by Anonymous Coward on Friday July 18, 2008 @05:13PM (#24248583)

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

    • by sveard ( 1076275 )

      That's 22 million

    • um...22 million. Three orders of magnitude lower. Lot of money, but still...3 full (decimal) orders lower.
    • Re: (Score:3, Informative)

      by Arterion ( 941661 )

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

      • by Junta ( 36770 )

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

        • 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 g

      • Maybe he meant multicast.

    • Not so simple.. (Score:3, Informative)

      by Junta ( 36770 )

      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 t

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

    • by Wildclaw ( 15718 )

      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.

  • 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.
  • Is it actually a standard torrent? How is this different from something like Peercast [peercast.org]?
    • by jd ( 1658 )
      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
    • by pembo13 ( 770295 )
      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 (Score:2, Interesting)

    by Anonymous Coward

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

    • Re:Already existing (Score:5, Informative)

      by freelunch ( 258011 ) on Friday July 18, 2008 @07:55PM (#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).

  • by xiando ( 770382 ) on Friday July 18, 2008 @05:44PM (#24248925) Homepage Journal
    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.
    • 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 appeal

    • 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.
    • 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
    • by josh82 ( 894884 )

      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.

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

    • 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.
  • It works. (Score:3, Interesting)

    by lkypnk ( 978898 ) on Friday July 18, 2008 @05:52PM (#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: (Score:3, Insightful)

      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 b

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

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

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

  • 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 ?
  • by cheekymatt ( 175255 ) on Friday July 18, 2008 @06:08PM (#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: (Score:2, Insightful)

      I'm just reply so that my signature is attached to this.
    • by Duncan3 ( 10537 )

      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: (Score:1, Interesting)

      by Anonymous Coward

      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

    • 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, bu

    • by aug24 ( 38229 )

      "The internet hates censorship, and finds ways to route around it"

      Dunno who said it, but your post demonstrates it really well.

      Justin.

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

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

A committee takes root and grows, it flowers, wilts and dies, scattering the seed from which other committees will bloom. -- Parkinson

Working...