Le transport de la vidéo dans l’univers Broadcast a eu pendant des décennies comme protagoniste privilégié le standard SDI, un système de transmission du signal vidéo numérique synchrone et unidirectionnel.
On peut se poser la question à savoir si ce mode de transmission est avantageux ou pas et pour quelle raison le SDI a pu s’imposer de telle manière.
A l’époque où les réseaux étaient encore à 10Mbps, le SDI pouvait transporter de la vidéo SD non compressée à 270Mbps. La question ne se posait donc pas, de plus il était plus facile de gérer une technologie unidirectionnelle et synchrone, plutôt qu’une technologie bidirectionnelle qui devait, entre autre, gérer le problème des collisions et la perte de paquets.
Puis, face à une exigence importante de qualité, on ne pouvait plus tolérer un manque de fiabilité, non négligeable, au niveau de la couche de transport (on considère d’ailleurs que la pile TCP/IP n’est pas fiable car on est jamais à l’abri d’une corruption des données).
Les choses ont progressivement changé, au moins concernant les débits en jeu, car les réseaux sont montés à 100Mbps (pas encore suffisant pour la SD), puis à 1Gbps (mais le SDI était passé à 1.5Gbps pour le transport de la HD).
Enfin le passage des réseaux à 10Gbps et puis à 100Gbps auront ouvert le chemin vers une réflexion sérieuse sur la faisabilité ou pas du transport IP de la vidéo non compressée, car il fallait déjà résoudre les autres soucis de l’IP :
• Fonctionnement asynchrone
• Problématique de fiabilité au niveau du transport
• Problématique de perte de paquets IP
• Problématique de routage non négligeables et dé-séquencement des paquets
• Latences non maîtrisées et fortement dépendantes de l’équipement utilisé.
Mais l’IP dispose d’un atout majeur : le transport n’est pas unidirectionnel.
En IP, un échange de données est toujours lié à un dialogue. La notion de client et de serveur est essentielle. Un client pose une question, le serveur répond. La réponse du serveur, selon le protocole, peut être une page web, des datas issus d’une base de données, des emails, un fichier et… un flux vidéo !!!
Mais quelle est la différence entre le transport d’un signal numérique et le transport en IP ?
Pourquoi la caméra va vers une des entrées du mélangeur ? Le signal numérique est dirigé par qui ??
On peut imaginer une gestion SDI comme la gestion de l’eau d’un fleuve vers lequel plusieurs sources se dirigent et à partir duquel on fait partir des canaux : il s’agit de diriger l’eau quelque part vers un destinataire.
L’eau peut être seulement détournée et le destinataire va recevoir un flux que quelqu’un lui aura directement envoyé même s’il n’a rien demandé !
Mais on peut voir la gestion des flux en IP différemment : on a plusieurs sources d’eau, et le destinataire pose lui-même la question : « Je voudrais 10 litres d’eau provenant de cette source ! »
A travers cette allégorie, ce fonctionnement en client/serveur a d’énormes avantages. Si le destinataire veut changer de source, selon la technologie utilisée, un processus différent doit être mis en place :
En SDI: Il va falloir réorganiser le câblage, ou bien modifier les attribution entrées/sorties au niveau de la grille. Cela fonctionne bien, mais disons que ce n’est pas pratique et il faut faire cette action avec une certaine conscience du système global. Dans la métaphore précédente il faudrait dévier un canal pour l’envoyer vers la destination voulue. Cela veut dire qu’on est obligé d’agir sur l’infrastructure physique.
En IP: Le client doit simplement changer l’adresse IP Multicast de la source.
L’effet de cela est immédiat, et on ne change rien à l’infrastructure physique.
Cette nouvelle approche semble donc préférable, dynamique, flexible, d’autant plus que les autoroutes IP sont globales et planétaires !!!
Mais les choses ne sont pas si simples : qui doit dire au client de changer l’adresse IP de la source ? Qui stocke et met à jour les informations sur les sources existantes ? Ces deux questions sont essentielles car tout le problème est là, aujourd’hui.
Si le client a la capacité de récupérer un flux (les normes SMPTE-2022 et SMPTE ST-2110 nous donnent des directives précises que le constructeur pourra ou pas appliquer), il est vrai que dans un système IP, il faudra remplacer le câblage SDI et la gestion des entrées/sorties de la grille par une couche applicative. Celle-ci doit gérer l’organisation des flux, contrôler chaque client, découvrir et organiser les sources présentes dans le réseau. Cette couche applicative ne traite pas directement les datas vidéos, mais elle permet de gérer les flux, avec l’objectif de réaliser le workflow voulu.
Le contrôle des flux peut d’ailleurs se faire avec deux logiques différentes :
La logique SDN (Software Defined Networks) : on contrôle les flux en pilotant les équipements du réseau. Un système de messagerie permet par exemple de changer les tables de routages afin de rediriger les flux.
Le contrôle applicatif : on pilote les applications client et serveur afin de modifier et gérer dynamiquement les abonnements Multicast.
Cette deuxième solution parait très intéressante, car elle est transparente au niveau du réseaux. Le système qui contrôle les flux s’appelle orchestrateur.
Un constructeur propose généralement son orchestrateur afin qu’il communique au moins avec les couches IP de ses propre équipements. Mais cela peut devenir un problème si on reste bloqué dans une solution fermée et donc pas ouverte à l’interopérabilité.
Chaque orchestrateur a son « langage », qui est parfaitement bien intégré aux couches applicatives du même constructeur. Mais si on doit piloter un équipement qui ne parle pas le même langage, il faut aujourd’hui développer une sorte de « traducteur » qui arrive à comprendre les deux langages et qui traduit d’un côté et de l’autre. On appelle ce composant un « connecteur ».
Pourquoi alors ne pas inventer un langage d’orchestration universel ? Eh bien, c’est le NMOS qui parait vouloir s’imposer.
NMOS est un ensemble de spécifications techniques, produites par l’Advanced Media Workflow Association, qui a comme objectif de normaliser les échanges en réseau, le contrôle et la découverte des sources.
On est donc dans la problématique la plus sensible, car mis à part l’interopérabilité des flux, il faut comprendre comment plusieurs solutions industrielles peuvent dialoguer entre elles afin de rendre les workflow dynamiques et flexibles, plutôt que d’attribuer des adresses multicast statiquement et se retrouver dans des solutions qui risquent de perdre les avantages du SDI (interopérabilité assurée et facilité de conception des workflow média).
L’architecture vidéo IP ouvre de nouvelles voies, elle doit permettre de nous réinventer grâce à l’interopérabilité entre environnements et technologies. Elle favorise des infrastructures agiles, efficientes, supervisées et virtualisées, avec des coûts maîtrisés et dont la flexibilité garantit une pérennité.
Mais déployer, administrer, maintenir et faire évoluer une infrastructure réseau/vidéo IP nécessite non seulement de s’approprier les solutions et nouveaux équipements déployés mais également de s’acculturer à l’environnement des réseaux de flux vidéo, à la terminologie, aux nouvelles normes IP sans oublier les problématiques de sécurité et d’orchestration.
Dans le cadre de ses formations, IIFA-Media 180 a mis en œuvre des cursus courts et des parcours certifiants (éligibles CPF) couvrant non seulement les connaissances fondamentales en réseaux et normalisation vidéo IP, mais également des sujets spécifiques en ligne directe avec le sujet de cet article telles que « Interopérabilité et orchestration » ou « Synchronisation et PTP ».
© IIFA-Media 180 2019 – Mention de la source obligatoire