Les premiers standards qui ont défini les modalités du transport de signaux vidéo en IP sont rassemblés dans la norme SMPTE ST2022 avec ses différents chapitres numérotés de 1 à 7. Il faut rappeler que le standard ST2022 a d’abord été élaboré pour le transport des signaux vidéo sur des réseaux IP dans une perspective de contribution ou de distribution primaire vers des points de diffusion. D’ailleurs, les chapitres 1, 2, 3 et 4 de la ST 2022 définissent les paramètres et les conditions d’un transport en Mpeg-2 TS. Ce sont seulement les chapitres 5 et 6 qui précisent les conditions spécifiques à la distribution d’un signal SDI sur un réseau IP.
Si, pour des besoins de transmission et de distribution, il est normal d’associer les divers éléments du contenu (vidéo, audio et métadonnées) dans un multiplex unique pour éviter la dissociation des éléments, dans un environnement de production, au contraire, il est nécessaire de les dissocier facilement pour les recombiner en fonction des besoins de la production.
Le standard 2022-6 a vite montré ses limites dans cet usage et le VSF (Video Services Forum) a complété cette première norme avec les recommandations TR03 et TR04 pour offrir plus de souplesse en vue d’une introduction des réseaux IP dans le monde de la production.
Lors de l’élaboration de la norme ST2110, ses contributeurs ont souhaité éviter cette complication et l’une des bases de la ST2110 est de transporter chaque élément constitutif d’un programme dans un flux distinct de manière à ce que chacun d’eux soit orienté séparément sans passer son temps à dissocier ou réassocier les éléments à chaque étape de traitement.
Ainsi, un équipement récepteur demande exactement ce dont il a besoin pour la tâche qu’il exécute. Une conséquence pratique de cette séparation en éléments distincts est l’organisation de la ST2110 en grandes têtes de chapitre avec une numérotation spécifique pour chaque type de signaux ou fonctions (voir tableau).
Le ST2110-10 gère l’inter-synchronisation des signaux
Le chapitre 10 du standard ST2110 est consacré au respect des références temporelles entre les divers éléments entrant dans la composition du signal complet. Dans un signal vidéo SDI traditionnel, les données audio et auxiliaires (ancillaire data) sont imbriquées intimement avec celles de la vidéo, ce qui préserve leur synchronisme.
Dans une architecture ST2110, chaque type de données est géré de manière indépendante dans des flux séparés. Il est donc indispensable de prévoir un mécanisme permettant de les remettre en parfait synchronisme. Pour cela, des marqueurs temporels sont insérés dans chaque paquet de données. Ceux-ci sont dérivés du signal de référence de type PTP (Précision Time Protocol) et spécifié dans la norme ST2059.
Le standard ST2110-10 décrit comment sont calculés ces marqueurs pour chaque catégorie de données. Chaque équipement source reçoit la référence temporelle depuis le signal PTP en conformité avec la ST2059 et insère les marqueurs RTP. Les récepteurs vidéo décodent ces marqueurs et réalignent les flux pour qu’ils soient en parfait synchronisme. Un utilisateur peut donc mélanger et associer des sources différentes sans risque de perte de synchronisme.
Ces mécanismes fonctionnent en réalité avec le SDP (Session Description Protocole). Ce protocole, décrit par la RFC4566, définit un jeu de métadonnées permettant à un émetteur de spécifier le ou les flux qu’il envoie. Ils indiquent au récepteur comment il doit interpréter les éléments du flux qu’il reçoit. Ces informations sont indispensables au récepteur pour son bon fonctionnement. Ces informations SDP ne font pas partie du ST2110, mais sont distribuées aux récepteurs par le système de supervision.
ST2110-20, pour la vidéo non compressée
Le chapitre ST2110-20 définit les paramètres des signaux vidéo non compressés. Une première évolution importante précise que seules les zones actives de l’image sont prises en compte dans l’élaboration du flux vidéo. Toutes les données de blanking ou liées aux zones de synchronisation sont éliminées. Cela conduit à une réduction du débit des flux vidéo, par rapport aux débits « standards » des signaux SDI, comprise entre 16 et 40 % selon les résolutions (voir tableau). Certains multiples ou combinaisons de débits vidéo devraient correspondre plus facilement à ceux des ports réseaux calibrés sur la progression 10/25/40/100 Gb/s qui n’avait aucune corrélation avec l’étalement des signaux vidéo.
Les spécifications du ST2110-20 sont définies pour des images allant jusqu’à du 32K x 32K, (ses rédacteurs ont prévu large !). Elles prennent en compte les espaces colorimétriques codés en Y’Cb’Cb’, RGB, XYZ et I’Ct’Cp’. Elles supportent les échantillonnages 4:2:2 sur 10 bits, 4:2:2 sur 12 bits et 4:4:4 sur 16 bits. Enfin, concernant le HDR, elles acceptent les courbes PQ et HLG avec une possibilité d’ouverture vers d’autres courbes ou systèmes HDR. Les fréquences images sont totalement libres et donc non spécifiées.
La partie 22 de la norme ST2110 définit les conditions de mise en œuvre de la compression vidéo. Elle ne fixe pas de codec privilégié avec un choix qui reste ouvert entre Jpeg 2000, Tico, AVCI, Jpeg-XS, ou autre. Ce chapitre précise comment chaque codec doit être utilisé. Et en particulier définit les relations temporelles entre le flux élémentaire du signal vidéo et l’ensemble du système 2110.
ST2110-30 prend en charge l’audio
Le chapitre ST2110-30 est consacré à l’audio. Il est basé sur les spécifications de l’AES67. Il laisse un large choix dans la définition des paramètres des signaux audio, mais un certain nombre d’éléments sont requis au minimum. Un fonctionnement avec un échantillonnage à 48 kHz est obligatoire pour tous les équipements. De même qu’un flux audio comprendra de un à huit canaux, avec une profondeur de quantification de 16 ou 24 bits. Si un équipement audio fonctionne avec un jeu de paramètres différent, il est indispensable d’examiner attentivement les spécifications de ce chapitre.
Il faudra éviter d’envoyer chaque canal audio séparément pour limiter le nombre de flux et ne pas compliquer inutilement la configuration du système. Il est préférable d’envoyer des flux plus importants composés de deux, quatre ou huit canaux pour alléger le travail des switchs. Des méga-flux audio pourront monter jusqu’à 64 canaux. Le fonctionnement spécifique de certains équipements exigera des compromis spécifiques, mais il est préférable de faire ces choix sur la base des flux plutôt que sur celui des canaux.
Le standard ST2110-30 ne traite que les signaux de type PCM. Le chapitre ST2110-31 définit les conditions de transport d’un signal audio AES3 sur IP. Il peut traiter des signaux non PCM et gérer les signaux AES3 avec userbits ainsi que les valeurs C et V. Il ne traite que des signaux stéréo comme dans l’AES3, mais peut gérer plusieurs signaux AES3 dans un même flux.
Le ST2110-40 pour les données auxiliaires
Les données auxiliaires sont transportées en parallèle avec les données vidéo (video essence) et audio (audio essence). Certaines sont intimement liées aux données vidéo, par exemple le time-code ; d’autres servent à transmettre des contenus indépendants, comme les sous-titrages, et enfin une dernière catégorie est transmise dans la liaison vidéo pour profiter du support de transport, ainsi que des données de services pour superviser des équipements ou rendre compte de leur fonctionnement. Jusqu’à présent ces données étaient insérées dans le signal ou décodées en traversant des circuits dédiés. Dorénavant on cherche à les gérer comme une composante interne du flux vidéo transporté.
L’IETF a récemment publié la RFC 8331 qui précise comment ces données sont intégrées dans un flux IP. Le standard 2110-40 détaille comment est adaptée la RFC 8331 dans l’environnement 2110. Les données auxiliaires sont agrégées dans un flux spécifique avec une identification propre à chacune d’elles, de manière à pouvoir les insérer dans un flux 2110 ou les extraire à chaque étape du transport ou du traitement IP 2110, un peu à la manière de l’audio où chaque stream ou chaque canal audio peut être séparé ou associé avec la vidéo.
Les spécifications NMOS viennent en complément
Le champ d’application du ST2110 est limité au transport du signal vidéo et de ses éléments associés sur une infrastructure IP. Il n’intervient pas dans le domaine de l’aiguillage ou de la supervision des signaux. Contrairement aux infrastructures SDI où la grille centrale de commutation joue le rôle de plaque tournante pour l’aiguillage des signaux, dans le monde vidéo sur IP, c’est l’équipement de réception ou destinataire du signal qui va aller sélectionner le flux vidéo envoyé par l’une des sources. Pour cela il doit connaître le nom et les caractéristiques de la source qui lui seront envoyés par le système de supervision.
Chaque constructeur met en avant son outil de contrôle et de supervision, mais pour garantir une bonne interopérabilité entre les équipements de constructeurs différents, il est indispensable de définir un système de description standardisé et ce à quoi s’est attaché l’AMWA avec les spécifications NMOS.
Plusieurs chapitres ont déjà été publiés, dont l’IS-04 et l’IS-05 et bientôt l’IS-06. Nous reviendrons plus en détail sur ces mécanismes dans un prochain article.
Pour les définir brièvement, l’IS-04 fournit les méthodes de découverte des équipements et de ses caractéristiques dans un environnement de production IP et la façon de les regrouper dans un registre central, l’IS-05 aide à établir la commutation vers la source des flux, tandis que l’IS-06 va gérer les besoins de bande passante et de qualité de service en évitant les situations de blocage du réseau.
Comme indiqué dans notre diagramme, un important travail de standardisation est encore nécessaire pour mettre en place des systèmes de production tout IP et totalement interopérables entre les constructeurs.
La ST2110 remise en cause ?
Cette longue route vers une architecture de production totalement sur IP suscite quelques interrogations, tant du côté des industriels que du côté des exploitants. Cette année, au NAB, le thème de la production sur IP était moins mis en avant, plusieurs acteurs constatant une demande toujours forte en infrastructure traditionnelle SDI. D’autres voix se font entendre comme celle de cet expert anonyme qui a mis en ligne un site « STOP THE 2110 ».
Sans reprendre dans le détail son argumentaire, il constate que l’organisation des données et leur structure en paquets dans le 2110 n’est pas propice à un traitement logiciel direct sur des machines virtuelles dans le cloud, sans utiliser des interfaces avec drivers spécifiques. Pour une architecture de taille moyenne, il effectue une comparaison de coûts et conclut que le gain économique est loin d’être évident. Ce que d’ailleurs confirment certains constructeurs qui placent le point mort de la réduction de coût pour des « grilles » tout IP avec des capacités supérieures à 500 x 500.
Interrogé lors d’une présentation de ses produits à propos du passage vers le tout IP, un constructeur de systèmes de régies vidéo intégrées avec outils d’habillage et de ralentis fonctionnant sur du hardware de type IT, a précisé que les interfaces réseau à 25 ou 40 Gb/s, les seules capables de raccorder de multiples sources et départs via une interface unique, font s’écrouler les processeurs internes de la machine. À son avis, la seule solution, pour une version tout IP de son mélangeur, est de prévoir des interfaces réseau avec des circuits de traitement interne pour soulager les processeurs.
Mais dans ce cas on revient à des cartes interfaces spécifiques pour encaisser les débits engendrés et on quitte la logique du choix de matériels COTS (Commercial Off-The-Shelf) qui est l’une des clés de la justification du basculement vers le tout IP.
Matrox l’a bien compris en dévoilant lors du dernier NAB sa carte X.mio5 équipée de quatre ports SFP pour recevoir ou envoyer des flux vidéo ST2110 à concurrence de 48 Gb/s.
Malgré leurs débits de plus en plus élevés (10, puis 25, 40 et maintenant 100 Gb/s) les ports réseau des interfaces constituent donc pour l’instant l’un des goulots d’étranglement des architectures de production en tout IP. Mais cela est une conséquence de la montée en résolution des images, HD entrelacé puis progressif et enfin UHD.
Malgré la réduction de débit de 15 à 30 % apportée par l’organisation des données de la ST2110-20, la compression semble incontournable pour mettre en place des architectures tout IP cohérentes avec le développement technologique actuel. L’usage de la compression en production reste encore tabou pour de multiples acteurs. Pourtant, comme le remarque l’auteur du site STOP 2110, son usage est largement répandu depuis des années et dans de nombreux secteurs de production. Pour lui, une solution consisterait à revenir au ST2022-2 avec des débits plus élevés et des codecs qui ont déjà fait leurs preuves comme l’AVC Intra ou l’AVC Ultra.
Le choix effectué par Newtek, qui réduit un flux vidéo HD à environ 100 Mb/s, lui semble aussi une alternative intéressante à examiner malgré l’absence de QoS et l’opacité du codec conçu par les équipes de Newtek.
Bertrand Ruelle, directeur technique de Télésambre, télévision régionale publique diffusant ses programmes autour de la ville de Charleroi (Belgique) a mis en place un plateau de production entièrement en NDI. Il confirme que la compression via le codec du NDI fournit des images HD avec un niveau de qualité totalement satisfaisant.
À travers ces quelques exemples et ces prises de position à propos de la vidéo live sur IP, on peut légitimement se demander si, à travers le développement du standard ST2110 et de ses compléments NMOS, le monde de l’audiovisuel professionnel n’est pas en train de revivre toutes les péripéties de l’avènement des standards de production audio sur IP avec l’émergence de la norme AVB rédigée sous les auspices de l’IEEE et des plus grands industriels, et qui a été balayée par le Dante.
Au cours des années 2000, l’IEEE a entrepris la mise au point d’un protocole de transport audio et vidéo sur réseau IP, dénommé AVB (Audio Video Bridging) en visant à la fois le marché domestique, celui de l’automobile, mais aussi le professionnel, et ce avec le soutien des principaux acteurs de l’industrie. Cela a abouti à un système extrêmement complexe exigeant des switchs réseau compatibles AVB.
Dans le même temps, Audinate, une start-up australienne, mettait au point un protocole propriétaire de transport audio sur IP, Dante. Dix ans plus tard, Dante est adopté par plus de 250 constructeurs, alors que pour AVB seule une grosse dizaine d’acteurs de l’audio professionnel ont repris ce standard. Pour la vidéo sur IP, n’était-on pas sur un scénario similaire ?
D’ailleurs John Mailhot, CTO pour les réseaux IP chez Imagine Communications et responsable du groupe de rédaction de la ST2110, lors d’une conférence de Bits By The Bay 2018, confirme que le ST2110 est parfaitement adapté pour les gros cars-régies conçus pour l’UHD, et pour les centres de production avec de nombreux studios nécessitant de larges systèmes de commutation, tous ces moyens devant être organisés autour d’une architecture réseau avec un domaine unique PTP et un système unifié de management.
Par contre, il estime que le choix de la ST2110 est moins pertinent dans le cas de services gérés dans le cloud ou basés sur les liaisons longue distance avec des équipements dispersés dans plusieurs domaines réseau.
L’avenir nous dira si la production vidéo live sur IP sera organisée avec deux modes de fonctionnement : l’un géré via des systèmes régis par le ST2110 et un second avec un protocole plus simple à mettre en œuvre avec une vidéo plus compressée, comme le NDI, voire un nouvel outsider inconnu à ce jour.
Article paru pour la première fois dans Mediakwest #28, p. 60/62. Abonnez-vous à Mediakwest (5 numéros/an + 1 Hors-Série « Guide du tournage ») pour accéder, dès leur sortie, à nos articles dans leur intégralité.
