ST-2110 : Codecs

Comme son intitulé le laisse entendre, ce document définit comment transporter et signaliser de la vidéo non compressée. Cette partie du standard est intéressante dans les cas où :

Ce document définit comment transporter et signaliser de la vidéo compressée dans un écosystème ST 2110. Il y a deux choses majeures à noter :

ST 2110-30 se présente comme un profil restreint d’AES67, pensé pour le broadcast. Il impose le support de la fréquence d’échantillonage de 48 KHz et supprime les mécanismes orientés VoIP. Cela apporte l’immense avantage de garantir une compatibilité ascendante avec les infrastructures AES 67 ou compatibles.

Le format choisi est un flux PCM linéaire à 16 ou 24 bits.

ST 2110-31 permet de transporter dans une infrastructure ST 2110 des flux AES3. Or AES3 est un protocole d’encapsulation qui peut contenir aussi bien :

Nous sommes donc face à une encapsulation IP d’un flux qui encapsule lui-même une essence, à rebours de l’objectif initial du ST 2110 qui visait à clarifier le transport des essences. La comparaison avec la vidéo est d’ailleurs flagrante : là où ST 2110-22 spécifie explicitement le codec transportée, ST 2110-31 se limite à indiquer « AES3 », charge au récepteur de déterminer ce que le flux contient réellement.

D’un point de vue normatif, un premier problème apparaît : la même essence peut désormais être transportée de plusieurs façons différentes. Ainsi, un flux PCM peut transiter soit en ST 2110-30, soit en ST 2110-31. De même, certains flux de métadonnées peuvent être diffusés indifféremment en ST 2110-31 ou en ST 2110-4X.

Enfin, cette approche soulève une fois de plus des problèmes d’interopérabilité : aucune restriction n’est définie concernant les codecs ou un profil minimal de compatibilité, ouvrant la voie à des implémentations incompatibles entre elles.

Cette norme est une passerelle qui permet de transporter les données auxiliaires contenues dans les intervals de blanking (encore !) d’un signal SDI. Elle n’existe que comme mécanisme de compatibilité ascendante et devrait être progressivement remplacée par des alternatives mieux adaptées au monde IP.

ST 2110-41 a pour ambition d’offrir un mécanisme générique de transport des métadonnées. Le principe est séduisant : un format agnostique, capable d’encapsuler aussi bien du JSON ou du XML standardisés que des données propriétaires.

Cette partie du standard définit le transport des sous-titres et captions en utilisant TTML (Timed Text Markup Language), un format largement répandu et adapté au monde IP.

L’intérêt est double :

En SDI, le coût d’une infrastructure restait indépendant du débit transporté : une fois le câble et les équipements en place, diffuser un flux 4K coûte le même prix qu’un flux SD. En IP, les coûts augmentent proportionnellement à la bande passante consommée.

Pour contenir ces coûts, il devient donc essentiel d’optimiser l’utilisation de la bande passante en fonction des fonctionnalités réellement attendues. Ce principe s’applique déjà aux architectures on-premise, où le débit conditionne directement le dimensionnement du réseau. Mais il est encore plus crucial dans le cloud, où chaque mégabit est facturé.

Pour des raisons similaires, il est important de garder un œil sur la puissance de calcul nécessaire au traitement.

Une fois les contraintes sur les infrastructures énoncées, il est nécessaire de définir les attentes sur la diffusion des essences, notamment en termes de qualité et de latence.

En SDI, la transmission en bande de base garantit une qualité maximale et une latence quasi nulle : il est donc tentant d’attendre la même chose en IP.

Il faut cependant ne pas oublier que si cette bande de base peut être conservée de bout en bout lors des réalisations en direct, elle ne l’est plus dès qu’un enregistrement entre dans la chaîne. En pratique, XDCAM reste le format majoritairement utilisé dans ce cadre-là, XAVC Intra étant prêt à prendre la relève - or ces deux formats impliquent par nature une détérioration visuelle du signal tout en restant cependant conformes aux attentes des diffuseurs.

En termes de latence, il paraît raisonnable d’accepter un ordre de grandeur de quelques images entre le début de la chaîne et la sortie de régie finale : les délais induits par les modes de diffusion étant supérieurs de plusieurs ordres de grandeurs, y compris en streaming.

Pour l’audio, la situation est relativement simple. Les ressources nécessaires — tant en bande passante qu’en puissance de calcul — sont négligeables par rapport à la vidéo. Il n’y a donc aucune raison de se priver d’un transport PCM linéaire, tel que défini par ST 2110-30, qui garantit une interopérabilité directe avec AES67 déjà largement déployé.

Lorsque des métadonnées descriptives sont nécessaires, par exemple pour la production immersive, le flux peut être enrichi via S-ADM transporté en ST 2110-41. Cette combinaison (2110-30 + 2110-41) permet de conserver la clarté des essences sans insulter l’avenir.

Pour les métadonnées comme pour les sous-titres, les briques sont présentes. ST 2110-41 offre un cadre générique suffisamment souple pour la plupart des besoins, tandis que ST 2110-43 redonne aux sous-titres leur statut d’essence à part entière. Malgré quelques choix techniques discutables, l’ensemble est exploitable et cohérent avec l’esprit IP.

Le SCTE-104, utilisé pour signaler les points d’insertion publicitaire, reste aujourd’hui prisonnier du ST 2110-40 où il transite comme simple donnée auxiliaire héritée du SDI. Cette approche assure la compatibilité, mais elle reste en décalage avec l’esprit IP, où ces métadonnées mériteraient un transport natif. ST 2110-41 offre un cadre idéal, encore faudrait-il qu’un mapping officiel soit défini. En l’absence de standard, certains acteurs ont déjà pris les devants : SiriusXM a ainsi enregistré un Data Item Type (DIT) pour transporter du SCTE-104 en JSON sur 2110-41.