Icecast 2.0 Released

← Back to Stories (view on slashdot.org)

Posted by CowboyNeal on Friday January 9, 2004 @01:09AM from the internet-radio-made-easy dept.

ArcRiley writes "After 3 years of development and 6 weeks of beta testing, Icecast 2.0 has been officially released! Features include support for both MP3 and Ogg Vorbis, a web administration interface, support for listing in directories (such as dir.xiph.org), and is freely available under the GNU GPL for Linux and Windows."

6 of 152 comments (clear)

Min score:

Reason:

Sort:

Re:Icecast is great.. by nempo · 2004-01-09 01:15 · Score: 5, Informative

gnump3d -> http://www.gnu.org/software/gnump3d/

--
--- No, english is not my mother tongue.
Re:you can't listen to this in winamp, so who care by shione · 2004-01-09 01:24 · Score: 5, Informative

Only if you have Winamp 3 but why would you?

Winamp 2 and 5 support Icecast 2.0 OOB

http://www.icecast.org/3rdparty.php
Debian Install by rudabager · 2004-01-09 01:24 · Score: 5, Informative

Incase anyone cant fig it out, icecast is avialable for debian as "apt-get install icecast-server".

--
If I wanted easy I wouldnt be an engineer or a patriot.
Mirror by arvindn · 2004-01-09 01:53 · Score: 4, Informative

Mirror
Re:Alternative Ogg codecs? (with OggFile) by ArcRiley · 2004-01-09 04:06 · Score: 3, Informative

Monty is working on something called OggFile, which will be part of libogg2 (currently available in CVS). Basically, the goal is that OggFile will work alot like current proprietary systems (Real, Quicktime, etc) in that any program that uses OggFile will be able to transparently support any codec which OggFile supports (via plugins).
When OggFile becomes useable support for it will be added to Icecast, whereas we'll have support to stream Flac, Speex, Theora (video), any other Ogg codec available at the time. Also, with OggFile, source clients and media players will be able to support these codec combinations, whereas very few players currently support Speex or Flac streaming now.
You misunderstand how the rate control works by xiphmont · 2004-01-09 11:56 · Score: 3, Informative

It always worked properly; you misunderstand how the timing has to work.

When a connection is momentarily interrupted, the streaming server doesn't just stall the timing on the connection; it's still tracking how much data had to go out in a given period of time. The total output at any time will always be up to date. Thus, if the network connection is interrupted momentarily, the data will indeed burst forward to the correct point when connectivity resumes. It's like squeezing off a very stretchy hose for a short time.

The connection is dropped only if connectivity disappears for longer than a certain threshold. Oh, and naturally, if you're trying to listen to a broadband bitstream over a 28.8 modem, you're going to get kicked pretty quickly. The hose only stretches so far, and if it bursts your connection gets dropped. That's not a bug.

Also, a client that falls behind on its own will eventually burst the hose. That's a bug in the client; you won't fall further and further behind unless a) your playback rate is way off or b) your buffering is pooched. It's the client's responsibility to accept data at the rate the streaming server sends it. The streaming server's timing is correct; if something happens to mess with the client timing, the client has to deal with that.

As for 'flooding data at the beginning of a connection', that doesn't really make sense in a system where every client has a configurable, different sized prebuffer.

Monty