Untertitel in Video einbrennen: der Rendi-Workflow

Kurz erklärt

SRT-Untertitel sollten eingebrannt werden, wenn alle Zuschauer unabhängig von den Funktionen des Players denselben Text sehen müssen. Als separate Datei oder Spur bleiben sie sinnvoller, wenn Untertitel abschaltbar sein sollen, mehrere Sprachen gebraucht werden oder die Bedienhilfen des Players verfügbar bleiben müssen.

Mit Rendi funktioniert der Ablauf so:

1. Das endgültige Video zusammen mit der SRT-Datei prüfen.
2. Beide Dateien über URLs bereitstellen, die Rendi abrufen kann, oder lokale Dateien zuerst zu Rendi hochladen.
3. Den dokumentierten FFmpeg-Befehl für Untertitel absenden.
4. Die Befehls-ID abfragen oder das Endergebnis per Webhook empfangen.
5. Die Metadaten der MP4 kontrollieren und die gesamte Ausgabe ansehen, bevor weitere Aufträge gestartet werden.

Diese Reihenfolge ist wichtig. Auch ein technisch erfolgreicher Encode kann unbrauchbar sein, wenn ein Untertitel zu früh erscheint, ein Name falsch geschrieben ist oder Text von der Bedienoberfläche einer Plattform verdeckt wird.

Untertitel in Video einbrennen: Was Rendi übernimmt

Rendi ist der Maschinenraum, nicht die Redaktion. Derselbe FFmpeg-Befehl, der lokal ausgeführt werden könnte, wird über eine HTTP-API übermittelt. Die Anfrage lässt sich als Arbeitsauftrag lesen: Eingabe-Aliasse verweisen auf das Ausgangsmaterial, der FFmpeg-String beschreibt die Verarbeitung und ein Ausgabe-Alias benennt das fertige Ergebnis.

Das aktuelle Anfrageschema verlangt ffmpeg_command und output_files. Schlüssel für Eingaben beginnen mit in_, Schlüssel für Ausgaben mit out_; dieselben Namen stehen im Befehl zwischen doppelten geschweiften Klammern. Nach erfolgreicher Übermittlung kommt eine command_id zurück – der Abholschein für den Auftrag.

Im einfachsten Fall liegen Video und SRT unter öffentlichen oder zeitlich begrenzten, signierten HTTP-URLs, an deren Ende jeweils ein Dateiname steht. Ein lokaler Pfad auf einem Laptop ist keine Eingabe-URL. Für lokale Dateien bietet Rendi außerdem einen mehrteiligen Direkt-Upload für Dateien bis 5 TB an; das ist allerdings ein eigener Vorbereitungsschritt.

Eingebrannte Untertitel und zuschaltbare Spuren sind nicht dasselbe

Eingebrannte Untertitel werden Bestandteil jedes decodierten Einzelbilds. Damit ist ihre Darstellung vorhersehbar, die Entscheidung aber auch dauerhaft. Schon eine Rechtschreibkorrektur erfordert ein neues Rendering, und Zuschauer können den Text nicht ausblenden.

Eine zuschaltbare Untertitelspur bleibt vom Bild getrennt. Für eine solche weiche Untertitelspur in einer MP4 empfiehlt das Rendi-Beispiel mov_text und verzichtet auf den Videofilter. So behalten Zuschauer die Kontrolle, ohne dass der Text fest ins Bild geschrieben wird.

Die klare Empfehlung: Für einen Review-Master oder eine Social-Media-Datei sind eingebrannte Untertitel richtig, wenn eine konsistente Darstellung entscheidend ist. Die ursprüngliche SRT-Datei sollte trotzdem erhalten bleiben. Wo Barrierefreiheit, Suche, Übersetzung oder Wahlfreiheit zählen, gehört zusätzlich eine zuschaltbare Spur oder eine separate Untertiteldatei zur Auslieferung.

Die SRT-Datei vor dem Rendering prüfen

Am günstigsten ist das Rendering, das nicht wiederholt werden muss. Deshalb gehört die SRT-Datei gegen exakt die endgültige Schnittfassung geprüft, nicht gegen einen früheren Export. Zu kontrollieren sind die Reihenfolge der Einblendungen, Start- und Endzeiten, Namen und Zahlen, beabsichtigte Zeilenumbrüche sowie repräsentative Akzentzeichen oder Zeichen nichtlateinischer Schriften. Untertitel dürfen weder mit Bauchbinden kollidieren noch zu dicht am unteren Bildrand stehen.

KI-Transkription sollte gedanklich nicht mit diesem Schritt vermischt werden. Spracherkennung kann vorgelagert einen SRT-Entwurf erzeugen. In diesen Ablauf darf die Datei jedoch erst gelangen, nachdem ein Mensch oder ein verlässlicher Prüfprozess Text und Timing freigegeben hat. Rendi übernimmt hier ausschließlich das Rendering.

Einen formatierten Rendi-Auftrag absenden

Das folgende Node.js-Beispiel verwendet das öffentliche Beispielvideo und die Beispiel-SRT von Rendi. Zur Ausführung ist daher nur RENDI_API_KEY nötig. Die Nutzlast entspricht den Feldnamen und Alias-Regeln der aktuellen OpenAPI-Spezifikation von Rendi. Die Werte in force_style erzeugen weißen Text mit schwarzer Kontur und Abstand zum unteren Rand; libx264 und AAC liefern die MP4 aus dem Untertitel-Rezept von Rendi.

const headers = {
  "X-API-KEY": process.env.RENDI_API_KEY,
  "Content-Type": "application/json",
};

const submit = await fetch("https://api.rendi.dev/v1/run-ffmpeg-command", {
  method: "POST",
  headers,
  body: JSON.stringify({
    input_files: {
      in_video: "https://storage.rendi.dev/sample/big_buck_bunny_720p_16sec.mp4",
      in_srt: "https://storage.rendi.dev/sample/subtitles.srt",
    },
    output_files: { out_1: "subtitled.mp4" },
    ffmpeg_command:
      "-i {{in_video}} -vf \"subtitles={{in_srt}}:force_style='FontSize=22,PrimaryColour=&H00FFFFFF,OutlineColour=&H00000000,BorderStyle=1,Outline=2,Shadow=0,MarginV=36'\" -c:v libx264 -crf 20 -c:a aac -b:a 192k {{out_1}}",
  }),
});

if (!submit.ok) throw new Error(await submit.text());
const { command_id } = await submit.json();

for (;;) {
  const poll = await fetch(
    `https://api.rendi.dev/v1/commands/${command_id}`,
    { headers: { "X-API-KEY": process.env.RENDI_API_KEY } },
  );
  const job = await poll.json();
  if (job.status === "SUCCESS") {
    console.log(job.output_files.out_1);
    break;
  }
  if (job.status === "FAILED") throw new Error(job.error_message);
  await new Promise((resolve) => setTimeout(resolve, 2000));
}

Da der Untertitelfilter die Einzelbilder verändert, muss das Video neu codiert werden. Stil, Codec und Qualität lassen sich anpassen, doch jede Änderung erzeugt eine neue Ausgabe, die erneut geprüft werden muss. Das offizielle FFmpeg-Cheatsheet von Rendi beschreibt außerdem eigene Schriftarten über fontsdir und FontName. Vor dem Einsatz in einer ganzen Bibliothek sollten genau diese Schriftart und der benötigte Zeichenvorrat getestet werden.

Was tatsächlich getestet wurde

Am 11. September 2026 wurden Endpunkt, Anfragefelder, Alias-Regeln, Statuswerte und Antwortfelder aus dem Beispiel mit der aktuellen OpenAPI-Datei von Rendi abgeglichen. Der exakte Untertitelfilter lief außerdem lokal mit FFmpeg 8.0.1 über das öffentliche Beispielvideo und die Beispiel-SRT von Rendi. Das Ergebnis war eine 16 Sekunden lange MP4 in 1280 mal 720 mit H.264-Video und AAC-Audio; in einem bei Sekunde fünf entnommenen Einzelbild war der erwartete Untertitel sichtbar.

Ein Auftrag in der Rendi-Cloud wurde nicht abgesendet, weil in dieser Umgebung kein Rendi-API-Schlüssel vorhanden war. Der Code wurde gegen das Schema geprüft und die FFmpeg-Verarbeitung lokal verifiziert; eine Ausführung in der Cloud wird damit nicht behauptet.

Kurze Aufträge abfragen, längere per Webhook empfangen

Der Status-Endpunkt von Rendi kann QUEUED, PROCESSING, PREPARED_FFMPEG_COMMAND, FAILED oder SUCCESS zurückgeben. Ein angenommener POST ist noch kein fertiges Video. Erst einen Endstatus abwarten, bei einem Fehlschlag error_message ausgeben und die Ausgabedatei nur nach erfolgreichem Abschluss verwenden.

Für Aufträge, die voraussichtlich höchstens etwa 30 Sekunden benötigen, empfiehlt Rendi Statusabfragen; bei längeren Verarbeitungen ist ein Webhook vorgesehen. Er enthält dieselben Daten zum abgeschlossenen Befehl wie die abgefragte Antwort. In Produktion sollte der Abschluss-Handler idempotent sein, zügig antworten und Statusabfragen als Ausweichweg beibehalten, falls die Webhook-Zustellung letztlich scheitert.

Vertrauliche Ausgaben lassen sich in einem kostenpflichtigen Tarif mit is_private: true schützen. Beim Abfragen kann dann eine vorsignierte URL angefordert werden. Standardmäßig ist der Speicher öffentlich. Eine private Datei besitzt keine dauerhafte öffentliche URL; der angeforderte Download-Link kann höchstens 7 Tage gültig sein.

Ausgabe prüfen, bevor Stapelaufträge beginnen

SUCCESS beweist nur, dass FFmpeg fertig geworden ist – nicht, dass die Untertitel gut sind. Deshalb müssen sowohl die maschinenlesbare Antwort als auch das sichtbare Ergebnis kontrolliert werden.

Zuerst prüfen, ob output_files.out_1 vorhanden ist und sich dessen storage_url öffnen lässt. Zurückgemeldete Dauer, Abmessungen, Codec und Dateiformat müssen zur vorgesehenen Auslieferung passen. Anschließend das ganze Video ansehen, besonders den ersten und letzten Untertitel, den schnellsten Wortwechsel, Zeilenumbrüche, Namen, Zahlen sowie Einblendungen in der Nähe von Schnitten oder Grafikelementen.

Erst nach dieser Kontrolle sollte dieselbe Formatvorlage in eine Warteschlange wandern. Gemeinsam zu speichern sind die Revision des Ausgangsvideos, die SRT-Revision, der FFmpeg-Befehl, die Rendi-Befehls-ID, die ID der Ausgabedatei und die Prüfentscheidung. So wird aus einer Ansammlung von Renderings ein Produktionssystem.

Die Kosten richten sich nach Bytes, nicht nach Minuten

Rendi zählt die gemeinsame Größe der Ein- und Ausgabemedien. Im Preisbeispiel ergeben eine Eingabe mit 1 GB und eine Ausgabe mit 0.5 GB zusammen 1.5 GB Verarbeitung. Genau nach dieser Rechnung reichen die 50 GB des Free-Tarifs für 33 vollständige Aufträge, wobei 0.5 GB übrig bleiben. Die 250 GB des Pro-Einstiegstarifs decken 166 vollständige Aufträge ab und lassen 1 GB frei.

Diese Auftragszahlen ergeben sich rechnerisch aus dem Rendi-Beispiel; es handelt sich nicht um einen Untertitel-Benchmark. Eine tatsächlich gerenderte MP4 kann je nach Quelle, Codec-Einstellungen und Ausgabe größer oder kleiner ausfallen. Für eine realistische Mengenplanung zählt daher die eigene Summe aus Eingabe und Ausgabe.

Free kostet $0 pro Monat, enthält 50 GB Verarbeitung und begrenzt einen Befehl auf 1 Minute Laufzeit. Der Pro-Einstiegstarif kostet $25 pro Monat, umfasst 250 GB und hebt das Limit pro Befehl auf 10 Minuten. Die vollständige Übersicht der Rendi-Preise behandelt auch Konfigurationen mit mehr CPU-Leistung und unbegrenzter Laufzeit; diese Tabelle muss hier nicht wiederholt werden.

Entscheidend ist der betriebliche Vergleich. Kapwing Pro ist mit $16 pro Mitglied und Monat bei jährlicher Abrechnung beziehungsweise $24 bei monatlicher Abrechnung gelistet. Für eine gelegentliche Einzelaufgabe ist ein visueller Editor einfacher. Rendi passt besser, wenn die Fertigstellung von Untertiteln ein wiederholbarer Systemschritt ist, der durch freigegebene Dateien ausgelöst und verfolgt wird, ohne dass dafür erneut jemand einen Editor öffnen muss.

Sieben Workflows mit dem größten Nutzen

Geeignet ist Rendi nicht für jeden, der Untertitel ergänzt. Den größten Nutzen haben Teams, denen bereits eine freigegebene SRT-Datei vorliegt und die denselben abschließenden Rendervorgang regelmäßig wiederholen.

Drei lohnende Produktideen

1. Stapelverarbeitung für markenkonforme Untertitel

Das ist die stärkste Chance. Denkbar ist ein schlankes Portal für Content-Teams und Agenturen: URL des angenommenen Videos, freigegebene SRT, benannte Formatvorlage, Prüfseite und herunterladbare MP4. Verkauft werden ein verlässlicher Ablauf und die Freigabe, nicht noch ein Universal-Editor.

Rund 1,900 Suchanfragen pro Monat in den USA entfallen auf add subtitles to a video; zugleich beginnt Kapwing Pro bei jährlicher Abrechnung bei $16 pro Mitglied und Monat. Die Nachfrage ist breit genug, um Nutzer zu gewinnen, während der wiederkehrende Team-Workflow konkret genug für ein fokussiertes Produkt ist.

Die kleinste verkaufsfähige Version benötigt Eingaben über signierte URLs, SRT-Prüfung, einige gesperrte Markenvorlagen, die Übermittlung an Rendi, Webhook-Verarbeitung, Ausgabemetadaten sowie eine menschliche Annahme oder Ablehnung. Die Herausforderung liegt in der Verteidigbarkeit. Ein Formular um einen einzelnen FFmpeg-Aufruf ist leicht kopiert. Dauerhafter Wert muss aus Freigabeverlauf, wiederverwendbaren Markenregeln, eindeutiger Zuordnung von Revisionen und zuverlässiger Fehlerbehebung entstehen.

2. Eine auf Automatisierung ausgelegte Untertitel-Render-API

Agenturen, die ihren Kunden keine FFmpeg-Syntax zumuten möchten, könnten einen einzigen stabilen Endpunkt erhalten. Der Kunde sendet Video-URL, SRT-URL, Namen der Formatvorlage und Callback-URL. Der Dienst übersetzt die Vorlage in einen geprüften Befehl und liefert ein normalisiertes Auftragsergebnis zurück.

Burn subtitles into video verzeichnet monatlich 40 Suchanfragen in den USA und einen CPC von $8.16. Das Volumen ist klein, die Absicht dahinter aber ungewöhnlich konkret. Die PAA-Frage „How can I permanently burn SRT subtitles into a video?“ formuliert beinahe schon die Produktanforderung.

Ein MVP braucht Authentifizierung, Anfragevalidierung, Zuordnung der Rendi-Aufträge, Idempotenzschlüssel, Webhook-Verifizierung, eine wiederholungssichere Zustandsverwaltung und Nutzungsdaten. Die Herausforderung ist der Vertrieb. Die Suche allein trägt das Geschäft nicht, und Rendi stellt die zugrunde liegende API bereits bereit. Durchsetzen kann sich die Zwischenschicht nur mit Agenturintegrationen, Vorlagen, Beobachtbarkeit und Support.

3. Untertitel-Vorabprüfung mit doppelter Ausgabe

Eine Prüfschleuse könnte eine SRT gegen das endgültige Video kontrollieren und aus dem freigegebenen Paar sowohl eine Review-MP4 mit eingebrannten Untertiteln als auch eine Auslieferungs-MP4 mit zuschaltbarer Spur erzeugen. Zielgruppe sind Lokalisierungs-, Schulungs- oder Medienbetriebsteams, bei denen immer wieder unklar ist, welche Untertitelrevision zu welchem Schnitt gehört.

Die tatsächlich gestellte PAA-Frage „How do I add SRT subtitles to a video?“ steht in aktuellen Ergebnissen neben der wiederkehrenden Verwechslung von permanenten und zuschaltbaren Untertiteln. Das Produkt löst beide Aufgaben, ohne dass Bedienende die Containermechanik allein auswählen müssen.

Das MVP benötigt die Auswertung der Einblendungen, einen Dauervergleich, eine Vorschau des sicheren Bildbereichs, Revisions-IDs, zwei kontrollierte FFmpeg-Rezepte und einen Freigabenachweis. Die Schwierigkeit: Eine grundlegende SRT-Prüfung ist ein Feature, kein Unternehmen. Prüfverlauf und Übergabekontrollen müssen so wertvoll sein, dass Teams das Produkt dauerhaft in ihrem Freigabeprozess behalten.

Grenzen und ehrliches Fazit

Rendi nimmt diesem Workflow die FFmpeg-Infrastruktur ab, nicht die redaktionelle Verantwortung. Das Tool korrigiert weder ein Transkript noch schlechtes Timing oder ungünstige Zeilenumbrüche. Ebenso entscheidet es nicht, ob eingebrannte Untertitel das richtige barrierefreie Format sind.

Auch ein verlustfreies Einbrennen ist nicht möglich. Der Untertitelfilter verändert die Einzelbilder des Videos, deshalb wird es neu codiert. Qualität, Laufzeit und Ausgabedateigröße hängen vom Befehl und vom Ausgangsmaterial ab. Die standardmäßige API-Sicherheitsgrenze beträgt 300 Sekunden; der Tarif bestimmt, welchen Höchstwert eine Anfrage setzen darf. Für lange oder rechenintensive Aufträge muss die zulässige Befehlslaufzeit des Tarifs zum tatsächlichen Encode passen.

Für einen einzelnen Gelegenheitsclip ist dieser Weg unnötig, wenn ein kostenloses Browser-Tool die Aufgabe bereits löst. Untertitel sollten nicht eingebrannt werden, wenn Zuschauer sie ein- und ausschalten können müssen. Und eine ungeprüfte Formatvorlage gehört nicht in die Stapelverarbeitung. Rendi überzeugt dort, wo dieselbe freigegebene Fertigstellungsregel zuverlässig auf viele Dateien angewendet werden muss.

Der nächste konkrete Schritt

Als Test genügen ein kurzes, freigegebenes Video und seine endgültige SRT-Datei. Beide kommen hinter abrufbare URLs; anschließend läuft die Beispiel-Nutzlast mit dem gewünschten Stil. Danach die zurückgemeldeten Metadaten prüfen und die gesamte MP4 auf dem kleinsten unterstützten Bildschirm ansehen. Erst nach dieser Kontrolle sollte der akzeptierte Befehl als Vorlage gespeichert und mit dem Punkt im Workflow verknüpft werden, an dem Video und Untertitel bereits als freigegeben gelten.

Wenn ein solcher geprüfter Medien-Workflow im Unternehmen verankert werden soll, bietet KI-Produktionssysteme den passenden Einstieg.