Talk:IceShare

From XiphWiki

(Difference between revisions)
Jump to: navigation, search
(Iceshare vs peercast)
Line 90: Line 90:
Mostly what we need, at this point, is to finish hashing out the details on the hash functions (ok, a little pun intended) and the anonymous identity challenge, and to get libogg2/OggStream to the point where all this stuff is seamlessly useable.
Mostly what we need, at this point, is to finish hashing out the details on the hash functions (ok, a little pun intended) and the anonymous identity challenge, and to get libogg2/OggStream to the point where all this stuff is seamlessly useable.
 +
 +
== Iceshare vs peercast ==
 +
 +
I recently set up a little peercast network on a trial basis. Everyone has UK-standard ADSL/RADSL connections which are  uncapped 512/256 kbit/s with 50:1 contention. The source stream is a 64kbps Ogg/icecast stream (actual rates vary, of course).
 +
 +
Performance has been very variable, with many users reporting long interruptions as it pre-buffers, but not consistently. I haven't been able to identify the problem although my instinct is that it is caused by bandwidth contention; the popularity of BitTorrent means that the typical spiky email-websurfing bandwidth usage pattern which informed the 50:1 contention architecture of DSL systems no longer applies - although whenever I test the bandwidth available to me I get a figure in the high 400's.
 +
 +
As I understand Peercast, with its relay architecture, anyone in the chain suffering this problem will cause difficulties for those further down the line (please correct me if I'm wrong, I often am).  Thus popularity doesn't increase the available bandwidth, it just doesn't reduce it as direct streaming does. It seems to me that the BitTorrent - swarming approach will scale much better than peercast; at least I'm hoping..

Revision as of 13:23, 22 January 2005

. --Anonymous
As far as I can tell.... IceShare is better than Peercast for a number of reasons.

Firstly, IceShare doesn't depend on a central server. Peercast depends on yp.peercast.org in order to function properly. Yes this is true, and recently peercast has become organised this way. Which i dislike.

Secondly, Peercast requires that you run the peercast client on each machine. If IceShare will be a library then lots of media players will be able to simply "play" a stream. People will just need a player that can do icet://

Thirdly, IceShare is based on ogg. If you look at yp.peercast.org you will find lots of formats. Most of the streams are not using open codecs. For example the video streams, there is just ONE theora stream, while the rest are WMV/NSV.


... --2003/11/21 13:36 EST
yo xiph: quit doing so much cool stuff, you make me feel worthless.

Killer app? --2003/11/22 14:06 EST
I can't see any competition :D

re: Killer app? --2003/11/28 18:39 EST
take a look at peercast http://www.peercast.org/ (be shure to disable ECN ;) ) it's working already!

keep the work going!

Wow, wow, wow! --2003/12/01 21:04 EST
Wow, I was talking to my Bro about this idea a few months ago, and how it could change the world. I was talking about video, but Audio is a good start!


It will do video. --ArcRiley, 2003/12/10 01:52 EST
IceShare will work for any Ogg codec, including Theora. In fact that's one of the uses I intend to test it with.


hmm --BlindWanderer, 2004/01/05 10:47 EST
Swarming streaming would work but i don't think it would catch on. But it still should be made. It would help guarantee freedom of speech/press in this world of censorship.

... --2004/01/12 01:33 EST
Video might end up being the killer app. Hosting an audio stream is expensive, it is still feasible. Hosting a video stream, on the other hand, rapidly becomes unaffordable. This project could make it affordable to broadcast high-quality video streams to a large audience


Where's the download link? --2004/01/19 22:35 EST
?????????????????????

Work in progress --ArcRiley, 2004/02/04 08:25 EST
This is currently in the "pre-alpha experimental and design" phase. We have some software, mostly for testing, and the protocols are still being altered slightly or extended as we need to. Don't worry, we'll make a big media splash if/when we get to beta release phase.

... --2004/01/21 22:38 EST
will it be posible to listen to a radio with winamp?, i mean no need for a special player? how coul we broadcast? using a special program?

Winamp --ArcRiley, 2004/02/04 08:27 EST
Short answer; when someone writes the software for this, and then only after we've finalised the spec. WinAMP will need a plugin, but that is all. The intention of IceShare is for it to be integrated closely with the media player, so not only should icet:// links open your media player directly, but things such as seeking should work seamlessly. As for broadcasting software, that's left completely up to implementation. Icecast support should be written eventually so any standard Icecast2 server can be used, but anyone could write a direct IceShare streaming client. Let's focus less on vaporware, right now we're concentrating on the spec, not integration with media players.

local relay --Andy Baxter, Sept 2004
Seeing as it might take a while for plugins to be written for all the players, how about making a local relay program for the main platforms which uses the iceshare library to provide a local http or rtsp relay, which players can connect to? This would also do as a reference implementation of the library for plugin coders. If the right protocol was used, it could handle seeking etc as well.

misinformation --2004/03/01 11:17 EST
I think you may have been misinformed about PeerCast, we're using it as the core of our media player and are streaming static files with it. Security was a concern for us so we added a very simple SKEY signature to broadcast packets that allows clients to verify each packet has not been modified. Although we haven't submitted patches to the PeerCast developers yet. Also our client is "allowed" to connect o to the main PeerCast network, in fact the developers have been very eager for us to do that.

Conferencing --AlexanderWinston, 2004-03-03 00:00 UTC
Might this have possible tele- or videoconferencing uses?

Dead Project --2004/11/09
Was a great idea, too bad it never took off.

Don't Assume -- 2004/11/19
The wiki just hasn't been maintained, work is happening behind the scenes. Be patient.

2004/11/19 I am very glad to hear this news! I am looking for something just like this & this looks very promising. I have started an internet radio station and am looking for a way to expand the stream once the audience exceeds my server capacity.

I know nothing of writing code but could beta test or write a "how to" article.

Peercast & IceShare - ZephyrXero - 2005/1/7
I've been wishing for a project like this for about a year now. I just discovered Peercast the other day, and now this. I'll be very excited to see where the IceShare/IceTracker stuff goes. I've been in love with everything ogg since I found out about it.

My question is, since IceShare & Peercast are open source projects... do you plan to share code from each other? What kind of collaboration has happened, if any...so far? Can't wait for the beta of IS to be released. I see huge potential for P2P streaming a/v in the near future.

Re: Peercast & IceShare - Arc 2005/1/10
I'm not sure how code sharing would help us. The systems are radically different in both theory and implementation.

Mostly what we need, at this point, is to finish hashing out the details on the hash functions (ok, a little pun intended) and the anonymous identity challenge, and to get libogg2/OggStream to the point where all this stuff is seamlessly useable.

Iceshare vs peercast

I recently set up a little peercast network on a trial basis. Everyone has UK-standard ADSL/RADSL connections which are uncapped 512/256 kbit/s with 50:1 contention. The source stream is a 64kbps Ogg/icecast stream (actual rates vary, of course).

Performance has been very variable, with many users reporting long interruptions as it pre-buffers, but not consistently. I haven't been able to identify the problem although my instinct is that it is caused by bandwidth contention; the popularity of BitTorrent means that the typical spiky email-websurfing bandwidth usage pattern which informed the 50:1 contention architecture of DSL systems no longer applies - although whenever I test the bandwidth available to me I get a figure in the high 400's.

As I understand Peercast, with its relay architecture, anyone in the chain suffering this problem will cause difficulties for those further down the line (please correct me if I'm wrong, I often am). Thus popularity doesn't increase the available bandwidth, it just doesn't reduce it as direct streaming does. It seems to me that the BitTorrent - swarming approach will scale much better than peercast; at least I'm hoping..

Personal tools


Main Page

Xiph.Org Projects

Audio—

Video—

Text—

Container—

Streaming—