4.3.2 Streaming-Server bei Proton

Bei Proton werden http-Streams verwendet, die beim Streaming-Server am Studio-Standort abgeholt werden können. Dazu muss sichergestellt werden, dass der Server von der Außenwelt bzw. im Internet auch zugänglich ist und nicht komplett von der Firewall des Routers geblockt wird. Bei Proton ist ein Port-Forwarding eingerichtet, auf den Port 7998, der an den Streaming-Server weiter geleitet wird.

Der typische Port für Audio-Streams ist 8000. Der Proton-Stream, den die Internet-Hörer beziehen können, verwendet diesen. Der Port-8000-Stream war auch schon vor dem Projekt zur Sender-Anbindung über Streaming (2009) eingerichtet. Der Live-Feed für den Internet-Hörer-Stream wurde bereits seit dem Jahr 2002 mehr oder weniger regelmäßig aus den Studio-Örtlichkeiten zugeliefert.

Ein Problem von Proton ist, dass die Radiostation nur sehr begrenzt über UKW hörbar ist. Die einzige Alternative bietet das Internet. Proton kann über den http-Stream gehört werden. Dieser wird vom gleichen Rechner weiter gereicht, der auch die Website 'radioproton.at' hostet.

Den Port 7998 wurde für das Streaming-Projekt zur Anbindung der Sender gewählt, um am bereits länger bestehenden Stream (auf Port 8000) nichts verändern zu müssen. Die Wahl fiel auf 2 weniger als 8000, weil 'shoutcast' (eine Streaming-Server-Software) nicht auf dem gleichen Port den Live-Feed (vom Source-Client) empfangen und Streams an die Hörer (Listener-Clients) weiter geben kann. Dies würde zu Komplikationen führen. So gibt die Hilfe für die Konfiguration von 'Icecast' (der verwendete Streaming-Server bei Proton) auch heute noch an, dass im „Shoutcast compatibility mode“ der Feed ein Port mehr sein muss als der Listener-Port.¹

Für Proton wurde als Streaming-Server nicht 'Shoutcast' gewählt, sondern 'Icecast2'. (Icecast2 steht für Icecast Version 2²; aktueller Stand Februar 2015 ist Version 2.4.1 als „production-release“³ oder für die Beta-Tester die Version 2.5 beta1⁴.) Online gibt es eine Gegenüberstellung dieser beiden Server, die besagt, dass bei shoutcast nur ein Feed zur gleichen Zeit verarbeitet werden kann („SHOUTcast Server can only handle 1 feed a time“⁵ ). Icecast hingegen könne bis zu 3 unterschiedlichen Feeds auf dem gleichen Port weiter reichen.⁶ Aber in der Online-Hilfe zur Konfiguration von Icecast kann kein Hinweis zur angeblichen Begrenzung gefunden werden!⁷

Icecast2 unterstützt den Codec 'Ogg Vorbis', der im Projekt zur Anwendung kommt, und ist eine Free Open Source Software (kurz FOSS). Die Software gibt es in den Paket-Quellen von Debian Linux. Sie musste also nicht compiliert werden. Aber konfiguriert – In der Anlage (siehe unten bzw. Anchor-Link) ist die 'icecast.xml; Konfigurationsdatei für den http-Streaming-Server Icecast2' zu finden, wie sie aktuell bei Proton im Einsatz ist.
 

Topologie Protons Streaming-Server

Über diesen Icecast2-Server am Studio-Standort laufen alle 3 Streams, die von 'darkice' produziert werden. Nur der Stream 'fett.ogg' wird von den Sendern abgeholt. Er hat eine besonders hohe Bitrate, um gute Qualität bei der Ausstrahlung zu gewährleisten. Die anderen 2 Streams, die für die Hörer über Internet gedacht sind, werden vom Streaming-Server in den Studio-Räumlichkeiten zum Relay-Server weiter gereicht.

Das wurde so eingerichtet, damit es zu keinen Bandbreite-Problemen kommt, wenn ein hoher Andrang herrscht und viele Hörer gleichzeitig über Internet Proton hören wollen. Die Clients, die das Audiosignal an die UKW-Sender weiter geben, sollen jederzeit genug schnell Daten-Nachschub erhalten ('Buffer Underrun' vermeiden!).

Ein 'Quality of Service' (QoS; Bevorzugung von Datenverkehr konfigurierbar) ist am Studio-Router eingerichtet. Dieses geht nach Ports vor und kann nicht zwischen den einzelnen Streams unterscheiden. Alle Daten auf dem Port 7998 werden gleich wichtig ausgewertet.

Der Streaming-Server am Proton Studio-Standort dient lediglich als Input für einen sogenannter Relay-Server. Über diesen zweiten Server werden die Internet-Hörer bedient. Der Relay-Server übernimmt das Verteilen an die möglicherweise vielen Internet-Hörer. Eine größere Bandbreite für die Internet-Hörer braucht der Relay-Server. In diesen komplexen Strukturen zwischen Client und Server nimmt ein (der Zweite, der Relay-)Server selbst wiederum den Dienst eines anderen (den ersten Streaming-) Servers in Anspruch.⁸

In der Anleitung zu 'Icecast' steht, dass die 'Relays' als Pull-System implementiert sind, bei dem der empfangende Server sich als Zuhörer mit dem sendenden Server verbindet.⁹ Da bei Proton nicht alle Streams weiter gereicht werden an den zweiten Server, wird die Methode „Specific Mountpoint Relay“ verwendet. Das wird am Pull-Server in der Konfigurationsdatei festgelegt (mit dem <relay>-tag). Der Server, der den Stream weiter reicht bzw. an dem per „Pull“ abgeholt wird, braucht keine speziellen Konfigurationen. (Deshalb ist in der Datei 'icecast.xml; Konfigurationsdatei für den http-Streaming-Server Icecast2' am Studio-Standort nichts davon zu sehen. Die Relay-Einträge wären in der Datei 'icecast.xml' vom Website-Host zu finden.)

Der Relay-Server bezieht die Streams per „Pull“ nur dann, wenn sie tatsächlich von Hörern bzw. von Clients angefordert werden. Die Belastung bei hohem Hörerandrang liegt nicht auf dem Streaming-Server am Studio-Standort. Deshalb wurde diese Lösung gewählt.

4.3.3 Zusammenfassung der Übertragungslösung bei Proton

In diesem Kapitel ist eine Auflistung der verwendeten Komponenten bei Proton angeführt. Im Blockschaltbild auf Seite 8 ist deren Anordnung in der Signalkette graphisch dargestellt.

Am Studio-Standort

Source-Client: Linux-Software Darkice (3 Streams; .ogg und .mp3)

Streaming-Server: Linux-Software Icecast2; http-Streaming, TCP, Pull-Modus

Fixe IP des Internet-Zuganges; Port-Forwarding am Router für 7998, TCP (damit die Clients auf den Server zugreifen können)

Für die Sender, an den Sender-Standorten bzw. direkte Zubringer:

Streaming-Client: Barix Exstreamer 100 an Internet-Anschluss

Für die Internet-Radio-Hörer, am Standort des Host von 'radioproton.at':

Streaming-Relay-Server: Linux-Software Icecast2 (für die Weiterverteilung der bezogenen Streams)

Port-Forwarding am Router für 8000, TCP (damit die Clients auf den Server zugreifen können)

Um einen Blick auf Alternativen zu werfen, werden im nächsten Kapitel weitere Möglichkeiten für Streaming vorgestellt. Eine Übertragungslösung bei Proton, die Pull und UDP verwendet, wäre gegenüber der momentanen Anwendung von Vorteil.

Anlage 9: icecast.xml; Konfigurationsdatei für den http-Streaming-Server Icecast2

<icecast>

<limits>
<clients>100</clients>
<sources>5</sources>
<threadpool>5</threadpool>
<queue-size>524288</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>10</source-timeout>
<!-- If enabled, this will provide a burst of data when a client
first connects, thereby significantly reducing the startup
time for listeners that do substantial buffering. However, it
also significantly increases latency between the source
client and listening client. For low-latency setups, you might
want to disable this. -->
<burst-on-connect>1</burst-on-connect>
<!-- same as burst-on-connect, but this allows for being more
specific on how much to burst. Most people won't need to
change from the default 64k. Applies to all mountpoints -->
<burst-size>65535</burst-size>

</limits>


<authentication>
<!-- Sources log in with username 'source' -->
<source-password> … </source-password>
<!-- Relays log in username 'relay' -->
<relay-password> … </relay-password>

<!-- Admin logs in with the username given below -->
<admin-user>admin</admin-user>
<admin-password>... </admin-password>

</authentication>

<!-- set the mountpoint for a shoutcast source to use, the default if not
specified is /stream but you can change it here if an alternative is
wanted or an extension is required … -->

<!-- This is the hostname other people will use to connect to your server.
It affects mainly the urls generated by Icecast for playlists and yp
listings. -->
<hostname>localhost</hostname>

<!-- You may have multiple <listener> elements -->
<listen-socket>
<port>7998</port>
<!-- <bind-address>127.0.0.1</bind-address> -->
<!-- <shoutcast-mount>/stream</shoutcast-mount> -->
</listen-socket>

<!-- <listen-socket><port>8001</port></listen-socket> -->
<!--<master-server>127.0.0.1</master-server>-->
<!--<master-server-port>8001</master-server-port>-->
<!--<master-update-interval>120</master-update-interval>-->
<!--<master-password>...</master-password>-->

<!-- setting this makes all relays on-demand unless overridden, this is
useful for master relays which do not have <relay> definitions here.
The default is 0 -->
<!--<relays-on-demand>1</relays-on-demand>-->

<!-- <relay> <server>127.0.0.1</server> <port>8001</port>
<mount>/example.ogg</mount> <local-mount>/different.ogg</local-mount>
<on-demand>0</on-demand>

<relay-shoutcast-metadata>0</relay-shoutcast-metadata>
</relay>    -->

<!-- Only define a <mount> section if you want to use advanced options,
like alternative usernames or passwords
<mount> …  </mount>  -->

<fileserve>1</fileserve>

<paths>
<!-- basedir is only used if chroot is enabled -->
<basedir>/usr/share/icecast2</basedir>
<!-- Note that if <chroot> is turned on below, these paths must both
be relative to the new root, not the original root -->
<logdir>/var/log/icecast2</logdir>
<webroot>/usr/share/icecast2/web</webroot>
<adminroot>/usr/share/icecast2/admin</adminroot>
<!-- <pidfile>/usr/share/icecast2/icecast.pid</pidfile> -->

<!-- Aliases: treat requests for 'source' path as being for 'dest' path
May be made specific to a port or bound address using the "port"
and "bind-address" attributes. -->

<!-- <alias source="/foo" dest="/bar"/>  -->
<!-- Aliases: can also be used for simple redirections as well,
this example will redirect all requests for http://server:port/ to
the status page  -->
<alias source="/" dest="/status.xsl"/>

</paths>

<logging>
<accesslog>access.log</accesslog>
<errorlog>error.log</errorlog>
<!-- <playlistlog>playlist.log</playlistlog> -->
<loglevel>3</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
<logsize>10000</logsize> <!-- Max size of a logfile -->
<!-- If logarchive is enabled (1), then when logsize is reached
the logfile will be moved to [error|access|playlist].log.DATESTAMP,
otherwise it will be moved to [error|access|playlist].log.old.
Default is non-archive mode (i.e. overwrite)
-->
<!-- <logarchive>1</logarchive> -->

</logging>

<security>
<chroot>0</chroot>

<!-- <changeowner> <user>nobody</user> <group>nogroup</group>
</changeowner> -->

</security>

</icecast>