Stream-Server einrichten: ein Upload für beliebig viele Zuschauer

Wer ohne eigenen Server streamt, schickt sein Bild an jeden Zuschauer einzeln. Zehn Zuschauer bedeuten zehnmal dieselben Daten, hundert Zuschauer hundertmal. Der Upload zu Hause oder im Büro ist damit nach wenigen Zuschauern dicht, und das Bild beginnt zu stocken, obwohl der Rechner langweilt.

Ein Stream-Server dreht das um: Du sendest genau einen Stream zum Server, und der Server versorgt damit alle Zuschauer. Deine eigene Leitung trägt dadurch immer nur einen einzigen Upload, völlig gleich, ob zehn oder zehntausend Leute zusehen. Dieser Artikel zeigt, warum das so gut funktioniert, wie du einen solchen Server aufsetzt, welches Protokoll welche Verzögerung kostet und wie viel Traffic dabei wirklich zusammenkommt.

Das Problem: dein Upload ist der Flaschenhals

Video ist ein Dauerstrom. Ein Stream in 1080p mit 60 Bildern pro Sekunde braucht je nach Inhalt 4,5 bis 8 Mbit/s, 720p liegt bei 3 bis 5 Mbit/s. Diese Bitrate fließt pro Zuschauer, die ganze Zeit, ohne Pause.

Ein durchschnittlicher Hausanschluss in Deutschland schafft im Upload zwischen 10 und 50 Mbit/s, selbst viele Glasfaseranschlüsse liegen im Upload bei 50 bis 100 Mbit/s. Die Rechnung ist deshalb schnell zu Ende:

Dazu kommt ein zweites Problem, das oft übersehen wird: Dein Anschluss teilt sich diese Leitung mit allem anderen im Haushalt oder im Büro. Sobald jemand eine große Datei hochlädt oder ein Backup losläuft, bricht der Stream ein. Ein Server im Rechenzentrum hat dieses Problem nicht, dort steht die Anbindung ausschließlich dir zur Verfügung.

Das Prinzip: einmal hoch, vielfach runter

Der Aufbau besteht aus drei Teilen:

• Der Sender, also OBS, ffmpeg oder eine Hardware-Box, schickt einen Stream zum Server. Das nennt sich Ingest.
• Der Server nimmt diesen einen Stream an, legt ihn in das gewünschte Ausspielformat um und hält ihn bereit.
• Die Zuschauer holen sich den Stream vom Server. Das nennt sich Egress und ist der Teil, der mit der Zuschauerzahl wächst.

Entscheidend ist die Asymmetrie: Der Weg von dir zum Server wird einmal gegangen, der Weg vom Server zu den Zuschauern tausendfach. Deshalb braucht dein Anschluss nur so viel Upload wie ein einziger Stream, während der Server eine Anbindung braucht, die mit dem Publikum mithält.

Wie viel Traffic wirklich zusammenkommt

Die Bandbreite ist nur die halbe Rechnung. Interessanter ist das Volumen, denn danach wird bei vielen Anbietern abgerechnet. Die Formel ist einfach:

Volumen in GB = Bitrate in Mbit/s × Sekunden × Zuschauer ÷ 8000

Ein paar realistische Beispiele:

Die Zahlen in der letzten Spalte sind der Grund, warum Streaming und volumenbasierte Abrechnung schlecht zusammenpassen. Eine einzige gut besuchte Übertragung kann das Inklusivvolumen eines ganzen Monats aufbrauchen, und jedes weitere Terabyte wird dann einzeln berechnet. Bei einem Tarif mit unbegrenztem Traffic entfällt diese Rechnung vollständig: Der Monatspreis steht fest, egal ob 200 GB oder 50 TB durch die Leitung gehen.

Welche Software passt zu dir

Für den Anfang ist nginx mit dem RTMP-Modul die naheliegendste Wahl: Es ist überall verfügbar, gut dokumentiert, und du kannst denselben Server später ohne Umbau als Webserver für die Zuschauerseite nutzen.

Einen Stream-Server mit nginx und RTMP aufsetzen

Installieren

Auf Debian und Ubuntu bringt das Paket libnginx-mod-rtmp das Modul mit, du brauchst nichts selbst zu übersetzen:

apt update
apt install -y nginx libnginx-mod-rtmp ffmpeg

Auf AlmaLinux und Rocky Linux kommt das Modul aus dem EPEL-Repository:

dnf install -y epel-release
dnf install -y nginx nginx-mod-rtmp ffmpeg

Konfigurieren

Der RTMP-Teil steht in der nginx.conf außerhalb des http-Blocks, das ist der häufigste Anfängerfehler. Eine schlanke, funktionierende Fassung sieht so aus:

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            record off;

            # HLS fuer normale Zuschauer
            hls on;
            hls_path /var/www/stream/hls;
            hls_fragment 2s;
            hls_playlist_length 12s;

            # nur von der eigenen Adresse darf gesendet werden
            allow publish 203.0.113.10;
            deny publish all;

            # Zuschauen darf jeder
            allow play all;
        }
    }
}

Die HLS-Dateien liefert dann der normale Webserver aus. Dafür genügt ein kleiner Block im http-Teil:

server {
    listen 80;
    server_name stream.example.com;

    location /hls {
        types {
            application/vnd.apple.mpegurl m3u8;
            video/mp2t ts;
        }
        root /var/www/stream;
        add_header Cache-Control no-cache;
        add_header Access-Control-Allow-Origin *;
    }
}

Verzeichnis anlegen, Konfiguration prüfen, neu starten:

mkdir -p /var/www/stream/hls
chown -R www-data:www-data /var/www/stream
nginx -t && systemctl reload nginx

Ports freigeben

RTMP läuft auf Port 1935, die Auslieferung über 80 und 443. Mit nftables oder ufw:

ufw allow from 203.0.113.10 to any port 1935 proto tcp
ufw allow 80/tcp
ufw allow 443/tcp

Beachte die erste Zeile: Der Sendeport ist nur für deine eigene Adresse offen. Ein weltweit offener RTMP-Port wird innerhalb weniger Tage gefunden, weil ganze Adressbereiche automatisch durchsucht werden, und dann sendet jemand anderes über deine Leitung.

Senden mit OBS

In OBS unter Einstellungen, Stream, Dienst „Benutzerdefiniert“ eintragen:

Unter Ausgabe stellst du die Bitrate ein. Als Richtwert: 1080p60 mit 6000 kbit/s, 1080p30 mit 4500 kbit/s, 720p30 mit 3000 kbit/s. Setze die Keyframe-Distanz auf 2 Sekunden, sonst entstehen bei HLS unregelmäßige Segmente und der Player stottert beim Umschalten.

Zuschauen

Der Stream liegt danach unter https://stream.example.com/hls/kanal1.m3u8 und lässt sich mit jedem HLS-fähigen Player öffnen, im Browser zum Beispiel mit hls.js oder Video.js. Zum schnellen Prüfen genügt VLC über „Netzwerkstream öffnen“.

Gleichzeitig zu mehreren Plattformen senden

Das ist der zweite große Vorteil eines eigenen Servers. Statt mit drei parallelen Uploads deine Leitung zu sprengen, sendest du einmal zum Server, und der verteilt weiter. Dafür ergänzt du im application-Block je Ziel eine Zeile:

application live {
    live on;
    record off;

    push rtmp://live.plattform-a.example/app/STREAM_KEY;
    push rtmp://live.plattform-b.example/app/STREAM_KEY;
}

Dein Upload bleibt dabei bei einem einzigen Stream. Die Vervielfachung übernimmt der Server, und dort ist Bandbreite genau das, wofür er da ist.

Verzögerung: welches Protokoll wofür

Die Verzögerung entsteht fast vollständig beim Ausspielen, nicht beim Senden. Das ist wichtig zu verstehen, weil viele an der falschen Stelle suchen:

Je niedriger die Verzögerung, desto teurer wird der einzelne Zuschauer. HLS ist am billigsten, weil es aus einfachen Dateien besteht, die jeder Webserver und jeder Cache ausliefern kann. WebRTC hält dagegen für jeden Zuschauer eine eigene Verbindung offen und kostet damit deutlich mehr Rechenleistung. Nimm die niedrige Verzögerung nur dort, wo du sie wirklich brauchst.

Transcoding: wann es sich lohnt

Solange der Server den Stream nur weiterreicht, braucht er fast keine Rechenleistung. Ein einzelner moderner Kern bedient auf diese Weise mehrere hundert Zuschauer, der Engpass ist allein die Anbindung.

Sobald du mehrere Qualitätsstufen anbieten willst, damit auch Zuschauer mit schwacher Verbindung zusehen können, ändert sich das. Jede zusätzliche Stufe muss berechnet werden:

ffmpeg -i rtmp://127.0.0.1/live/kanal1 \
  -c:v libx264 -preset veryfast -b:v 3000k -s 1280x720 -c:a copy -f flv rtmp://127.0.0.1/live/kanal1_720 \
  -c:v libx264 -preset veryfast -b:v 1200k -s 854x480  -c:a copy -f flv rtmp://127.0.0.1/live/kanal1_480

Rechne mit zwei bis vier Kernen je Stufe. Drei Stufen binden damit schon acht bis zwölf Kerne dauerhaft. Überlege deshalb genau, ob du sie brauchst: Für ein Publikum, das überwiegend am Rechner oder im WLAN sitzt, genügt oft eine einzige gut gewählte Stufe.

Absichern: wer darf senden

Ein Stream-Server ist von außen sichtbar und wird gefunden. Drei Maßnahmen reichen für den Alltag:

• Firewall auf den Sendeport. Nur deine eigene Adresse darf auf 1935. Wechselt deine Adresse, nutze stattdessen einen VPN-Zugang zum Server.
• Streamschlüssel prüfen. Mit on_publish ruft nginx bei jedem Sendeversuch ein kleines Skript auf, das den Schlüssel gegen eine Liste prüft und bei Nichtübereinstimmung ablehnt.
• Grundschutz gegen Überlastung. Ein Stream-Server ist ein lohnendes Ziel, weil ein Ausfall sofort sichtbar ist. Bei KernelHost liegt ein Floodschutz mit 3,2 Tbps Kapazität auf jedem Server, ohne dass du etwas einrichten musst. Mehr dazu auf der Seite zum DDoS-Schutz.

Standortwahl und mehrere Server

Der Server gehört nicht in deine Nähe, sondern in die Nähe deiner Zuschauer. Deine eigene Verbindung zum Server wird einmal aufgebaut und läuft dann stabil, selbst über einen halben Kontinent. Die Verbindung zu den Zuschauern dagegen entscheidet über Ladezeit und Abbruchrate.

Sitzt dein Publikum überwiegend in Europa, steht ein Standort in Deutschland richtig. Verteilt es sich über mehrere Kontinente, lohnt sich ein zweiter Server und eine Verteilung über DNS, sodass jeder Zuschauer beim nächstgelegenen landet. KernelHost bietet dafür Standorte in Deutschland, an der US-Westküste, an der US-Ostküste sowie in Singapur und Südkorea, eine Übersicht findest du unter Serverstandorte.

Wenn du Dateien statt Livebilder verteilst, also Updates, Bilder oder Videoarchive, ist nicht ein Stream-Server das richtige Werkzeug, sondern ein Cache davor. Wie das funktioniert, steht im Artikel Eigenen CDN-Server aufbauen.

Welcher Server passt

Für einen Stream-Server zählt eine andere Reihenfolge als bei einem Webserver:

1. Anbindung und Traffic. Das ist der Engpass, und zwar immer. Eine echte Gigabit-Anbindung ohne Drosselung trägt rund 160 Zuschauer bei 6 Mbit/s.
2. Unbegrenzter Traffic. Volumenbasierte Tarife sind für Streaming kaum kalkulierbar, weil ein einziger erfolgreicher Abend das Monatsvolumen aufbraucht.
3. CPU. Zweitrangig, solange du nicht transcodierst. Beim Transcoding wird sie zum zweiten Engpass.
4. RAM und Platte. Am wenigsten kritisch. Erst wenn du Aufzeichnungen behältst, wird Plattenplatz zum Thema.

Genau auf diesen Fall sind unsere Unlimited-Traffic-Rootserver zugeschnitten: echte 2 × 1 Gbit/s Anbindung pro Server, unbegrenztes Volumen ohne Drosselung, ein fixer Monatspreis unabhängig von der übertragenen Menge, und 3,2 Tbps Floodschutz ab Werk. Der Server ist in unter 30 Sekunden bereitgestellt, mit vollem Root-Zugriff, IPv4 und einem /64-IPv6-Netz. Abgerechnet wird auf PrePaid-Basis und monatlich kündbar, du kannst also mit einem kleinen Tarif anfangen und wachsen, wenn dein Publikum wächst.