Transloadit

Qu’est-ce que MPEG-TS ?

MPEG-TS (flux de transport MPEG-2) est un conteneur organisé en paquets qui multiplexe les flux vidéo, audio et de données d’un ou plusieurs programmes avec les tables qui les décrivent ; les fichiers qui le contiennent utilisent couramment l’extension .ts. Il a été conçu pour les environnements où les erreurs sont probables, comme la transmission de programmes de radio ou de télévision.

Fonctionnement de MPEG-TS

Un flux de transport MPEG découpe les flux élémentaires et les tables de signalisation en paquets de taille fixe de 188 octets, chacun portant un identifiant de paquet (PID) de 13 bits. Un récepteur lit la table d’association des programmes sur le PID 0, la suit jusqu’à la table de correspondance de chaque programme et en déduit quels PID transportent la vidéo, l’audio et les données du programme. Un compteur de continuité sur chaque PID autre que celui des paquets nuls aide à détecter les paquets perdus, et un bit indicateur d’erreur de transport dans l’en-tête de chaque paquet, lorsqu’il est activé, signale au moins une erreur de bit non corrigeable dans ce paquet. Les références d’horloge de programme sont les horodatages dont est dérivée la temporisation du décodeur. Un multiplex peut transporter plusieurs programmes ayant des bases de temps indépendantes. Comme un récepteur peut commencer à recevoir un flux en cours, les tables sont normalement retransmises périodiquement ; la norme le recommande sans fixer de fréquence.

Points clés

  1. Un paquet de flux de transport fait toujours 188 octets et commence par l’octet de synchronisation 0x47 ; 4 de ces octets constituent l’en-tête, de sorte que le découpage en paquets entraîne un surcoût d’au moins 2,1 % avant les champs d’adaptation, les en-têtes PES ou le bourrage. Certains systèmes ajoutent des octets autour de chaque paquet : la transmission DVB par satellite ajoute 16 octets de parité Reed-Solomon pour atteindre 204, et le démultiplexeur de FFmpeg recherche aussi une variante de 192 octets ; un analyseur qui suppose un pas de 188 octets perd donc la synchronisation sur de telles captures.
  2. La table d’association des programmes sur le PID 0x0000 répertorie chaque programme et le PID de sa table de correspondance, qui répertorie à son tour les PID des flux élémentaires de ce programme. HLS impose des restrictions supplémentaires : chaque segment de flux de transport doit contenir un seul programme et inclure une PAT et une PMT, qui devraient constituer ses deux premiers paquets, sauf si un élément EXT-X-MAP les fournit. Les horodatages et les compteurs de continuité doivent aussi se poursuivre d’un segment au suivant, sauf si la liste de lecture signale une discontinuité. Une capture de diffusion contenant plusieurs programmes doit donc être réduite à un seul programme avant de pouvoir servir de segments HLS.
  3. Le compteur de continuité est une valeur de 4 bits par PID qui augmente de un, en revenant à zéro après 15, à chaque paquet contenant une charge utile. Il se répète légitimement sur les paquets qui ne contiennent qu’un champ d’adaptation et sur un unique doublon répété immédiatement, peut sauter des valeurs lorsque le flux active l’indicateur de discontinuité, et n’est pas défini pour les paquets nuls. Toute autre valeur est une erreur de continuité, dont la RFC 6990 énumère les causes : un paquet perdu, un ordre incorrect des paquets ou un paquet présent plus de deux fois. Lorsque la cause est une perte, l’amplitude du saut ne donne le nombre de paquets manquants contenant une charge utile que modulo 16 ; perdre exactement 16 paquets, ou tout multiple de 16, ne laisse donc aucun écart.
  4. Le remultiplexage peut extraire un seul programme d’un flux contenant plusieurs programmes, et insérer ou supprimer des paquets nuls pour modifier le débit de transport, sans recompresser l’audio ni la vidéo. Le remultiplexeur peut devoir corriger les valeurs de référence d’horloge de programme, car leur position dans le flux change. L’extraction seule ne rend pas un programme prêt pour HLS : la RFC 8216 recommande que chaque segment H.264 contienne une image IDR, et la spécification de création HLS d’Apple n’accepte que la vidéo H.264, HEVC, Dolby Vision ou AV1, exige fMP4 plutôt que des flux de transport pour HEVC, exige que chaque segment vidéo commence par une image IDR et exige que tout contenu source entrelacé soit désentrelacé. Un programme diffusé dont le codec n’est pas accepté par les lecteurs cibles, ou dont les images clés ne se situent pas à des limites de segments utilisables, doit être réencodé, tout comme la vidéo entrelacée diffusée qui doit respecter la spécification d’Apple.

Quand MPEG-TS est utile

Choisissez MPEG-TS pour la diffusion de programmes de radio ou de télévision, l’IPTV, les flux de contribution ou la diffusion traditionnelle de segments HLS. Sa résilience et sa prise en charge du multiplexage ajoutent un surcoût par rapport aux conteneurs optimisés pour le stockage fiable de fichiers.

Comment Transloadit vous aide avec MPEG-TS

Les Robots de Transloadit fondés sur FFmpeg répertorient MPEG-TS parmi les formats qu’ils peuvent lire et écrire. /video/encode dispose d’une option segment qui divise sa sortie en parties pour HTTP Live Streaming, nommées à l’aide de segment_prefix (le préfixe segment_ donne segment_0.ts, segment_1.ts, et ainsi de suite), et /video/adaptive conditionne les déclinaisons pour HLS, MPEG-DASH ou CMAF et écrit la liste de lecture ou le manifeste.

Explorer les possibilités de Transloadit en matière de formats de fichiers et de compression

Références

Transformer vos connaissances sur les médias en une chaîne de traitement opérationnelle

Reliez les téléversements, le traitement, l’IA, le stockage et la diffusion via une seule API déclarative — la pile d’encodage, la montée en charge et l’évolution constante des formats sont prises en charge pour vous.

Essayer Transloadit gratuitement