SRT vs VTT vs TTML : trois formats, trois rôles

Trois formats, trois métiers

SRT pour la portabilité, VTT pour le web, TTML pour la diffusion et la livraison OTT. Si vous avez déjà importé un fichier de sous-titres et l'avez vu échouer en silence, vous avez déjà vécu ce décalage. Les trois formats se ressemblent de l'extérieur, mais ils résolvent des problèmes différents, et la plupart des plateformes n'en acceptent qu'un ou deux.

Ce billet associe chaque format à son métier concret : sa structure, les lecteurs et plateformes qui l'acceptent, et les points où les spécifications de livraison OTT divergent de manière à compter si votre contenu se retrouve sur Netflix, Amazon ou Disney+. Pour le choix plus simple entre SRT et WebVTT, la comparaison SRT vs VTT va plus loin sans le contexte de diffusion.

SRT : le plus petit dénominateur commun

SRT (SubRip) est le plus ancien des trois et le format le plus largement pris en charge qui existe. Un fichier SRT brut ressemble à ceci :

1
00:00:01,000 --> 00:00:04,500
Ceci est la première légende.

2
00:00:05,000 --> 00:00:08,200
Ceci est la deuxième légende.

Chaque bloc contient un numéro de séquence, une plage horaire avec une virgule comme séparateur de millisecondes, et une ou deux lignes de texte. Cette virgule n'est pas un hasard : SRT a été créé en Europe, où la virgule est le séparateur décimal. Quand on convertit du SRT en VTT à la main et qu'on oublie de remplacer les virgules par des points, le fichier échoue silencieusement dans les navigateurs.

Les points forts du SRT sont indissociables de ses limites. Le format est si simple que tous les lecteurs vidéo, sur tous les systèmes d'exploitation, le lisent : YouTube, Vimeo, VLC, Plex, Premiere Pro, DaVinci Resolve, et la plupart des encodeurs de qualité diffusion. Si vous ne pouvez livrer qu'un seul format, livrez du SRT.

Les points faibles sont l’absence de style natif et la contrainte d’une langue par fichier. Si vous avez besoin de texte en gras, de couleur, de positionnement à l’écran ou d’attribution de locuteur dans les données de sous-titres elles-mêmes, le SRT ne peut pas les porter. La plupart des flux de travail qui exigent des sous-titres stylisés incrustent le texte dans les pixels de la vidéo, ce que le guide du générateur de sous-titres traite séparément.

VTT : la norme web moderne

Le WebVTT est le format que le W3C a conçu pour la vidéo HTML5, et c’est celui que tout navigateur moderne comprend nativement. La structure ressemble au SRT, mais utilise un point comme séparateur de millisecondes et intègre un support explicite pour le style, le positionnement et les métadonnées de locuteur :

WEBVTT

00:00:01.000 --> 00:00:04.500 line:90% align:center
<v Alice>Ceci est le premier sous-titre.

00:00:05.000 --> 00:00:08.200
<v Bob>Ceci est le deuxième sous-titre.

Les balises <v Alice> et <v Bob> sont des annotations vocales de locuteur, ce qui signifie qu’un fichier VTT peut transporter des données de diarisation dès la sortie de la boîte. Les paramètres de repère line:90% align:center indiquent au lecteur où afficher le texte à l’écran. Vous pouvez aussi attacher du CSS via le pseudo-élément ::cue pour la couleur, la taille de police et l’arrière-plan.

Le VTT est obligatoire si vous utilisez l’élément HTML5 <track> pour attacher des sous-titres à une balise <video> sur votre propre site. Tout navigateur moderne le lit nativement. Les lecteurs JavaScript comme Video.js et Plyr sont construits autour du VTT. Si vous publiez de la vidéo sur le web, c’est le format qu’il vous faut.

Là où le VTT pose problème, c’est pour les destinations hors web. YouTube accepte bien le VTT (ainsi que le SRT, le SBV, le TTML et le DFXP), mais la plupart des encodeurs grand public et des outils de diffusion par défaut privilégient le SRT ou exigent le TTML. Convertissez depuis le format que vous avez généré en premier ; le changement de timecode est la seule opération technique.

TTML : le format broadcast et OTT

TTML (Timed Text Markup Language) est ce que les grands services de streaming et les diffuseurs exigent à la livraison, et il n'est pas interchangeable avec SRT ou VTT pour ces destinations. Le fichier est en XML et paraît nettement plus lourd que les deux autres :

<?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>

Cette verbosité achète de vraies capacités : un style riche, plusieurs pistes de langues dans un seul fichier, un positionnement en pourcentage, du texte ruby pour le japonais, et des métadonnées structurées pour les auditeurs d'accessibilité. TTML est une spécification du W3C, mais en pratique chaque plateforme qui l'exige utilise un profil spécifique.

Les profils OTT : Netflix, Amazon, Disney+

C'est là que « TTML » cesse d'être une réponse unique. Les grands streamers imposent chacun un profil ou un ensemble de contraintes différent.

Netflix exige TTML1 avec une extension .xml ou .ttml pour toutes les langues. Le japonais fait exception : Netflix demande le format IMSC 1.1 spécifiquement pour le japonais, avec son propre identifiant de profil. Les exigences générales de TTML1 sont strictes : toutes les données de positionnement doivent utiliser uniquement des valeurs en pourcentage, jamais en pixels ; la taille de police doit être exprimée à 100 % ; les timecodes dépendent de la fréquence d'images de la source.

Amazon Prime Video est plus permissif que Netflix. Pour les sous-titres, il accepte les formats STL, DFXP/TTML, SCC et SRT. Pour les fichiers de sous-titres (dialogue uniquement), il accepte le DFXP/TTML, l'iTT (un sous-ensemble de TTML 1.0 développé par Apple) et le SRT. L'acceptation du SRT sur la piste de sous-titres signifie que de nombreux petits producteurs peuvent contourner entièrement le TTML pour les soumissions Prime Video Direct.

Disney+ exige l'IMSC 1.1 comme format de livraison général. Pour les contenus japonais, il publie son propre profil IMSC 1.1 avec des règles de validation distinctes.

EBU-TT-D est le profil que l'Union européenne de radio-télévision a développé pour la distribution IP et le streaming DVB-DASH. C'est un sous-ensemble du profil texte IMSC 1, avec des différences mineures. La plateforme Freely au Royaume-Uni (le service IPTV conjoint de BBC, ITV, Channel 4 et Channel 5 lancé en 2024) impose l'EBU-TT-D pour tous les lecteurs participants. Si un contrat mentionne « EBU-TT-D », il demande un fichier TTML contraint, pas un format totalement différent.

Mon avis : si vous ne livrez pas à un diffuseur ou à une plateforme OTT nommée, vous n'avez presque certainement pas besoin de TTML. La complexité du format est un coût qui ne paie que lorsqu'une spécification précise l'exige. En dehors de ces contrats, le reste de l'industrie est bien servi par le SRT et le VTT.

Tableau comparatif des fonctionnalités

Le classement est pratique : SRT pour la portée la plus large, VTT pour la vidéo HTML5, TTML quand un contrat exige un profil précis.

Conversion : ce que vous perdez dans chaque sens

Convertir entre les trois formats est surtout mécanique, mais la conversion n'est pas symétrique.

SRT vers VTT est quasi sans perte. Ajoutez un en-tête WEBVTT sur la première ligne et remplacez toutes les virgules des timecodes par des points. La structure des blocs reste identique. Si vous voulez des étiquettes de locuteur, ajoutez des annotations <v Name> à la main ou à partir d'une source de transcription diarisée.

SRT ou VTT vers TTML ajoute une structure que vous devez ensuite remplir. Les timecodes se transfèrent proprement. Les attributs de style sont soit vides (ce qui exige qu'un ingénieur de localisation les complète), soit auto-remplis par un outil de conversion. Le profil de plateforme n'est presque jamais géré par les convertisseurs génériques : vous devrez ajouter le désignateur de profil, les tailles de police en pourcentage uniquement, et tout mode de timecode basé sur la fréquence d'images que la spécification exige. Prévoyez un passage de contrôle qualité après toute conversion TTML.

TTML vers SRT est une conversion avec perte. Le style, le positionnement et les pistes multilingues disparaissent tous. Le SRT obtenu contient du texte brut avec des timecodes corrects, ce qui est souvent exactement ce qu'un upload YouTube exige.

Un piège de timing mérite d'être mentionné : les conversions TTML suppriment parfois la précision en millisecondes lorsque la source utilise des modes de timecode à différentes fréquences d'images (SMPTE vs temps média). Si les sous-titres semblent décalés d'une frame après conversion, c'est le mode de timecode qui est en cause, pas le contenu.

Les deux scénarios les plus courants en pratique :

1. Un client fournit un SRT et votre diffuseur exige du TTML pour un cahier des charges de livraison. Convertissez, puis ajoutez les champs de métadonnées requis et validez par rapport au cahier des charges. Le générateur de sous-titres peut produire un SRT à partir de l'audio si vous devez partir de zéro.
2. Un diffuseur fournit un TTML et vous avez besoin d'un SRT pour un upload YouTube ou un lecteur web. Convertissez et acceptez la perte de style. Le texte et le timing seront corrects.

La réalité des plateformes

Voici ce que chaque destination majeure accepte réellement, vérifié auprès de la documentation actuelle des plateformes :

• YouTube : SRT, VTT, SBV, TTML, DFXP, SCC et plusieurs formats de diffusion hérités via YouTube Studio.
• Vimeo : SRT et VTT.
• Facebook et Instagram : SRT uniquement via les outils de téléversement pour créateurs. La plupart des contenus courts incrustent les sous-titres dans la vidéo.
• TikTok : Aucun fichier de sous-titres externe. Incrustez dans la vidéo.
• Netflix : TTML1 (.xml/.ttml) pour toutes les langues ; IMSC 1.1 pour le japonais. Toutes les données de positionnement doivent utiliser uniquement des valeurs en pourcentage.
• Amazon Prime Video : DFXP/TTML, iTT et SRT pour les pistes de sous-titres.
• Disney+ : IMSC 1.1.
• Diffusion européenne / DVB-DASH : EBU-TT-D (un sous-ensemble contraint de TTML).
• Vidéo HTML5 sur votre propre site : VTT via l'élément <track>.

Si vous publiez sur plusieurs destinations, générez d'abord un SRT propre, puis convertissez en aval. Éditer du XML à la main est lent ; éditer un SRT en texte brut et reconvertir prend quelques secondes.

Choisir le bon format de départ

Pour la majorité des cas d'usage, générez d'abord un fichier SRT. Vous pouvez exporter un SRT directement depuis n'importe quelle transcription, corriger les erreurs dans un éditeur de texte brut, le téléverser sur YouTube et l'attacher à un fichier vidéo. Si votre destination est un lecteur HTML5 sur votre propre site, passez l'export en VTT. Si un diffuseur ou une plateforme OTT intervient dans la chaîne de livraison, convertissez à partir de votre source SRT une fois que vous avez confirmé le profil exact exigé par le cahier des charges.

Le format est rarement le goulot d'étranglement. La précision, des sauts de ligne lisibles et un minutage correct sont ce que les spectateurs remarquent. Une fois ces éléments réglés, la conversion de format n'est qu'une étape qui se compte en secondes. ConvertAudioToText génère des fichiers SRT et VTT directement à partir de n'importe quel fichier audio ou vidéo, ce qui vous donne une source propre à partir de laquelle travailler. Pour une livraison en TTML, utilisez ce SRT comme entrée de conversion plutôt que de convertir à partir d'un brouillon.

Questions fréquentes

Quelle est la différence entre SRT et VTT ?

Le SRT utilise une virgule comme séparateur de millisecondes dans les codes temporels (00:00:01,000) et n'a pas de ligne d'en-tête. Le VTT utilise un point (00:00:01.000) et commence par un en-tête WEBVTT. Le VTT prend également en charge les balises vocales, le positionnement en pourcentage et le style CSS. Pour la vidéo web en HTML5, le VTT est le bon choix. Pour une compatibilité maximale entre plateformes, le SRT va plus loin. La comparaison SRT vs VTT couvre en détail la décision entre ces deux formats.

Netflix exige-t-il le TTML ou l'IMSC ?

Netflix exige le TTML1 (extension de fichier .xml ou .ttml) pour toutes les livraisons de sous-titres et SDH dans la plupart des langues. L'IMSC 1.1 est exigé spécifiquement pour le contenu japonais, selon le propre profil IMSC 1.1 de Netflix. Les deux sont liés : l'IMSC est un profil TTML contraint, mais la nomenclature dans les spécifications Netflix est spécifique. Confirmez le profil exact par rapport à votre documentation de livraison partenaire Netflix actuelle avant de soumettre.

Puis-je convertir automatiquement un SRT en TTML ?

Oui, mais avec des réserves. Les convertisseurs génériques transfèrent correctement les codes temporels et le texte. En revanche, ils ne renseignent généralement pas le champ du profil spécifique à la plateforme, le dimensionnement de police en pourcentage, ni le mode de code temporel basé sur la fréquence d'images qu'exige un cahier des charges OTT donné. Après toute conversion automatique de SRT vers TTML, un contrôle qualité conforme à la spécification cible est obligatoire avant la livraison.

Quel format utiliser pour YouTube ?

SRT et VTT fonctionnent tous les deux sur YouTube. La plateforme accepte les deux, ainsi que plusieurs autres formats. SRT est le choix le plus courant, car c'est le format de sortie de presque tous les outils de transcription et il est plus simple à éditer à la main. VTT convient tout aussi bien si c'est ce que produit votre flux de transcription. Pour les sous-titres YouTube en particulier, le générateur de sous-titres produit l'un ou l'autre format à partir d'un fichier audio ou vidéo.

Sources

• Centre d'aide Netflix pour les partenaires : Exigences générales du guide de style pour le texte à horodatage
• Centre d'aide Netflix pour les partenaires : Profil texte Netflix IMSC 1.1
• Amazon Prime Video Direct : Exigences relatives aux sous-titres
• Aide YouTube : Fichiers de sous-titres et de légendes pris en charge
• W3C : WebVTT : le format de pistes texte vidéo du Web
• W3C : Profils TTML pour sous-titres et légendes Internet (IMSC 1.2)
• MDN Web Docs : IMSC : sous-titres et légendes pour le Web
• DVB : Systèmes de sous-titrage DVB-TTML