Robbinaer

Noch immer verwenden viele Webradios den alten Shoutcast-1.x-Server, obwohl dieser seit mindestens einem Jahrzehnt nicht mehr weiterentwickelt wird. Ein Grund hierfür könnte die teilweise vorhandene Inkompatibilität auf Hörerseite sein, bedient man sich alternativer Streaming-Plattformen. Vor allem das Verbreiten neuer Streaming-Links an sämtliche Portale dürfte eine nicht unerhebliche Zeit in Anspruch nehmen. Bis alle Links aktualisiert sind, muss man zwischenzeitlich wohl mit einem Hörerschwund rechnen. Dank des quelloffenen Streaming-Servers Icecast gibt es aber Abhilfe.

Das Problem mit den Ports

Erinnern wir uns zurück: Ein Shoutcast-Stream baute sich in der Regel aus Hostname und Port auf. Hatte ein Webradio mehrere Streams, etwa um verschiedene Qualitätsstufen für mobile und stationäre Nutzung anzubieten, lief für jeden dieser Streams eine eigene Shoutcast-Instanz. Shoutcast2 und erst recht Icecast nutzen hingegen das umgekehrte Prinzip. Statt für jeden Stream eine eigene Instanz zu starten, werden viele Streams als sogenannte Mountpoints auf einem einzigen Server gehostet. Hierbei handelt es sich im Grunde um Dateinamen, welche dem Stream-Link angehängt werden

Ein Stream-Link setzt sich dann also nicht nur aus Hostname und Port zusammen, sondern erfordert auch die Angabe des Mountpoints. Aus http://example.com:8000 entstünde demnach http://example.com:8000/meinradio.mp3. Alle alten Links wären folgerichtig ungültig. Zwar könnte man sich generell mit universellen Playlist-Dateien behelfen, welche auf der Webseite eines Radios gehostet werden und immer die aktuellen Streaming-Links enthalten, doch eine hundertprozentige Garantie, dass Hörer und Webradio-Portale tatsächlich am Ende auch nur diese Dateien abgreifen, besteht natürlich nicht.

Weicher Übergang mit Icecast-Weiterleitungen

Zum Glück ist die Icecast-Konfiguration hier sehr flexibel anpassbar. Sie bietet die Möglichkeit, durch sogenannte Alias-Weiterleitungen einen Stream so auszuliefern, dass er sich im Player der Hörer wie der altbekannte Shoutcast-Stream verhält. Es können sogar mehrere Ports geöffnet werden, und jeder dieser Ports liefert einen eigenen Stream aus, obwohl weiterhin nur eine einzige Server-Instanz aktiv ist. Angenommen, wir hätten ein Radio mit zwei Streams - einer für hohe, der andere für niedrige Qualität. Die relevante Konfiguration sähe dann etwa so aus:

In der Standardkonfiguration des Icecast-Servers existiert bereits ein Port, welchen wir auch so belassen:
<listen-socket>
    <port>8000</port>
</listen-socket>


Direkt darunter werden auf die gleiche Weise zwei weitere Ports definiert:
<listen-socket>
    <port>8002</port>
</listen-socket>
<listen-socket>
    <port>9000</port>
</listen-socket>

Zur Erklärung: Port 8000 und 8002 sind die angenommenen Ports der alten Shoutcast-Streams. Port 9000 soll hier exemplarisch als Basis für die neuen Streams nach der Übergangszeit dienen. Nun müssen wir nur noch über die Alias-Funktion im Abschnitt <paths> die zuvor definierten Ports ihrer gewünschten Funktion zuführen. Die bereits vorhandene Alias-Zeile muss zuvor kommentiert oder am besten gelöscht werden, da sie sonst die restlichen Aliase unwirksam machen würde.

Port 8000 liefert einen Stream mit hoher Qualität aus:
<alias source="/" port="8000" destination="/radio192kbps.mp3"/>

Port 8002 soll einen Stream für mobile Nutzung ausliefern:
<alias source="/" port="8002" destination="/radio64kbps.mp3"/>

Port 9000 liefert die übliche Status-Seite des Icecast-Servers mit allen verfügbaren Streams aus:
<alias source="/" port="9000" destination="/status.xsl"/>

Abschließend noch den Icecast-Server neustarten, und die Konfiguration sollte wie gewünscht funktionieren.

Das Ergebnis

Wir haben nun zwei Ports (8000 und 8002), bei deren Aufruf unterschiedliche Streams ausgeliefert werden. Port 9000 hingegen liefert die Icecast-typische Statusseite aus, und man kann von dort sowohl den auf Port 8000, als auch den auf Port 8002 verfügbaren Stream per direktem Mountpoint abrufen. Die so erzeugten Streams sollten auf allen Playern funktionieren, und als Webradio kann man sich in Ruhe Zeit zum allmählichen Umstellen der Streaming-Links lassen. Natürlich können die Links auch einfach im alten Format belassen werden, dies beeinträchtigt die Funktion des Servers in keiner Weise. Bis vor kurzem kannte ich diese Möglichkeit selbst noch nicht, da sie in der offiziellen Icecast-Dokumentation scheinbar nirgendwo erwähnt wird. Lediglich eine allgemeine Information zu Alias-Weiterleitungen ist dort aufgeführt.

Wie man einen Icecast-Server mit Inhalten versorgt, ist dann natürlich Sache des Radiosenders. Streaming-Clients, welche das Icecast-Protokoll sprechen, sind aber weiter verbreitet als jene, die das neue Shoutcast2 beherrschen. Auch Anbieter kommerzieller Streaming-Lösungen setzen auf Icecast als Basis, auch wenn sie den Code häufig noch an ihre eigenen Bedürfnisse anpassen.