# Icecast 2: a streaming media server for Ogg, WebM and legacy formats

> Icecast 2 is a C streaming media server that serves Ogg and WebM streams, including Opus, Vorbis and Theora, and can handle MP3, AAC and NSV in an unsupported legacy mode. It fits an operator running an internet radio station or a private jukebox, and it is not a transcoding front end for arbitrary input formats.

**xiph/Icecast-Server** — Icecast streaming media server (Mirror) - Please report bugs at https://gitlab.xiph.org/xiph/icecast-server/issues

- Repository: https://github.com/xiph/Icecast-Server
- Website: https://icecast.org
- Stars: 555 · Forks: 137
- Language: C
- License: GPL-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/xiph-icecast-server

## A server for streams you have already encoded

Icecast is a streaming media server, and the README frames the scope clearly: it is used to create an internet radio station or a privately running jukebox, and many things in between. The people it is written for are operators rather than end users, someone who has a source of audio and wants it delivered to listeners over the network. The project is deliberately open, and the README makes two claims about that openness: new formats can be added relatively easily, and the software supports open standards for communication and interaction. That combination is what distinguishes it from a hosted radio platform. The code is C, the licence is the GNU GPL version 2 with the text in the COPYING file, and the project lives with the Xiph Foundation, whose name appears in the repository address, the website and the mailing lists.

## Ogg and WebM are the supported formats, the rest is legacy

The format story is the first thing to understand, and the README is blunt about it. Icecast currently supports WebM and Ogg streaming, including the Opus, Vorbis and Theora codecs. It can also handle other streams such as MP3, AAC and NSV in legacy mode, but the README says this is not officially supported. That distinction decides what you can build on it. A station publishing Opus or Vorbis in an Ogg container, or video in WebM, is on the supported path. A station that receives MP3 and wants the server to handle it is on a path the project declines to stand behind, which in practice means you are running it without the promise of a fix when something breaks. The README also notes the server is very versatile because new formats can be added relatively easily, which is a statement about the extension points in the code rather than about the current format list.

## The six packages the build expects

The prerequisites are listed explicitly, and each one maps to a capability rather than being a formality. libxml2 and libxslt cover XML handling and stylesheet processing, curl is required at version 7.10 or later, ogg and vorbis are required at version 1.0 or later, and the project also needs libigloo and librhash. The curl requirement carries an important caveat. The README notes that Icecast may be compiled without curl, and that doing so disables Stream Directory server interaction, which is the mechanism by which a station announces itself in the directory of internet radio, and disables URL based authentication. So the optional dependency is optional in name only. The README also explains a practical point about packaging: most distributions ship a runtime package, but building from source needs the development package, with names that vary by distribution, such as a libxslt-devel style package.

## Building from a tarball or a recursive Git clone

The build follows the usual GNU sequence on a Unix platform, and the README gives the three commands:

```
    ./configure
    make
    make install  # as root
```

That is the procedure for the tar file, where the configure script already exists. If the code comes from Git, the README asks for a recursive clone, because the tree uses submodules:

```
    git clone --recursive https://gitlab.xiph.org/xiph/icecast-server.git
```

In that case the configure script has to be created first by running ./autogen.sh, and the same three steps follow. The install step is the one that needs root, and the README marks it as such in the comment. After installation, a sample configuration file is placed in /usr/local/etc on Unix, where the exact path depends on the PREFIX chosen at configure time, or in the current working directory on Win32, and it is called icecast.xml. The repository layout backs this up: there are separate directories for the source, the configuration files, the web interface, the Windows build, the tests and the continuous integration setup, with a configure.ac and an autogen.sh driving the autotools build.

## The sample icecast.xml and the documentation tree

The configuration model is a single XML file, and the distribution hands you a sample one rather than an empty file, which is the right starting point for a server whose misconfiguration means a silent stream rather than an error. The documentation lives with the source. The README says documentation for Icecast is available in the doc directory, by viewing doc/index.html in a browser, and that it is also installed to $PREFIX/share/doc/icecast/ so the documentation travels with the installed files rather than only existing in the checkout. Online documentation is on the project website. For a project of this age and size, the practical consequence is that a new operator should read the shipped documentation rather than a tutorial written elsewhere, because the shipped version matches the installed version, and the sample config carries the mount points, authentication and logging settings that have to be right before a listener hears anything.

## Bug reports belong on GitLab, not on this mirror

This repository is a mirror, and the project says so in the first line of its description: it is the Icecast streaming media server mirror, and bugs should be reported at the issue tracker on gitlab.xiph.org. Anyone who opens an issue or a pull request on the mirror is filing into a place that is not read by the maintainers, so the cost of the mistake is a bug that never gets triaged. The same pattern applies to the support channels the README lists: the Icecast mailing list for setup problems, with the address icecast@xiph.org, the developer mailing list for patches and development discussion at icecast-dev@xiph.org, and an IRC channel on the Libera Chat network. The repository is organised for that upstream workflow: a .gitlab-ci.yml drives the tests, a ChangeLog and a NEWS file track the history, and a tap-driver.sh script points at the test harness.

## GPL-2.0, a spelling rule, and the release record

The licence is the GNU General Public License version 2, and the README says a copy of it is included with the software in the COPYING file, which is present at the top level of the tree. That is a permissive-in-practice, copyleft licence, and the README does not add any commercial exception, so anyone embedding Icecast in a product should read the terms rather than assume. The README also insists on a trivial point with a surprising amount of emphasis: the name is spelled Icecast with a leading capital I and a lower case c, and any other spelling is incorrect. The release picture is that there are no GitHub releases here, because the mirror does not carry tags for distribution, and the repository is not archived with the last push on 2026-08-19. Upstream development happens on the GitLab instance named in the clone command, which is the address to watch if you want to know when a new version lands.

## Conclusion

Icecast fits an operator who already has encoded streams and needs a server that exposes them over open standards, either as an internet radio station or a private jukebox. It does not fit a pipeline that expects the server to transcode what it is given, since formats other than Ogg and WebM land in a legacy mode the project does not officially support. Verify first that your distribution has development packages for libxml2, libxslt, ogg and vorbis, and that you can accept losing the Stream Directory interaction and URL based authentication if you build without curl, then run the server against the sample icecast.xml rather than a hand written one.

## FAQ

### How do I build and install Icecast from source?

On a Unix platform the README gives the sequence ./configure, make and make install as root. From Git you should clone recursively and run ./autogen.sh first to create the configure script, and the build needs the development packages for libxml2, libxslt, curl, ogg and vorbis, plus libigloo and librhash.

### Which audio formats does Icecast support?

Icecast currently supports WebM and Ogg streaming, including the Opus, Vorbis and Theora codecs. It can also handle MP3, AAC and NSV in legacy mode, but the README states that this is not officially supported.

### What happens if I build Icecast without curl?

The README notes that Icecast may be compiled without curl, and that doing so disables Stream Directory server interaction, also known as YP, and URL based authentication. curl is therefore required at version 7.10 or later for those features.

### Where should I report a bug in Icecast?

This GitHub repository is a mirror, and the description directs bug reports to the issue tracker at gitlab.xiph.org/xiph/icecast-server/issues. For support there is the Icecast mailing list at icecast@xiph.org, and for development issues the developer list at icecast-dev@xiph.org.

## Sources

- [Issues](https://github.com/xiph/Icecast-Server/issues)
- [License: GPL-2.0](https://github.com/xiph/Icecast-Server/blob/master/LICENSE)
- [Project website](https://icecast.org)
- [README](https://github.com/xiph/Icecast-Server/blob/master/README.md)
- [xiph/Icecast-Server on GitHub](https://github.com/xiph/Icecast-Server)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xiph-icecast-server
