SRT vs VTT vs TTML: Drei Formate, drei Aufgaben

Drei Formate, drei Aufgaben

SRT steht für Portabilität, VTT für das Web, TTML für Broadcast und OTT-Auslieferung. Wenn du schon einmal eine Untertiteldatei hochgeladen hast und sie still und leise gescheitert ist, bist du genau auf diese Diskrepanz gestoßen. Die drei Formate sehen von außen ähnlich aus, lösen aber unterschiedliche Probleme, und die meisten Plattformen akzeptieren nur ein oder zwei davon.

Dieser Beitrag ordnet jedes Format seiner realen Aufgabe zu: wie es strukturell aussieht, welche Player und Plattformen es akzeptieren und wo die OTT-Auslieferungsspezifikationen auf eine Weise voneinander abweichen, die zählt, wenn deine Inhalte bei Netflix, Amazon oder Disney+ landen. Für die einfachere Zwei-Formate-Entscheidung zwischen SRT und WebVTT geht der SRT-vs-VTT-Vergleich tiefer, ohne den Broadcast-Kontext.

SRT: Der kleinste gemeinsame Nenner

SRT (SubRip) ist das älteste der drei Formate und das am breitesten unterstützte überhaupt. Eine nackte SRT-Datei sieht so aus:

1
00:00:01,000 --> 00:00:04,500
Dies ist die erste Untertitelung.

2
00:00:05,000 --> 00:00:08,200
Dies ist die zweite Untertitelung.

Jeder Block hat eine Sequenznummer, einen Zeitcodebereich mit einem Komma als Millisekunden-Trennzeichen und ein oder zwei Textzeilen. Dieses Komma ist kein Zufall: SRT wurde in Europa entwickelt, wo das Komma das Dezimaltrennzeichen ist. Wenn Leute SRT von Hand in VTT konvertieren und vergessen, Kommas durch Punkte zu ersetzen, schlägt die Datei in Browsern still fehl.

Die Stärken von SRT sind untrennbar mit seinen Grenzen verbunden. Das Format ist so schlicht, dass es jeder Videoplayer auf jedem Betriebssystem liest: YouTube, Vimeo, VLC, Plex, Premiere Pro, DaVinci Resolve und die meisten Broadcast-Encoder. Wenn du nur ein Format ausliefern kannst, dann SRT.

Die Schwächen sind das fehlende native Styling und die Beschränkung auf eine Sprache pro Datei. Wenn du fette Schrift, Farbe, Bildschirmpositionierung oder Sprecherzuordnung direkt in den Untertitel-Daten brauchst, kann SRT das nicht transportieren. Die meisten Workflows, die gestylte Untertitel benötigen, brennen den Text direkt in die Videopixel, was der Untertitel-Generator-Leitfaden separat behandelt.

VTT: Der moderne Webstandard

WebVTT ist das Format, das das W3C für HTML5-Video entwickelt hat, und es ist dasjenige, das jeder moderne Browser nativ versteht. Die Struktur ähnelt SRT, verwendet aber einen Punkt als Millisekunden-Trenner und bringt explizite Unterstützung für Styling, Positionierung und Sprecher-Metadaten mit:

WEBVTT

00:00:01.000 --> 00:00:04.500 line:90% align:center
<v Alice>Dies ist die erste Untertitelung.

00:00:05.000 --> 00:00:08.200
<v Bob>Dies ist die zweite Untertitelung.

Die Tags <v Alice> und <v Bob> sind Sprecher-Stimmanmerkungen, was bedeutet, dass eine VTT-Datei Diarisierungsdaten von Haus aus mitführen kann. Die Cue-Einstellungen line:90% align:center sagen dem Player, wo auf dem Bildschirm der Text gerendert werden soll. Du kannst außerdem CSS über das Pseudo-Element ::cue für Farbe, Schriftgröße und Hintergrund anhängen.

VTT ist Pflicht, wenn du das HTML5-<track>-Element nutzt, um Untertitel an ein <video>-Tag auf deiner eigenen Website anzuhängen. Jeder moderne Browser liest es nativ. JavaScript-Player wie Video.js und Plyr sind auf VTT aufgebaut. Wenn du Webvideo veröffentlichst, ist das das Format, das du willst.

Wo VTT an seine Grenzen stößt, sind Nicht-Web-Ziele. YouTube akzeptiert zwar VTT (neben SRT, SBV, TTML und DFXP), aber die meisten Consumer-Encoder und Broadcast-Tools setzen standardmäßig auf SRT oder verlangen TTML. Konvertiere aus dem Format, das du zuerst erzeugt hast; der Zeitcode-Tausch ist die einzige technische Hürde.

TTML: Das Broadcast- und OTT-Format

TTML (Timed Text Markup Language) ist das Format, das große Streaming-Dienste und Rundfunkanstalten bei der Lieferung verlangen, und für diese Abnehmer ist es nicht mit SRT oder VTT austauschbar. Die Datei ist XML und wirkt deutlich schwergewichtiger als die anderen beiden:

<?xml version="1.0" encoding="UTF-8"?>
<tt xmlns="http://www.w3.org/ns/ttml"
    xmlns:tts="http://www.w3.org/ns/ttml#styling">
  <head>
    <styling>
      <style xml:id="default"
             tts:fontFamily="sansSerif"
             tts:color="white"
             tts:fontSize="100%"/>
    </styling>
  </head>
  <body>
    <div>
      <p begin="00:00:01.000" end="00:00:04.500"
         style="default">This is the first caption.</p>
      <p begin="00:00:05.000" end="00:00:08.200"
         style="default">This is the second caption.</p>
    </div>
  </body>
</tt>

Diese Ausführlichkeit erkauft sich echte Leistungsfähigkeit: umfangreiche Styling-Optionen, mehrere Sprachspuren in einer einzigen Datei, prozentbasierte Positionierung, Ruby-Text für Japanisch und strukturierte Metadaten für Barrierefreiheits-Prüfer. TTML ist eine W3C-Spezifikation, aber in der Praxis verwendet jede Plattform, die es vorschreibt, ein eigenes Profil.

Die OTT-Profile: Netflix, Amazon, Disney+

Hier hört „TTML" auf, eine einzige Antwort zu sein. Die großen Streaming-Anbieter schreiben jeweils ein anderes Profil oder einen anderen Satz von Einschränkungen vor.

Netflix verlangt für alle Sprachen TTML1 mit der Dateiendung .xml oder .ttml. Japanisch ist die Ausnahme: Für Japanisch schreibt Netflix speziell das IMSC-1.1-Format vor, mit eigener Profilkennung. Die allgemeinen TTML1-Anforderungen sind streng: Alle Positionsdaten müssen ausschließlich in Prozentwerten angegeben werden, niemals in Pixeln; die Schriftgröße muss als 100% ausgedrückt werden; die Zeitcodes hängen von der Bildrate des Quellmaterials ab.

Amazon Prime Video ist großzügiger als Netflix. Für Untertitel akzeptiert es STL, DFXP/TTML, SCC und SRT. Für Untertiteldateien (nur Dialog) akzeptiert es DFXP/TTML, iTT (eine von Apple entwickelte TTML-1.0-Untermenge) und SRT. Da SRT auch für die Untertitelspur akzeptiert wird, können viele kleinere Produzenten für Prime Video Direct-Einreichungen komplett auf TTML verzichten.

Disney+ verlangt IMSC 1.1 als allgemeines Lieferformat. Für japanische Inhalte veröffentlicht es ein eigenes IMSC-1.1-Profil mit separaten Validierungsregeln.

EBU-TT-D ist das Profil, das die European Broadcasting Union für IP-Verteilung und DVB-DASH-Streaming entwickelt hat. Es ist eine Untermenge des IMSC-1-Textprofils mit kleineren Abweichungen. Die britische Freely-Plattform (der gemeinsame IPTV-Dienst von BBC, ITV, Channel 4 und Channel 5, der 2024 gestartet ist) schreibt EBU-TT-D für alle teilnehmenden Player vor. Wenn ein Vertrag „EBU-TT-D“ erwähnt, verlangt er eine eingeschränkte TTML-Datei, kein völlig anderes Format.

Meine Einschätzung: Wenn Sie nicht an einen Broadcaster oder eine benannte OTT-Plattform liefern, brauchen Sie mit ziemlicher Sicherheit kein TTML. Die Komplexität des Formats ist ein Kostenfaktor, der sich nur auszahlt, wenn eine bestimmte Spezifikation es verlangt. Außerhalb solcher Verträge ist der Rest der Branche mit SRT und VTT bestens bedient.

Feature-Vergleichstabelle

Die Abstufung ist praktisch: SRT für die breiteste Reichweite, VTT für HTML5-Video, TTML wenn ein Vertrag ein bestimmtes Profil vorschreibt.

Konvertierung: Was Sie in jede Richtung verlieren

Die Umwandlung zwischen den drei Formaten ist meist mechanisch, aber die Konvertierung ist nicht symmetrisch.

SRT zu VTT ist nahezu verlustfrei. Fügen Sie in der ersten Zeile einen WEBVTT-Header hinzu und ändern Sie alle Komma-Trennzeichen in den Zeitcodes zu Punkten. Die Blockstruktur bleibt identisch. Wenn Sie Sprecherkennzeichnung möchten, ergänzen Sie <v Name>-Annotationen von Hand oder aus einer diarisierten Transkriptquelle.

SRT oder VTT zu TTML fügt Struktur hinzu, die Sie dann befüllen müssen. Die Zeitcodes übertragen sich sauber. Die Styling-Attribute sind entweder leer (was einen Lokalisierungsingenieur erfordert, der sie ausfüllt) oder werden von einem Konvertierungstool automatisch befüllt. Das Plattformprofil wird von generischen Konvertern fast nie berücksichtigt: Sie müssen den Profilbezeichner, die rein prozentbasierten Schriftgrößen und jeden bildratenbasierten Zeitcode-Modus hinzufügen, den die Spezifikation verlangt. Planen Sie nach jeder TTML-Konvertierung einen Qualitätskontroll-Durchlauf ein.

TTML zu SRT ist verlustbehaftet. Styling, Positionierung und mehrsprachige Spuren gehen alle verloren. Das resultierende SRT enthält Klartext mit korrekten Zeitcodes, was oft genau das ist, was ein YouTube-Upload braucht.

Eine zeitliche Stolperfalle, die erwähnenswert ist: TTML-Konvertierungen verlieren manchmal die Millisekundengenauigkeit, wenn die Quelle unterschiedliche Bildraten-Zeitcode-Modi verwendet (SMPTE vs. Media Time). Wenn Untertitel nach der Konvertierung um ein Frame versetzt wirken, liegt es am Zeitcode-Modus, nicht am Inhalt.

Die zwei häufigsten Szenarien in der Praxis:

1. Ein Kunde liefert ein SRT und dein Broadcaster verlangt TTML für eine Liefervorgabe. Konvertiere, füge dann die erforderlichen Metadatenfelder hinzu und validiere gegen die Vorgabe. Der Untertitel-Generator kann SRT aus Audio erzeugen, falls du von null starten musst.
2. Ein Broadcaster liefert ein TTML und du brauchst SRT für einen YouTube-Upload oder Webplayer. Konvertiere und akzeptiere den Styling-Verlust. Text und Timing werden korrekt sein.

Realitätscheck der Plattformen

Hier ist, was jede große Zielplattform tatsächlich akzeptiert, geprüft gegen die aktuelle Plattformdokumentation:

• YouTube: SRT, VTT, SBV, TTML, DFXP, SCC und mehrere ältere Broadcast-Formate über YouTube Studio.
• Vimeo: SRT und VTT.
• Facebook und Instagram: Nur SRT über die Creator-Upload-Tools. Die meisten Kurzformate brennen Untertitel ins Video ein.
• TikTok: Kein externer Untertitel-Datei-Upload. Ins Video einbrennen.
• Netflix: TTML1 (.xml/.ttml) für alle Sprachen; IMSC 1.1 für Japanisch. Alle Positionsdaten müssen ausschließlich Prozentwerte verwenden.
• Amazon Prime Video: DFXP/TTML, iTT und SRT für Untertitelspuren.
• Disney+: IMSC 1.1.
• Europäischer Broadcast / DVB-DASH: EBU-TT-D (eine eingeschränkte TTML-Untermenge).
• HTML5-Video auf der eigenen Website: VTT über das <track>-Element.

Wenn du auf mehr als eine Plattform veröffentlichst, erzeuge zuerst ein sauberes SRT und konvertiere dann nachgelagert. XML von Hand zu bearbeiten ist langsam; ein Klartext-SRT zu bearbeiten und neu zu konvertieren dauert Sekunden.

Das richtige Ausgangsformat wählen

Für die meisten Anwendungsfälle solltest du zuerst SRT erzeugen. Du kannst SRT direkt aus jeder Transkription exportieren, Fehler in einem einfachen Texteditor korrigieren, bei YouTube hochladen und an eine Videodatei anhängen. Wenn dein Ziel ein HTML5-Player auf deiner eigenen Website ist, stelle den Export auf VTT um. Wenn ein Broadcaster oder eine OTT-Plattform in der Lieferkette steckt, konvertiere von deiner SRT-Quelle, sobald du das genaue Profil bestätigt hast, das die Spezifikation verlangt.

Das Format ist selten der Engpass. Genauigkeit, lesbare Zeilenumbrüche und korrektes Timing sind das, was Zuschauer wahrnehmen. Sobald diese stimmen, ist die Formatkonvertierung ein Schritt, der in Sekunden gemessen wird. ConvertAudioToText erzeugt SRT und VTT direkt aus jeder Audio- oder Videodatei und gibt dir eine saubere Quelle, mit der du arbeiten kannst. Für die TTML-Auslieferung verwende diese SRT als Konvertierungseingabe, anstatt aus einem groben Entwurf zu konvertieren.

Häufige Fragen

Was ist der Unterschied zwischen SRT und VTT?

SRT verwendet ein Komma als Millisekunden-Trenner in den Zeitcodes (00:00:01,000) und hat keine Kopfzeile. VTT verwendet einen Punkt (00:00:01.000) und beginnt mit einem WEBVTT-Header. VTT unterstützt außerdem Sprecher-Sprachtags, prozentbasierte Positionierung und CSS-Styling. Für HTML5-Webvideo ist VTT die richtige Wahl. Für maximale plattformübergreifende Kompatibilität reicht SRT weiter. Der SRT vs. VTT Vergleich behandelt die Zwei-Format-Entscheidung im Detail.

Verlangt Netflix TTML oder IMSC?

Netflix verlangt TTML1 (Dateiendung .xml oder .ttml) für alle Untertitel- und SDH-Lieferungen in den meisten Sprachen. IMSC 1.1 ist speziell für japanische Inhalte erforderlich, unter Netflix' eigenem IMSC-1.1-Profil. Die beiden hängen zusammen: IMSC ist ein eingeschränktes TTML-Profil, aber die Benennung in den Netflix-Spezifikationen ist spezifisch. Bestätige das genaue Profil anhand deiner aktuellen Netflix-Partner-Lieferdokumentation, bevor du einreichst.

Kann ich SRT automatisch in TTML konvertieren?

Ja, aber mit Einschränkungen. Generische Konverter übertragen Zeitcodes und Text zuverlässig. Sie füllen aber in der Regel nicht den plattformspezifischen Profilbezeichner, die prozentbasierte Schriftgröße oder den Bildraten-Zeitcodemodus aus, den ein bestimmter OTT-Standard verlangt. Nach jeder automatischen SRT-zu-TTML-Konvertierung ist vor der Lieferung eine QC-Prüfung gegen den Zielstandard Pflicht.

Welches Format sollte ich für YouTube verwenden?

SRT oder VTT funktionieren beide auf YouTube. YouTube akzeptiert beide sowie mehrere andere Formate. SRT ist die häufigere Wahl, weil es das Ausgabeformat fast aller Transkriptionstools ist und sich einfacher manuell bearbeiten lässt. VTT funktioniert genauso gut, wenn dein Transkriptionsworkflow dieses Format erzeugt. Für YouTube-Untertitel im Speziellen erzeugt der Untertitel-Generator beide Formate aus einem Audio- oder Video-Upload.

Quellen

• Netflix Partner Help Center: Timed Text Style Guide General Requirements
• Netflix Partner Help Center: Netflix IMSC 1.1 Text Profile
• Amazon Prime Video Direct: Caption Requirements
• YouTube Help: Supported Subtitle and Closed Caption Files
• W3C: WebVTT: The Web Video Text Tracks Format
• W3C: TTML Profiles for Internet Media Subtitles and Captions (IMSC 1.2)
• MDN Web Docs: IMSC: Subtitles and Captioning for the Web
• DVB: DVB-TTML Subtitling Systems