Anmelden Jetzt streamen
← Wissensdatenbank
Alle PlattformenVIDEO

Ein Broadcast-Video mit HandBrake oder ffmpeg encodieren

16. Juli 2026 · 6 Min. Lesezeit

Steam prüft einen Broadcast nicht, bevor er ausgestrahlt wird - es validiert das Konto, die Verbindung und das Encoding. Ist auch nur eines davon falsch, wird der Feed rundweg abgelehnt oder bricht mitten im Stream ohne Vorwarnung ab. Dieser Artikel deckt alle drei ab: wer überhaupt broadcasten darf, Valves veröffentlichte Encoding-Spezifikation und warum jede Einstellung existiert, wohin der Stream tatsächlich geht, und was du realistisch erwarten kannst, sobald er live ist.

Kann dieses Konto überhaupt broadcasten?

Nichts vom Encoding unten spielt eine Rolle, wenn das Konto selbst nicht broadcasten darf, und das ist der Schritt, den Leute überspringen, weil er nichts mit Video zu tun hat. Steam verlangt, dass das Streaming-Konto nicht limitiert ist - mindestens $5 an historischen Ausgaben auf der Plattform - und entweder die Berechtigung "Broadcast Live" hat oder in der Store Broadcast Beta eingeschrieben ist. Das Konto muss außerdem das gestreamte Spiel besitzen oder anderweitig Zugriff darauf haben, und es darf nicht Community Banned sein. Fehlt auch nur eines davon, geht ein perfekt spezifikationsgerechter H.264 High@4.1 Feed trotzdem nicht live, und der Fehler sieht von außen genauso aus wie ein schlechtes Encoding - der Stream startet einfach nicht, ohne dass etwas im Encoder-Log dafür verantwortlich zu machen wäre. Schließ das aus, bevor du einen Abend damit verbringst, deine Bitrate-Einstellungen infrage zu stellen. Es ist eine Fünf-Minuten-Prüfung gegen ein mehrstündiges Encoding-Kaninchenloch, und es ist billige Versicherung, das zuerst zu erledigen statt zuletzt.

Valves Spezifikation, vollständig

Alles Folgende stammt aus Valves eigener Dokumentation auf partner.steamgames.com, nicht aus Vermutungen. Der Video-Codec muss H.264, Profile High, Level 4.1 sein. Die Bildrate ist entweder 30 oder 60 FPS, das Seitenverhältnis 16:9, und das Keyframe-Intervall muss 2 Sekunden betragen. Die maximale Bitrate ist 7000 kbps CBR. Audio ist AAC-LC, gedeckelt bei 128 kbps. Keiner davon ist ein Vorschlag - Valve validiert den Stream bei der Verbindung dagegen, und ein Wert außerhalb der Spezifikation ist der Grund, warum ein Broadcast, der in deinem Encoder gut aussieht, nie live geht. Wir behandeln dieselben Zahlen mit mehr Kontext in Video-Spezifikationen und Encoding für Steam.

Verbindung zu Steam: die RTMP-Seite

Spezifikationsgerechtes Encoding verschafft dir einen konformen Feed; du musst ihn trotzdem irgendwohin senden, und dieser Teil bringt Leute seltener ins Stolpern, weil er einfacher ist als die Encoding-Einstellungen, nicht weil er undokumentiert wäre. Steams Broadcast-Ingest ist ein Standard-RTMP-Endpunkt: rtmp://ingest-rtmp.broadcast.steamcontent.com/app. Du wählst die Region nicht selbst - Steam wählt den tatsächlichen Upload-Server für dich basierend auf dem Standort des Kontos, so wie es auch Download-Server für Spielinstallationen wählt. Der Stream-Key wird auf steamcommunity.com/broadcast/upload unter "Create RTMP Minuten" generiert wird. Beim Erstellen wählst du die Basis-App-ID des Spiels, nicht einen DLC- oder Demo-Eintrag, da sich der Broadcast unabhängig davon, welche Edition du bewirbst, an die Basis-App hängt.

OBS ist die Software, zu der die meisten greifen, um das zu testen, aber sie ist nichts Steam-Spezifisches - jeder RTMP-fähige Encoder verbindet sich auf dieselbe Weise, ob das nun OBS, vMix, ein Hardware-Gerät oder ffmpeg ist, das direkt mit deinem Stream-Key auf die obige URL sendet. In OBS-Begriffen ist das der Streaming-Dienst "Custom", mit der Ingest-URL im Feld Server und dem Key im Feld Stream Key. Die RTMP-Ebene kümmert sich nicht darum, was die Bits erzeugt hat, nur dass sie bei der Ankunft Valves Spezifikation entsprechen.

Eine Sache, die es wert ist zu prüfen, wenn die Verbindung selbst gar nicht erst zustande kommt, unabhängig vom Encoding: RTMP läuft standardmäßig über TCP-Port 1935. Bei einer Heimverbindung ist das selten ein Problem, aber in einem Firmennetzwerk, einem Unternehmens-VPN oder einer abgeschotteten Cloud-VM kann ausgehender Verkehr auf Port 1935 von einer Firewall blockiert werden, die mit normalem Webverkehr auf 80 und 443 kein Problem hat. Wenn der Encoder die Ingest-URL überhaupt nicht erreichen kann - kein abgelehnter Stream, einfach keine Verbindung - , ist das die erste Sache, die du ausschließen solltest, bevor du von einem Problem auf Steam-Seite ausgehst.

Die eine Einstellung, die hart scheitert: das Keyframe-Intervall

Die meisten Felder der Spezifikation verzeihen kleinere Abweichungen - eine Bitrate, die leicht über der Obergrenze liegt, wird von Steams Ingest möglicherweise einfach gedeckelt. Das Keyframe-Intervall funktioniert nicht so. Valve stellt ausdrücklich klar, dass dein Stream nicht startet, wenn es nicht exakt 2 Sekunden beträgt. Keine Teilpunkte.

Ein Keyframe-Intervall von 2 Sekunden bedeutet, dass alle 2 Sekunden ein vollständiges Frame encodiert wird, auf das sich die Frames dazwischen beziehen. Bei 30 fps ergibt das eine GOP-Länge von 60 Frames, bei 60 fps sind es 120. Die meisten Encoder haben standardmäßig etwas anderes eingestellt - oft 4 oder 5 Sekunden, ausgelegt auf Dateigröße statt auf Live-Konformität - , weshalb das die Einstellung ist, die Leute übersehen, selbst wenn alles andere stimmt. Valve nennt hier explizit vMix: dessen Standard ist Main Profile bei Level 3.0, und diese Kombination muss geändert werden, bevor eine vMix-Ausgabe durchgeht. Nimm das als Warnung, dass die Standardeinstellungen deines eigenen Encoders wahrscheinlich ebenfalls nicht Steams Standards entsprechen, und prüfe sie explizit, statt es anzunehmen.

Warum konstante Bitrate, nicht variable

Valves Spezifikation verlangt CBR, nicht VBR, und der Grund liegt speziell im Live-Streaming, nicht in der Videoqualität im Allgemeinen. Variable Bitrate lässt den Encoder mehr Bits für komplexe Frames und weniger für einfache aufwenden, was großartig für eine Datei ist, die man einmal von Anfang bis Ende ansieht. Ein Live-Ingest-Server muss gegen eine annähernd konstante erwartete Datenrate puffern; ein Stream, der zwischen 2000 kbps und 9000 kbps hin- und herschwankt, lässt diesen Puffer entweder verhungern oder überlaufen, und beides äußert sich als Ruckeln oder abgebrochene Verbindung. CBR tauscht ein wenig Qualität bei einfachen Szenen gegen eine Datenrate, mit der die Ingest-Seite planen kann, und genau das braucht ein 24/7 Broadcast.

7000 kbps ist Valves dokumentierte Obergrenze, kein Zielwert. Direkt an dieser Grenze zu fahren lässt keinen Spielraum, falls dein Ausgangsmaterial kurz über deine eingestellte Rate hinausschießt, was normales Encoder-Verhalten ist, selbst im CBR-Modus. Ein sichererer Zielwert ist, ein paar hundert kbps unter der Obergrenze zu encodieren - 6000 kbps ist eine vernünftige Wahl, und genau das setzen wir aus demselben Grund standardmäßig an.

Was Steam nach dem Ingest mit deinem Feed macht

Es lohnt sich zu wissen, was mit dem Feed passiert, sobald er akzeptiert ist, hauptsächlich damit du nicht für ein Problem überkonstruierst, das Steam bereits löst. Sobald ein Broadcast etwa 10 gleichzeitige Zuschauer überschreitet, aktiviert Steam automatisch Transcoding und erzeugt Renditions in niedrigerer Auflösung - 720p, 480p und 360p - neben deinem originalen 1080p-Feed. Das geschieht vollständig serverseitig; du lädst nie mehr als einen Stream hoch und konfigurierst nie selbst eine Auflösungsleiter. Der einzelne oben beschriebene CBR-Feed ist das einzige Encoding, für das du verantwortlich bist. Wenn du Plattformen gewohnt bist, bei denen du selbst mehrere Bitrate-Varianten hochlädst, kannst du diese Gewohnheit hier ablegen - ein sauberer 1080p-Feed nach obiger Spezifikation ist die ganze Aufgabe, und das bedeutet auch, dass die Qualität dieses einen Feeds mehr zählt, nicht weniger, da er der Master ist, von dem alles andere unterhalb der Transcoding-Schwelle abgeleitet wird.

Encoding in HandBrake

HandBrake liefert dir konformen Output, aber die für Steam relevanten Felder liegen außerhalb seiner Standard-Presets. Stell den Container auf MP4 und den Video-Codec auf H.264 (x264). Wähl unter Framerate deinen Zielwert - 30 oder 60 - und stell ihn auf Constant, nicht Variable. Für die Ratensteuerung nutze Average Bitrate und stell sie auf 6000 kbps statt eines qualitätsbasierten (CRF-)Modus, da CRF konstruktionsbedingt variable Bitrate erzeugt.

Profile, Level und Keyframe-Intervall stecken im x264-Optionsstring des Advanced-Tabs. Stell Profile auf High und Level auf 4.1 in den jeweiligen Dropdowns, dann füge keyint=60:min-keyint=60 dem Optionsstring für 30 fps hinzu, oder keyint=120:min-keyint=120 für 60 fps - das ist dein 2-Sekunden-Intervall, ausgedrückt in Frames. Encodiere im Audio-Tab zu AAC mit 128 kbps.

Dasselbe in ffmpeg

Wenn du es lieber skriptest: Jedes Feld oben entspricht einem Flag. Das kodiert nach Spezifikation mit 30 fps, einem Zielwert von 6000 kbps und einem 2-Sekunden-GOP:

ffmpeg -i input.mp4 -c:v libx264 -profile:v high -level 4.1 -r 30 -g 60 -keyint_min 60 -sc_threshold 0 -b:v 6000k -maxrate 6000k -bufsize 12000k -c:a aac -b:a 128k -ar 44100 -pix_fmt yuv420p output.mp4

Das Paar, das man erklären sollte, ist -b:v, -maxrateund -bufsize , gesetzt auf denselben oder verwandte Werte - das ist es, was libx264 tatsächlich bei CBR hält, statt in Richtung seines standardmäßigen VBR-ähnlichen Verhaltens abzudriften. -g 60 ist die GOP-Länge für 30 fps (nutze 120 bei 60 fps), und -sc_threshold 0 hindert den Encoder daran, bei Schnitten ein zusätzliches Keyframe einzufügen, was andernfalls das von Valve geforderte feste 2-Sekunden-Intervall brechen würde.

Deine Ausgabe prüfen, bevor du live gehst

Statt einfach darauf zu vertrauen, dass dein Encoder das getan hat, worum du ihn gebeten hast, lohnt es sich, die Datei zurückzulesen, bevor du sie an Steams Ingest schickst. ffprobe, das zusammen mit ffmpeg ausgeliefert wird, gibt das tatsächliche Profil, Level und die Bildrate aus, die es in der Ausgabe findet - nicht die, die du angefordert hast:

ffprobe -v error -select_streams v:0 -show_entries stream=profile,level,r_frame_rate,bit_rate -of default=noprint_wrappers=1 output.mp4

Das gibt exakt aus, was in die Datei eingebacken wurde - steht dort beim Profil "Main" statt "High", oder zeigt das Level 3.1 statt 4.1 an, weißt du es, bevor Steam es dich auf die harte Tour lehrt. Die GOP-Länge direkt zu bestätigen ist etwas aufwendiger, aber eine grobe Prüfung ist, die Videopakete über die ersten paar Sekunden zu zählen; bei 30 fps mit einem 2-Sekunden-Intervall solltest du etwa alle 60 Frames einen Keyframe sehen. Es ist ein kleiner Schritt, aber er macht aus "der Stream wurde abgelehnt, was jetzt" ein "das Level ist falsch, korrigiere dieses eine Feld" - eine deutlich kürzere Debugging-Schleife.

Latenz: Was du tatsächlich erwarten kannst

Valve veröffentlicht keine offizielle Latenzangabe für Store Broadcasts, also behandle alles, was du dazu liest - auch hier - als berichteten Wert, nicht als Spezifikation. Mit diesem Vorbehalt: Nutzer berichten für Store Broadcasts üblicherweise von einer Latenz von rund 30 Sekunden, gegenüber etwa 15 Sekunden bei Twitch. Valves eigene Patch Notes haben eine Latenz von unter einer Sekunde beansprucht, allerdings speziell für 1-zu-1-Freundes-Broadcasts, nicht für den Store-Seiten-Feed, und manche Nutzer berichten, dass diese Verbesserung bei Store Broadcasts nie ankam. Nimm den Wert von ~30 Sekunden als groben, von der Community berichteten Wert, nicht als etwas, für das Valve schriftlich einsteht.

Bei einem geloopten, vorab aufgezeichneten Video spielt das in der Praxis keine Rolle. Latenz wird nur dann zum Problem, wenn jemand am anderen Ende mit dem interagieren muss, was gerade live passiert - Chat lesen, in Echtzeit reagieren, einen Countdown timen. Ein 24/7 Loop eines Trailers oder Gameplay-Reels hat nichts Live, das desynchronisieren könnte, also ist eine 30-Sekunden-Verzögerung für jemanden, der nur deine Shopseite anschaut, unsichtbar. Es ist nur dann eine echte Einschränkung, wenn du versuchst, etwas Interaktives über dieselbe Verbindung laufen zu lassen; siehe einen geloopten, vorab aufgezeichneten Broadcast betreiben für das, was als Loop gut funktioniert und was nicht.

Oder überspring den Encoder komplett

All das existiert, weil Steams Ingest unnachgiebig beim Encoding ist, nicht weil die Zahlen schwer zu finden sind. Mit Loopcast lädst du hoch, was du an Datei hast, und wir transkodieren sie automatisch auf 1920x1080 bei 30 fps, einem 2-Sekunden-Keyframe-Intervall, 6000 kbps CBR und AAC-LC-Audio mit 128 kbps und 44,1 kHz - dieselbe Spezifikation wie oben beschrieben, angewendet ohne dass du eine Codec-Einstellung oder eine RTMP URL anfasst. Sobald du einen Stream-Key von Steam hast, siehe wie du deinen Stream-Key bekommst , um es zu verbinden, und falls ein Stream sich jemals weigert zu starten, deckt Broadcast-Fehlerbehebung die häufigsten Ursachen ab, sowohl beim Encoding als auch bei der Berechtigung.

Überspring die Encoder-Einstellungen

Lade ein Video hoch, füge deinen Stream-Key ein, starte. Ab $0.72/Tag.

Jetzt streamen · $0.72/Tag
Hängst du fest? Frag in unserem Discord →