24/7-Stream auf dem VPS oder mit einem Managed Cloud-Dienst?
Ein 24/7-Stream auf einem VPS mit FFmpeg wirkt simpel – bis die Playlist von vorn startet, der Prozess nachts abstürzt oder ein zweites Ziel deinen ausgehenden Traffic verdoppelt. Hier erfährst du, was DIY wirklich bedeutet und wann sich ein Managed-Dienst mehr lohnt.
Etwa 7 Min. Lesezeit
Auf dieser Seite
Du kannst einen 24/7-Stream auf einem VPS mit FFmpeg betreiben: Videos auf einen gemieteten Server hochladen, eine Concat-Playlist schreiben und sie in Dauerschleife an die RTMP-URL einer Plattform schicken. Das funktioniert und kann ein gutes Lernprojekt sein. Der eigentliche Preis ist deine Zeit – für Encoding, Absturz-Recovery, Monitoring und Bandbreitenplanung.
Hier siehst du, was DIY wirklich bedeutet und wann ein Managed-Dienst die bessere Investition deiner Stunden ist.
Das Wichtigste in Kürze
- Eine einfache FFmpeg-Schleife steht schnell; sie monatelang am Laufen zu halten, ist die eigentliche Arbeit.
- Abweichende Framerates oder Timestamps können eine Playlist im Copy-Modus abstürzen und von vorn beginnen lassen.
- FFmpeg startet sich weder selbst neu noch benachrichtigt es dich.
- Jedes zusätzliche Ziel addiert seine volle Bitrate zum ausgehenden Traffic.
So sieht das DIY-Setup auf dem VPS aus
Der typische selbst gehostete Stack besteht aus vier Teilen:
- Ein Linux-VPS mit genug Speicherplatz für deine Bibliothek und ausreichend ausgehendem Traffic für einen Stream, der nie stoppt.
- Deine Videodateien, per SFTP hochgeladen oder aus einem Speicher synchronisiert.
- Eine Playlist-Datei für den Concat-Demuxer von FFmpeg.
- Ein FFmpeg-Befehl, der die Playlist in Echtzeit liest, in Schleife abspielt und an eine Ingest-URL wie
rtmp://a.rtmp.youtube.com/live2plus deinen Streamschlüssel schickt.
Die meisten Tutorials nutzen den Stream-Copy-Modus, bei dem FFmpeg Video und Audio ohne Neukodierung durchreicht. Die CPU-Last bleibt winzig, ein kleiner Server kommt also locker mit, und der erste Stream ist tatsächlich schnell gestartet.
Der Haken: Der Copy-Modus läuft nur dann sauber, wenn jede Datei technisch einheitlich ist – und genau da fließt der langfristige Aufwand hin.
Encoding und Timestamps: Warum FFmpeg-Playlists neu starten
Mit Stream Copy fügt FFmpeg die Dateien so zusammen, wie sie sind – eine einzige abweichende Datei zerstört also die Übergänge. Die üblichen Verdächtigen:
- Abweichende Framerates, etwa ein Export mit 29,97 fps neben Dateien mit 30 fps oder eine Handyaufnahme mit variabler Framerate.
- Unterschiedliche Auflösungen oder Audioformate, zum Beispiel ein 720p-Clip zwischen 1080p-Dateien.
- Seltsame Timebases oder fehlende Timestamps, die manche Schnittprogramme und Bildschirmrekorder hinterlassen.
Die Symptome reichen von Warnungen im Log über eingefrorenes Bild bis zum Beenden von FFmpeg. Beim Neustart beginnt die Playlist wieder mit dem ersten Video, und deine Zuschauer sehen immer wieder dieselbe erste Stunde.
Die Lösung: Alles vor der Aufnahme in die Playlist auf ein einheitliches Profil neu kodieren – gleiche Auflösung, konstante Framerate, gleiches Keyframe-Intervall und gleiches Audioformat. Mehr dazu in unserem Guide zu Encoding-Einstellungen für 24/7-Streaming.
Abstürze, Neustarts und Monitoring in Eigenregie
FFmpeg ist großartig, aber es ist ein einzelner Prozess, dem es egal ist, ob er weiterläuft. Wenn die Plattform die Verbindung trennt, das Netzwerk kurz hakt oder eine Datei einen Fehler auslöst, beendet er sich – und nichts holt ihn zurück, es sei denn, du hast Folgendes gebaut:
- Einen Supervisor, etwa einen systemd-Dienst mit automatischem Neustart.
- Positionstracking, damit ein Neustart die Playlist nicht wieder von oben beginnt.
- Health-Checks, die bestätigen, dass die Plattform tatsächlich Video empfängt – denn ein laufender Prozess kann trotzdem offline angezeigt werden.
- Benachrichtigungen aufs Handy, damit ein Ausfall um 3 Uhr nachts nicht bis zum Frühstück dauert.
Dazu kommt die Wartung: Updates, Neustarts, Festplatten, die mit Logs volllaufen, und Streamschlüssel im Klartext in Skripten. Nichts davon ist für sich allein schwer; zusammen ist es ein Teilzeitjob. Was du im Blick behalten solltest, liest du in Stream-Zustand und Uptime überwachen.
Bandbreite und mehrere Ziele von einem Server
Ein Nonstop-Stream verbraucht mehr Daten, als viele erwarten. Ein einzelner 6-Mbit/s-Stream, der 30 Tage läuft, sendet rund 1,9 TB. Schickst du ihn an drei Plattformen, pusht der Server rund um die Uhr etwa 18 Mbit/s – knapp 6 TB im Monat. Prüf das Kontingent für ausgehenden Traffic und die Konditionen für Mehrverbrauch bei deinem Anbieter.
Multi-Destination mit FFmpeg hat eigene Tücken. Ein Prozess pro Plattform heißt mehrere Prozesse, die überwacht werden müssen. Der Tee-Muxer von FFmpeg schickt einen Input an mehrere Outputs, aber ein einziges fehlschlagendes Ziel – etwa eine Plattform, die einen veralteten Schlüssel ablehnt – kann den ganzen Prozess lahmlegen, wenn nicht jeder Output so konfiguriert ist, dass er Fehler toleriert.
Auch die Eigenheiten der Plattformen bleiben an dir hängen, etwa das 12-Stunden-Archivlimit von YouTube, das eine simple Schleife ignoriert.
Wann ein DIY-Stream auf dem VPS die richtige Wahl ist
Self-Hosting passt, wenn die meisten dieser Punkte zutreffen:
- Du fühlst dich auf der Linux-Kommandozeile wohl und wartest gern Systeme.
- Du streamst an ein Ziel oder bist bereit, die Fehlerbehandlung für mehrere Ziele selbst zu bauen.
- Deine Bibliothek ist klein und stabil, und du bestimmst, wie jede Datei exportiert wird.
- Ein gelegentlicher Neustart vom Anfang der Playlist ist für dein Publikum kein großes Problem.
- Du willst lernen, wie Streaming unter der Haube funktioniert.
Ein Managed-Dienst ist sinnvoller, wenn der Stream Einnahmen oder eine Marke trägt, du häufig Videos hinzufügst, mehrere Plattformen brauchst oder deine Zeit besser in Content investiert ist. Der faire Vergleich lautet: Serverrechnung plus Stunden für Setup und nächtliche Fixes gegen einen Dienst, der diese Probleme bereits gelöst hat.
Dieselbe 24/7-Schleife stattdessen mit StreamHouse
StreamHouse ersetzt jeden Baustein dieses Stacks. Uploads werden vorab auf ein einheitliches Encoding-Profil gebracht, das Bitrate und Timestamps stabil hält – eine abweichende Datei startet deine Playlist also nicht neu. Du baust die Playlist im Browser, fügst Ziele wie YouTube, Twitch, Rumble, Facebook, eigenes RTMP oder SRT hinzu und drückst auf Start oder planst einen Zeitpunkt.
Die Schleife läuft 24/7 in der Cloud und verbindet sich nach Aussetzern der Plattform oder des Netzwerks automatisch neu. Du kannst Videos während des Livestreams hinzufügen, entfernen oder umsortieren; Änderungen greifen beim nächsten Video. Zusätzliche Ziele belegen keine zusätzlichen Stream-Slots, und bei einem verbundenen YouTube-Kanal kann der Aufzeichnungsschutz die erste Übertragung an einem von dir gewählten Punkt beenden und in einer neuen fortsetzen, ohne die Playlist neu zu starten.
Abos und Pay-as-you-go-Guthaben vergleichst du auf der Preisseite.
Häufig gestellte Fragen
Kann ich einen 24/7-YouTube-Stream mit FFmpeg auf einem VPS betreiben?
Ja. Ein FFmpeg-Befehl in Dauerschleife, der auf die RTMP-URL von YouTube zeigt, hält einen Kanal live. Schwierig ist, ihn wochenlang gesund zu halten: einheitliches Encoding, automatische Neustarts, Monitoring und die Archivierung langer Übertragungen liegen komplett bei dir.
Warum startet meine FFmpeg-Playlist immer wieder von vorn?
Meist passt eine Datei nicht zu den anderen – mit abweichender Framerate, Auflösung oder anderem Audioformat. Im Copy-Modus brechen dann die Timestamps, FFmpeg beendet sich und startet beim ersten Video neu. Kodiere jede Datei auf ein einheitliches, konstantes Profil neu.
Wie viel Bandbreite verbraucht ein 24/7-Stream pro Monat?
Rund 1,9 TB für einen einzelnen 6-Mbit/s-Stream, der 30 Tage nonstop läuft, und entsprechend mehr bei höheren Bitraten oder zusätzlichen Zielen. Drei Plattformen bei dieser Bitrate bedeuten knapp 6 TB – prüf also vorher das Traffic-Kontingent deines Servers.
Brauche ich einen leistungsstarken VPS für 24/7-Streaming?
Nicht, wenn du die Dateien vorab kodierst und Stream Copy nutzt – das braucht sehr wenig CPU. Echtzeit-Encoding in 1080p auf dem Server ist etwas anderes: Dafür brauchst du dedizierte Kerne, und kleine Shared-Tarife schaffen oft keine Echtzeitgeschwindigkeit.
