SRT ou VTT : quel format choisir pour des sous-titres en temps réel ?

SRT : le plus simple, et c'est son mérite

SubRip (SRT) n'est qu'une suite de blocs numérotés : un index, deux horodatages séparés par une flèche, une ou deux lignes de texte, puis une ligne vide. Les millisecondes y sont séparées par une virgule.

1
00:00:01,000 --> 00:00:03,500
Bonsoir et bienvenue
dans ce journal.

2
00:00:03,600 --> 00:00:06,000
Premier titre ce soir…

Aucun style, aucun positionnement, aucune métadonnée. SRT n'a d'ailleurs jamais fait l'objet d'une norme formelle : il est né d'un logiciel, et l'encodage des caractères n'y est pas fixé. Certains lecteurs interprètent des balises comme l'italique ou le gras, sans garantie. Cette pauvreté est précisément ce qui le rend universel : logiciels de montage, lecteurs médias, YouTube et Vimeo l'acceptent sans discussion. C'est le format du transport, pas de la mise en forme.

WebVTT : conçu pour le web

WebVTT, spécifié par le W3C, est le format natif de l'élément <track> en HTML5. Il reprend la structure de SRT en y ajoutant ce qui manquait pour le web. Un fichier commence obligatoirement par la ligne WEBVTT, les millisecondes sont séparées par un point, et chaque sous-titre peut porter des réglages de placement.

WEBVTT

00:00:01.000 --> 00:00:03.500 line:85% align:center
<v Présentatrice>Bonsoir et bienvenue dans ce journal.

00:00:03.600 --> 00:00:06.000
Premier titre ce soir…

Les réglages line, position, size et align placent le texte à l'écran ; la balise de voix identifie le locuteur ; des classes permettent de styler le texte en CSS, via le pseudo-élément ::cue. Le format accepte aussi des commentaires, des pistes de chapitres et des pistes de métadonnées exploitables en JavaScript. Enfin, l'encodage est imposé : UTF-8, ce qui règle d'emblée les problèmes d'accents.

Pour un player web ou une plateforme de streaming, cette richesse n'est pas décorative : elle permet de placer un sous-titre au-dessus d'un bandeau d'information, ou de distinguer deux locuteurs. Un SRT converti mécaniquement en VTT reste un SRT : il n'acquiert aucune de ces capacités.

SRT et VTT, point par point

Ce que le direct change

En transcription temps réel, le fichier n'est jamais « fini » : il s'allonge pendant la diffusion. En HLS, les sous-titres sont découpés en segments WebVTT, comme la vidéo, et listés dans leur propre playlist. Chaque segment porte un en-tête X-TIMESTAMP-MAP (RFC 8216) qui aligne ses horodatages sur ceux du flux vidéo ; s'il manque ou s'il est faux, les sous-titres se décalent.

Deux conséquences pratiques. La durée des segments s'ajoute au délai d'affichage : des segments de six secondes retardent d'autant le texte à l'écran. Et un sous-titre qui chevauche deux segments doit être répété dans chacun pour rester visible. En DASH et en CMAF, les sous-titres voyagent dans des fragments MP4, en WebVTT ou en IMSC1 selon le cahier de livraison.

SRT n'a pas de place dans cette chaîne de diffusion, mais il reste parfait pour archiver l'émission une fois terminée, ou pour l'importer dans un logiciel de montage. Le choix se fait donc moins sur le format que sur le moment où le texte est consommé.

Convertir un SRT en VTT

La conversion est simple, à condition de ne rien oublier :

1. Ajouter la ligne WEBVTT en tête du fichier, suivie d'une ligne vide.
2. Remplacer la virgule des millisecondes par un point dans chaque horodatage.
3. Réenregistrer le fichier en UTF-8 : un SRT est souvent encodé autrement, et les accents sont les premiers à en souffrir.
4. Garder ou retirer les numéros : WebVTT les accepte comme identifiants de sous-titres.
5. Remplacer les balises non standard du SRT, comme les balises de police, par des classes WebVTT.

Le résultat est un VTT valide, mais sans positionnement ni style : ceux-ci ne s'ajoutent qu'à partir d'une source qui les porte.

Quel format pour quelle destination

• Montage et post-production : SRT, accepté partout.
• YouTube et Vimeo : les deux sont acceptés ; SRT suffit si aucun placement n'est nécessaire.
• Player web HTML5 : WebVTT, seul format lu nativement par l'élément <track>.
• Streaming HLS en direct : segments WebVTT, ou IMSC1 si le cahier de livraison l'exige.
• Archivage d'une émission : SRT pour la simplicité, TTML si les styles doivent être conservés.
• Diffusion broadcast : ni l'un ni l'autre ; voyez les formats professionnels comme EBU-TT-D, STL ou SCC.

Questions fréquentes

Un navigateur peut-il lire un fichier SRT ?

Pas nativement : l'élément track du HTML5 attend du WebVTT. Les lecteurs vidéo en JavaScript savent souvent convertir un SRT à la volée, mais le plus sûr est de livrer directement du VTT.

Pourquoi les accents de mon fichier SRT s'affichent-ils mal ?

Parce que SRT ne fixe pas d'encodage et que le fichier a probablement été enregistré dans un encodage ancien, comme Windows-1252, puis lu comme de l'UTF-8. Réenregistrez-le en UTF-8, ou passez à WebVTT, qui l'impose.

Peut-on placer un sous-titre en haut de l'écran en SRT ?

Pas de manière standard. Certains lecteurs reconnaissent des balises de position héritées d'autres formats, sans aucune garantie. Si le placement compte, par exemple pour ne pas masquer un bandeau, utilisez WebVTT.

OnAirText livre-t-il SRT et VTT pendant la diffusion ?

Oui. OnAirText produit les deux en continu à partir du même flux, dès le plan Starter, ainsi que les formats broadcast professionnels sur les plans supérieurs.