Pour la production live, la SMPTE a démarré il y a plusieurs années un important travail de normalisation, concrétisé par la publication des standards SMPTE ST 2110. Autour du même sujet, est apparu le sigle NMOS avec ses spécifications IS. Ce travail normatif de tous les éléments de la vidéo IP dans un environnement broadcast est encore loin d’être achevé.
Le transport d’un signal vidéo de qualité broadcast sur un réseau IP dans un environnement de production live combine un nombre élevé de paramètres, des mécanismes complexes et des configurations largement plus nombreuses que pour une simple architecture SDI.
La production des signaux live exige de s’appuyer sur quelques principes intangibles comme l’intersynchronisation des sources, l’absence de compression (quoique sur ce point les choses évoluent avec le Jpeg XS), une commutation propre lors du passage d’une source à l’autre dans une structure en paquets totalement décorrélée du balayage vidéo et la préservation d’une synchronisation entre l’image et le son.
Par ailleurs le passage au tout IP ne doit pas bouleverser les habitudes de travail des équipes techniques et il faut leur garder les interfaces habituelles de commande.
À ces impératifs, s’ajoutent aussi le souhait des chaînes et des prestataires de ne pas être enfermés dans des choix technologiques et des protocoles propriétaires propres à chaque constructeur. Dans les diverses instances qui réunissent tous les acteurs concernés : organismes techniques qui éditent des spécifications comme la SMPTE ou l’EBU, mais aussi des groupes d’utilisateurs comme le VSF, l’AIMS ou l’AMWA, deux exigences ont été exprimées très vite : définir des protocoles et des architectures ouvertes (ou open), disponibles de manière gratuite pour garantir l’interopérabilité et faciliter les évolutions dans le futur et s’appuyer au maximum sur les protocoles et standards d’Internet.
Dans leurs réflexions, les initiateurs de cette révolution pensent à des architectures flexibles et réparties dans lesquelles les équipements sont organisés entre divers pôles techniques reliés par des faisceaux de fibres optiques et auxquels les équipes de production accèdent à distance, dans des configurations évolutives et redimensionnables en permanence. Cette notion d’interopérabilité est donc essentielle.
Une première étape avec le standard SMPTE ST 2110
Vu l’ampleur de la tâche, plusieurs organismes se sont attelés à ce titanesque travail de standardisation en le répartissant par grandes fonctions.
La SMPTE s’est centrée sur deux grands domaines : la référence horaire et l’intersynchronisation d’un côté, le transport des contenus de l’autre. Elle avait déjà mené un premier travail qui avait conduit au standard SMPTE ST 2022 centré sur le transport des contenus dans une perspective de contribution ou de distribution avec une organisation des signaux dans un flux unique. Cela reste peu adapté à un travail de production où les diverses « essences » vidéo et audio doivent être traitées de manière différenciée.
La SMPTE 2110 part sur un principe différent en les séparant clairement. La vidéo, l’audio et les données auxiliaires font l’objet chacun d’un chapitre distinct.
Tous ces éléments sont maintenant stabilisés et ont été repris par de nombreux constructeurs. Leur interopérabilité a été validée lors de multiples programmes de tests. Deux évolutions récentes sont à noter : la compression vidéo avec l’adoption de la norme Jpeg XS (avec sa désignation officielle ISO/IEC 21122) et son utilisation dans le cadre du chapitre ST 2110-31.
Le Jpeg XS est un codec de compression basé sur les ondelettes, comme le Jpeg 2000 avec un taux de compression similaire mais une très faible latence, inférieure à la milliseconde. Son taux de compression, entre 4 et 10, réduit les débits de l’UHD à ceux du 1080p, soit des valeurs plus adaptées aux ports à 10 Gb/s, moins onéreux que les modèles à 25, 40 ou 100 Gb/s. Le Jpeg XS est issu des travaux qu’a menés Intopix sur le Jpeg 2000 et sur son codec propriétaire Tico.
L’autre évolution concerne l’implémentation du ST 2110 dans les chipsets d’Audinate pour le transport du Dante. Dans un premier temps, la ST 2110 traitait les signaux audio sur IP en conformité avec l’AES67 avec un ensemble de paramètres communs aux divers protocoles propriétaires d’audio sur IP pour remplir le rôle de passerelle entre eux, mais avec des restrictions sur les codages et les formats.
Suite aux évolutions du protocole PTP de référence horaire qui est passé en v.2, Audinate a implanté le ST2110 dans son chipset en parallèle à l’AES67, de manière à offrir une interopérabilité complète entre Dante et le ST 2110.
Mais la SMPTE ST 2110 ne fait pas tout
Plusieurs équipements d’envergure comme des cars régies ou des centres de production ont été déployés sur la base des standards SMPTE ST 2110. Mais dans plusieurs webinaires diffusés cet été par l’AIMS, leurs responsables techniques ont fait part de leurs difficultés pour la configuration et le pilotage des équipements. L’un d’eux relate que ses équipes ont dû configurer 500 000 adresses IP de manière manuelle avec juste l’aide de tableaux Excel. Ils constatent que le « data plane » et l’interconnexion des signaux fonctionnent correctement avec le ST 2110, mais que le gros challenge qui reste à relever concerne le « control plane ».
Emanuele Di Mauro, responsable de projet à l’IIFA, exprime le même constat avec une métaphore routière : « On a construit les autoroutes, les camions (les datas) peuvent circuler, mais qui va indiquer au camion son point de départ, sa destination et à quelle heure il doit partir ? C’est là toute la question. »
Jusqu’à présent chaque concepteur d’orchestrateur (Grass Valley, Imagine Communications, Lawo entre autres) définissait les commandes pour piloter chaque équipement ou applicatif. Si elles n’étaient pas disponibles pour l’un d’eux, il fallait concevoir un connecteur « logiciel », petit programme développé sur mesure pour permettre le dialogue entre l’orchestrateur et l’équipement.
Vu l’étendue des catalogues, le nombre de combinaisons devient vite énorme. Il est donc indispensable de mettre en place des mécanismes automatisés pour éliminer cette étape chronophage encore au cœur de nombreux projets.
Le rôle des spécifications NMOS
Les spécifications NMOS (Networked media open specifications) ont été développées pour fournir une couche de gestion et de contrôle des équipements (aussi bien hardware que logiciels) en complément à la couche de transport définie par le standard SMPTE ST 2110. L’objectif est de fournir des outils pour faciliter l’interopérabilité entre les équipements provenant d’une large gamme de constructeurs et les outils d’orchestration.
La famille des spécifications NMOS est disponible gratuitement à la fois pour les fournisseurs d’équipements et les utilisateurs pour un déploiement de leurs infrastructures. Ces spécifications s’appuient en majorité sur les standards et les technologies d’Internet.
Le développement de NMOS est soutenu par le JT-NM (Joint task force of networked media) qui associe pour ces travaux quatre organismes : l’AMWA, l’EBU, le SMPTE et le VSF.
Plus de 70 membres de l’AMWA, fournisseurs et utilisateurs, participent à ces travaux dans divers groupes de travail. Le JT-NM travaille en étroite collaboration avec l’AIMS (Alliance for IP Media Solutions) dont l’objectif de favoriser et de promouvoir l’introduction des technologies IP dans l’industrie des médias.
Les spécifications NMOS sont publiées sous forme de recommandations dénommées IS (Interface specifications) avec un numéro et qui correspondent à un groupe de fonctionnalités. Elles servent de base à la programmation d’API par les constructeurs ou éditeurs de services de manière à garantir l’interopérabilité entre les équipements et divers logiciels. Cette liste n’est pas figée car d’autres sujets sont en cours d’examen et font l’objet de BCP (Best current practice), étape préalable à l’élaboration d’une spécification NMOS.
Faire le lien avec le réseau en dialoguant avec le SDN
Maintenant les principaux orchestrateurs du marché ont intégré les protocoles NMOS. Des difficultés subsistent encore au niveau des endpoints (sources et destination des signaux). Ils doivent être rendus compatibles NMOS. Or beaucoup d’équipements ne le sont pas encore, même s’ils sont annoncés comme conformes.
D’autre part certains matériels n’offrent pas toute la souplesse permettant de les modifier à distance et sans délais. Il faut parfois changer manuellement leur configuration d’exploitation et, seulement après un reboot, il est alors possible de le piloter à distance.
NMOS ne remplit pas encore toutes les fonctions dont les équipes ont besoin pour une vraie configuration « plug and play ». À terme il faut pouvoir repérer un équipement avec un libellé unique. Il y a juste à modifier son affectation par exemple « Camera 1 /Studio 3 », et tous les mécanismes de configuration s’adaptent de manière automatique. Il faut aussi pouvoir gérer facilement un parc d’équipements non permanents exploités en pool ou loués à l’extérieur.
Emanuele Di Mauro constate que certains orchestrateurs restent dans une logique de contrôle applicatif et que cela pose des difficultés : « Si je demande à un récepteur d’aller récupérer un flux supplémentaire, je ne suis pas sûr que le réseau soit capable d’absorber ce débit. Même chose si j’ajoute un équipement ou bien si je bascule l’infrastructure d’un mode 50i à du 50p. Avec ce type d’orchestrateur je reste externe au réseau. D’autres orchestrateurs utilisent la technologie SDN (Software defined network) qui sert à contrôler et paramétrer automatiquement le réseau et à rediriger les flux. Il avertit l’administrateur en cas de dépassement des capacités du réseau en étant toujours “non blocking”. Il est important d’ajouter à l’orchestrateur une couche SDN pour qu’un dialogue s’établisse entre les deux entités. Dans le cas d’un simple contrôle applicatif, je devrais au moins vérifier que le réseau reste dans un état “non blocking” si on lance toutes les sources vers toutes les destinations et que le réseau n’est pas saturé. »
La gestion de l’état « blocking » et « non blocking » du réseau devient primordiale et doit être remontée de manière explicite à l’orchestrateur. Si ce n’est pas le cas, la saturation d’un lien peut conduire à des dégradations des images et des sons.
Si le SDN refuse l’action demandée, il doit en avertir l’orchestrateur pour qu’un message explicite soit renvoyé à l’exploitant vidéo pour lui annoncer que l’action demandée n’est pas possible. Le SDN, en particulier dans le cas d’une topologie de type « spine leaf » redondée, pourra rediriger les flux supplémentaires vers un lien moins chargé et optimiser la charge globale du réseau.
Ces mécanismes vont devenir incontournables dans des architectures de remote production dans laquelle les liens intersites sont plus limités en termes de bande passante. Si le SDN n’est pas embarqué dans l’orchestrateur, on peut recourir à celui fourni par le constructeur des actifs réseaux. Dans ce cas, l’interaction entre l’orchestrateur et le SDN peut se gérer avec la spécification IS-06 (network control) du NMOS.
Un dernier domaine dans lequel les travaux de normalisation et d’interopérabilité débutent seulement, concerne tous les aspects liés à la sécurité. Et dans un monde totalement interconnecté, nous savons qu’ils revêtent une importance capitale.
Ces quelques exemples d’interdépendance entre les équipements, les flux, les actifs réseaux montrent qu’un important travail d’élaboration de spécifications, standards ou autres recommandations est encore nécessaire avant de déployer des infrastructures basées sur le standard SMPTE ST 2110 et le NMOS dans un environnement fiable et totalement « plug and play ».
Article paru pour la première fois dans Mediakwest #38, p. 102-105. 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é.
[envira-gallery id= »117924″]
