Anforderungen an einen Live-Streaming-Server auf dedizierter Hardware

Was Live-Streaming eigentlich von einem Server verlangt

Ein Live-Streaming-Server führt drei verschiedene Vorgänge aus, die jeweils unterschiedliche Ressourcenprofile aufweisen:

Ingest: Empfängt den kodierten Stream von deiner Streaming-Software (OBS, Restream, vMix) über RTMP (Real-Time Messaging Protocol). Geringe CPU-Auslastung – der Server nimmt lediglich eine Netzwerkverbindung entgegen und schreibt auf die Festplatte oder in den Arbeitsspeicher.

Transkodierung: Der eingehende Stream wird in verschiedene Qualitätsstufen (1080p, 720p, 480p, 360p) umkodiert, damit Zuschauer mit unterschiedlicher Bandbreite ohne Pufferung zuschauen können. CPU-intensiv. Hier stoßen die meisten Server an ihre Grenzen.

Übertragung: Sendet die HLS- (HTTP Live Streaming) oder DASH-Segmente über ein CDN oder direkt an die Zuschauer. Bandbreitenintensiv. Bei 100 gleichzeitigen Zuschauern mit jeweils 4 Mbit/s sind das 400 Mbit/s an kontinuierlicher Ausgangsbandbreite.

Dein Server muss alle drei gleichzeitig verarbeiten, möglicherweise für mehrere parallele Streams.

Hardwareanforderungen nach Anwendungsfall

Ein Stream, bis zu 500 gleichzeitige Zuschauer

Mindestkonfiguration: InMotion Essential (99,99 $/Monat, 64 GB DDR4, 2×1,92 TB NVMe)

Bei einer Auflösung von 1080p30 mit der x264-Voreinstellung „medium“ und der Transkodierung in drei Qualitätsstufen ist davon auszugehen, dass während des aktiven Streamings 4 bis 6 CPU-Kerne voll ausgelastet sind. Der Prozessor des Essential-Servers bewältigt dies problemlos. Bei 500 gleichzeitigen Zuschauern, die Streams mit 4 Mbit/s empfangen, erreicht die ausgehende Bandbreite 2 Gbit/s – was innerhalb des burstfähigen 10-Gbit/s-Rahmens liegt.

RAM ist bei diesem Umfang kein Engpass – 8 bis 16 GB reichen für den Streaming-Stack aus. 64 GB bieten Spielraum für das Betriebssystem und alle anderen Dienste, die parallel zum Stream laufen.

Mehrere Streams oder 500–5.000 gleichzeitige Zuschauer

Empfehlung: InMotion Elite oder Extreme (199,99–349,99 $/Monat)

Für Multi-Stream-Betrieb oder hohe Zuschauerzahlen sind entweder mehr CPU-Kerne für die gleichzeitige Transkodierung oder ausreichend RAM erforderlich, um Stream-Segmente großzügig zwischenzuspeichern. Bei 2.000 gleichzeitigen Zuschauern, die eine HLS-Übertragung mit 4 Mbit/s empfangen, liegt die Dauerleistung bei 8 Gbit/s – das nähert sich der Burst-Grenze und ist ein starkes Argument für eine garantierte, unbegrenzte Bandbreite von 10 Gbit/s.

Die 16 Kerne mit 32 Threads des AMD EPYC 4545P eignen sich hervorragend für parallele Transcodierungsaufgaben. Die Softwaretranscodierung mit libx264 oder libvpx skaliert linear mit der Kernanzahl – zwei parallele 1080p-Streams beanspruchen etwa doppelt so viel CPU-Leistung wie ein einzelner.

Bereitstellung in großem Maßstab (über 5.000 gleichzeitige Zuschauer)

In dieser Größenordnung übernimmt der dedizierte Server die Erfassung und Transkodierung; ein CDN kümmert sich um die Bereitstellung. Die Rechnung ist einfach: 5.000 Zuschauer bei 4 Mbit/s ergeben 20 Gbit/s Übertragungsbandbreite, was die realistische Auslastung eines einzelnen Servers übersteigt. Ein richtig konfiguriertes CDN ruft den HLS-Stream einmalig von deinem Server ab und verteilt ihn an die Zuschauer – dein Server verzeichnet nur eine geringe Anzahl von CDN-PoP-Verbindungen statt 5.000 einzelner Zuschauerverbindungen.

Nginx unter Linux einrichten

Nginx dem RTMP-Modul ist der gängige Open-Source-Streaming-Server. Unter AlmaLinux oder Ubuntu:

# Ubuntu

apt-get install nginx libnginx-mod-rtmp -y

# AlmaLinux/Rocky

dnf install nginx -y

# Compile RTMP module or use community packages

Basic Nginx configuration for ingest and HLS delivery:

# /etc/nginx/nginx.conf

rtmp {

    server {

        listen 1935;

        chunk_size 4096;

        application live {

            live on;

            record off;

            # HLS delivery

            hls on;

            hls_path /var/www/html/hls;

            hls_fragment 3s;

            hls_playlist_length 60s;

            # Transcode to multiple qualities

            exec_push ffmpeg -i rtmp://localhost/$app/$name

                -c:v libx264 -b:v 3000k -s 1920x1080 -r 30

                -c:a aac -b:a 128k

                -f flv rtmp://localhost/hls/$name_1080p

                -c:v libx264 -b:v 1500k -s 1280x720 -r 30

                -c:a aac -b:a 128k

                -f flv rtmp://localhost/hls/$name_720p

                -c:v libx264 -b:v 600k -s 854x480 -r 30

                -c:a aac -b:a 96k

                -f flv rtmp://localhost/hls/$name_480p;

        }

        application hls {

            live on;

            hls on;

            hls_path /var/www/html/hls;

            hls_fragment 3s;

            hls_nested on;

        }

    }

}

http {

    server {

        listen 80;

        location /hls {

            types {

                application/vnd.apple.mpegurl m3u8;

                video/mp2t ts;

            }

            root /var/www/html;

            add_header Cache-Control no-cache;

            add_header Access-Control-Allow-Origin *;

        }

    }

}

# Ubuntu

apt-get install nginx libnginx-mod-rtmp -y

# AlmaLinux/Rocky

dnf install nginx -y

# Compile RTMP module or use community packages

Basic Nginx configuration for ingest and HLS delivery:

# /etc/nginx/nginx.conf

rtmp {

    server {

        listen 1935;

        chunk_size 4096;

        application live {

            live on;

            record off;

            # HLS delivery

            hls on;

            hls_path /var/www/html/hls;

            hls_fragment 3s;

            hls_playlist_length 60s;

            # Transcode to multiple qualities

            exec_push ffmpeg -i rtmp://localhost/$app/$name

                -c:v libx264 -b:v 3000k -s 1920x1080 -r 30

                -c:a aac -b:a 128k

                -f flv rtmp://localhost/hls/$name_1080p

                -c:v libx264 -b:v 1500k -s 1280x720 -r 30

                -c:a aac -b:a 128k

                -f flv rtmp://localhost/hls/$name_720p

                -c:v libx264 -b:v 600k -s 854x480 -r 30

                -c:a aac -b:a 96k

                -f flv rtmp://localhost/hls/$name_480p;

        }

        application hls {

            live on;

            hls on;

            hls_path /var/www/html/hls;

            hls_fragment 3s;

            hls_nested on;

        }

    }

}

http {

    server {

        listen 80;

        location /hls {

            types {

                application/vnd.apple.mpegurl m3u8;

                video/mp2t ts;

            }

            root /var/www/html;

            add_header Cache-Control no-cache;

            add_header Access-Control-Allow-Origin *;

        }

    }

}

Diese Konfiguration empfängt einen RTMP-Stream von OBS auf Port 1935, transkodiert ihn mithilfe von FFmpeg in drei Qualitätsstufen und stellt HLS-Segmente über HTTP auf Port 80 bereit.

OBS-Stream-Einstellungen:

• Server: rtmp://deine-server-ip/live
• Stream-Schlüssel: beliebige Zeichenfolge (wird zum Stream-Namen)
• Encoder: x264 oder NVENC (sofern eine GPU verfügbar ist)
• Bitrate: 6.000 Kbit/s für 1080p60-Quellmaterial

Streme über einen dedizierten Server gleichzeitig auf Twitch und YouTube

Ein dedizierter RTMP-Server kann gleichzeitig auf mehrere Plattformen übertragen, sodass kein kostenpflichtiger Restreaming-Dienst mehr erforderlich ist.

application live {

    live on;

    # Push to Twitch

    push rtmp://live.twitch.tv/app/YOUR_TWITCH_STREAM_KEY;

    # Push to YouTube

    push rtmp://a.rtmp.youtube.com/live2/YOUR_YOUTUBE_STREAM_KEY;

    # Keep local HLS copy

    hls on;

    hls_path /var/www/html/hls;

}

application live {

    live on;

    # Push to Twitch

    push rtmp://live.twitch.tv/app/YOUR_TWITCH_STREAM_KEY;

    # Push to YouTube

    push rtmp://a.rtmp.youtube.com/live2/YOUR_YOUTUBE_STREAM_KEY;

    # Keep local HLS copy

    hls on;

    hls_path /var/www/html/hls;

}

Dein Streamer sendet einen Stream an deinen dedizierten Server; der Server verteilt diesen gleichzeitig an Twitch, YouTube und deinen eigenen HLS-Endpunkt. Dafür ist eine ausgehende Bandbreite erforderlich, die der Summe aller Ziel-Bitraten entspricht – in der Regel 6.000 bis 18.000 Kbit/s, je nach den Anforderungen der jeweiligen Plattform.

Optimierung der FFmpeg-Transkodierung

Bei den Standardeinstellungen von FFmpeg hat die Qualität Vorrang vor der CPU-Effizienz. Für Live-Streams, bei denen Echtzeitleistung gefragt ist, solltest du die Voreinstellung anpassen und die Flags entsprechend einstellen:

ffmpeg -i rtmp://localhost/$app/$name \

    -c:v libx264 \

    -preset veryfast \       # Entscheidend für Echtzeit: veryfast oder ultrafast

    -tune zerolatency \      # Reduziert die Kodierungsverzögerung

    -b:v 3000k \

    -maxrate 3000k \

    -bufsize 6000k \

    -g 60 \                  # Keyframe-Intervall (2x Bildrate bei 30 fps)

    -sc_threshold 0 \        # Deaktiviert die Erkennung von Szenenwechseln (erhöht die Latenz)

    -c:a aac \

    -b:a 128k \

    -f flv rtmp://localhost/hls/$name_1080p

ffmpeg -i rtmp://localhost/$app/$name \

    -c:v libx264 \

    -preset veryfast \       # Critical for real-time: veryfast or ultrafast

    -tune zerolatency \      # Reduces encoding delay

    -b:v 3000k \

    -maxrate 3000k \

    -bufsize 6000k \

    -g 60 \                  # Keyframe interval (2x framerate for 30fps)

    -sc_threshold 0 \        # Disable scene change detection (adds latency)

    -c:a aac \

    -b:a 128k \

    -f flv rtmp://localhost/hls/$name_1080p

Die Voreinstellung „veryfast“ verringert die Kodierungsqualität im Vergleich zu „slow“ oder „medium“ zwar leicht, senkt aber die CPU-Auslastung um 60–70 % – was für die Echtzeit-Transkodierung auf einer CPU, die mehrere Streams oder andere Aufgaben gleichzeitig verarbeitet, unerlässlich ist.

Der FFmpeg-Leitfaden zur Codierung behandelt die Vor- und Nachteile der verschiedenen Voreinstellungen ausführlich.

Firewall-Konfiguration für Streaming

Öffne die Ports, die dein Streaming-Stack benötigt:

# RTMP-Upload von Sendern zulassen

nft add rule inet filter input tcp dport 1935 accept

# HTTP-Übertragung von HLS-Segmenten zulassen

nft add rule inet filter input tcp dport 80 accept

nft add rule inet filter input tcp dport 443 accept

# RTMP-Upload nach Möglichkeit auf bekannte IP-Adressen von Sendern beschränken

# Durch die tatsächliche IP des Senders ersetzen

nft add rule inet filter input ip saddr 203.0.113.0/24 tcp dport 1935 accept

nft add rule inet filter input tcp dport 1935 drop

# Allow RTMP ingest from broadcasters

nft add rule inet filter input tcp dport 1935 accept

# Allow HTTP delivery of HLS segments

nft add rule inet filter input tcp dport 80 accept

nft add rule inet filter input tcp dport 443 accept

# Restrict RTMP ingest to known broadcaster IPs if possible

# Replace with actual broadcaster IP

nft add rule inet filter input ip saddr 203.0.113.0/24 tcp dport 1935 accept

nft add rule inet filter input tcp dport 1935 drop

Wenn du den RTMP-Port für das Internet offen lässt, kann jeder auf deinen Server streamen. Durch die IP-Beschränkung des Ingest-Ports verhinderst du die unbefugte Nutzung der Bandbreite deines Servers.

Speicherplatz für Stream-Aufzeichnungen

Aufgezeichnete Streams in 1080p verbrauchen bei einer Bitrate von 12–15 Mbit/s etwa 1 GB pro 10 Minuten Aufzeichnung. Plane den Speicherplatz für den regulären Streaming-Betrieb entsprechend ein:

• 2 Stunden Aufnahme pro Tag: ~12 GB/Tag, ~360 GB/Monat
• Der Essential-Server von InMotion verfügt über 2×1,92 TB NVMe das reicht für etwa 3.000 Stunden Aufzeichnungen, bevor eine Archivierung erforderlich wird

Configure Nginx-RTMP to record to a specific path:

application live {

    live on;

    record all;

    record_path /var/recordings;

    record_suffix -%d%m%Y-%H%M%S.flv;

    record_max_size 1000M;  # Split at 1GB to keep files manageable

}

Configure Nginx-RTMP to record to a specific path:

application live {

    live on;

    record all;

    record_path /var/recordings;

    record_suffix -%d%m%Y-%H%M%S.flv;

    record_max_size 1000M;  # Split at 1GB to keep files manageable

}

Der „Premier Care“-Backup-Speicher von InMotion (500 GB) bietet eine Kopie wichtiger Aufzeichnungen außerhalb des Servers. Für die längerfristige Archivierung konfigurierst du rclone so, dass das Aufzeichnungsverzeichnis regelmäßig mit einem S3-kompatiblen Objektspeicher synchronisiert wird.

Weiterführende Literatur: Optimierung der Netzwerklatenz für dedizierte Server | Optimierung von CDN-Origin-Servern