IBC 2015 : Live IP

IPL’IP dans la régie : choc des cultures. L’IBC 2015 est là pour nous confirmer qu’il est désormais possible de réaliser avec une base informatique standard des fonctionnalités qui jusqu’à un passé très récent étaient réservées à des hardware dédiés. Cela s’accompagne de bouleversements dans la conception et la perception de nos outils de fabrication, l’informatique arrivant avec ses caractéristiques propres. Deux mondes alors coexistent, l’IT et le broadcast. Nos exigences fondamentales d’un monde à l’autre restent les mêmes, il revient donc à l’IT de les intégrer. Le broadcast lui, qui a su s’adapter jusque là aux évolutions des besoins est il prêt à répondre aux exigences technologiques de l’époque ? Pas sûr.

L’heure est au partage

Jusque là, dans l’approche broadcast, une tache à accomplir trouve une solution via un système dédié. Ce qui veut dire : mise en place d’un équipement hardware spécifique répondant uniquement au besoin.

Avantage : Certitude que la tache est effectuée au moment où elle est demandée.

Inconvénient : Un équipement est mobilisé pour effectuer cette tache, et reste inactif s’il n’y a pas de besoin.

Cela signifie qu’une régie est composée d’autant de « briques » que de besoins, elles-mêmes constituées de matériels dédiés qui ne répondent qu’à un seul besoin, et qui ne sont opérationnels qu’à des moments précis.

L’IT propose une autre approche

Il ne s’agit plus de construire des équipements « sur mesure » dédiés aux besoins du broadcast mais d’utiliser du matériel informatique courant. Une tache n’est plus confiée à un équipement unique, un outil informatique peut prendre en charge plusieurs taches qui devront se partager la bande passante.

Avantages : Les coûts extrêmement optimisés s’agissant de matériel standard et les multiples possibilités offertes par rapport à du matériel dédié. Les taches étant mutualisées, la rentabilité des équipements est meilleure.

Inconvénients : On perd le déterminisme temporel. Le délai d’exécution dépendra du nombre de processus engagés et de la bande passante disponible. Malgré tout, certaines fonctions peuvent s’exécuter avec succès dans un délai indéterminé (typiquement calculs), d’autres non (écoute, visionnage).

Or, quand il s’agit de fabriquer et diffuser des signaux audio/vidéo en direct, il n’est pas question de mettre en jeu des outils qui ne se comportent pas de façon prédictive. Dans le même temps, il n’est pas envisageable de se passer des fonctionnalités apportées par le logiciel. Les constructeurs travaillent à garantir le déterminisme, en général avec succès sur des outils isolés, mais l’heure est au partage des ressources, au Cloud, à la virtualisation ! L’optimisation des ressources s’oppose à leur disponibilité et donc à la maitrise du temps réel, c’est le sujet de nombre de travaux et de recherches des industriels. Reste à voir si, in fine, l’équation économique est favorable.

Lorsque le nombre de fonctionnalités augmente, que la conception se complexifie, le comportement d’un système tend vers l’indéterminisme car toutes les combinaisons possibles n’ont pas pu être anticipées par le concepteur. Elles ne sont pas toutes testées et peuvent donc ne pas correspondre au comportement attendu. De plus, un système est d’autant plus déterministe (débuggé) qu’il est largement testé … Les marchés de niche dont le broadcast n’auraient donc d’autre solution que d’apprendre à vivre avec cette incertitude ? Il n’y a aucune raison pour que ce qui prévaut par ailleurs ne soit pas vrai également en broadcast. Il serait aussi erroné de penser un environnement technologique comme immuable que d’imaginer la perte brutale de caractéristiques essentielles au métier. L’évolution se fera mutatis mutandis, mais elle est inéluctable.


EBU IBCDans cette mouvance du tout IP, le point marquant du salon est sans doute l’initiative de la VRT qui, avec l’EBU et la compagnie belge de consultants DWESAM, a mené un projet dont l’objectif était de créer l’environnement d’un studio live en utilisant du matériel IP de type IT (matériel et logiciel).

Ce projet devait mettre en évidence le glissement du monde du broadcast vers le monde digital, présenter les nouveaux workflows, démontrer la souplesse et l’évolutivité des systèmes IP et faire la preuve que désormais, nous pouvons faire plus… avec moins. Ce projet était basé sur des standards ouverts afin de montrer les niveaux d’interopérabilité que l’on peut atteindre aujourd’hui. La VRT s’est appuyée notamment sur des constructeurs comme Axon, EVS, Genelec, Grass Valley, Lawo, LSB, Nevion, Tektronix et Trilogy.

Chacun sait que si le marché n’a pas confiance, ces technologies ne seront pas facilement adoptées, c’est donc pour cela que l’ensemble des constructeurs affiche l’objectif de travailler ensemble afin d’avoir des systèmes qui fonctionnent parfaitement ensemble.

La démonstration de la VRT est nativement IP : il n’y a plus d’encapsulation, ni de conversion de protocole et elle se déploie sur 3 sites interconnectés par des fibres avec les différents équipements :

  • Le studio dans lequel on va retrouver des caméras et des boitiers de conversion IP/SDI
  • Le centre de données (salle informatique) dans lequel on retrouve toute la puissance de calcul des infrastructures, la référence de temps ou encore des serveurs de diffusion.
  • Le centre de contrôle dans lequel on va retrouver ce qui concerne le monitoring et contrôle des équipements audio/vidéo/réseau.

La VRT a aussi imposé les standards SMPTE 2022-6 (Transport de Video Haut débit sur IP), AES67/Ravena (Audio), PTP (Precision Time Protocol) et OpenFlow (Contrôle du réseau) aux fabricants. Cela a forcément limité le nombre de participants possibles à la démonstration, mais ces standards s’imposent pour l’avenir et l’ensemble des constructeurs devraient bientôt être compatibles avec ces standards.

OpenFlow est associé de manière inévitable aux réseaux gérés et contrôlés qui  nécessitent un déterminisme temporel. En effet ce protocole est la base d’un Software-Defined Networking (SDN) standardisé.

Un SDN est un modèle d’architecture réseau qui ajoute un niveau d’abstraction aux fonctionnalités des équipements réseau afin de pouvoir les gérer de façon globale. La partie décisionnelle des équipements est séparée de leur partie opérationnelle et déportée vers un unique point de contrôle qui dirige l’ensemble de façon cohérente.

Ce découplage permet de déployer le plan de contrôle sur des plateformes dont les capacités sont plus grandes que celles des commutateurs réseau classiques. Le Software-Defined Networking est un concept-clé pour faire le pont entre la gestion dynamique des ressources réseaux d’une part et la demande en connectivité et en qualité de service (QoS) des applications de type Audio Video Live d’autre part.

LiveIp VRT IBC

La démonstration de la VRT s’appuie sur deux réseaux distincts : un réseau de gestion et de contrôle et un réseau temps réel doublé. Le réseau de gestion et de contrôle est un réseau IP traditionnel. Le réseau temps réel est géré par un logiciel : le SDN VideoIPath de Nevion qui gère l’ensemble des switches Nevion via le protocole Openflow.

VRT LiveIP IBC

Un clavier de commutation de grille LSB communique la couche de gestion de studio VSM (Virtual Studio Manager) qui s’intègre avec la couche du SDN Nevion VideoIPath.

Le résultat est convaincant, les changements d’images sont propres lors de chaque envoi de commande par le LSB et la démonstration rend crédible ce type de solutions dans un avenir relativement proche.

La VRT ne s’arrête pas à cette première phase et table sur une roadmap jusqu’à Janvier 2016 dans laquelle l’objectif est de multiplier le nombre de caméras, de faire du streaming live et de produire un JT en live.

Chez Cisco et EVS on retrouve une autre démonstration concernant la production Live sur IP. La démonstration met en œuvre la nouvelle gateway XIP d’EVS qui offre la possibilité d’envoyer en direct via IP les flux vidéo. La démonstration s’appuie sur des commutateurs Cisco standards (Nexus, switch haut de gamme) gérés par un logiciel de gestion SDN Cisco (Openflow encore).

CISCO liveIP IBC

Ce qui rend cette démonstration « futée » c’est la génération de flux réseaux non prioritaires : des transferts de fichiers FTP qui ont la fâcheuse habitude de s’accaparer les bandes passantes.

On peut monitorer ces flux et observer le comportement du réseau en fonction des réservations de bandes passantes indirectement faites par l’utilisateur en fonction du nombre de flux vidéo transitant d’un site vers l’autre.

Ça fonctionne… Chez EVS, on croit, comme tout le monde, que les workflows IP interopérables sont non seulement une réalité mais qu’ils ne feront que croitre avec le temps…

Sony LiveIP IBCChez Sony, on joue aussi la carte du tout IP, de l’interopérabilité et de la standardisation, et on ne fait pas les choses à moitié : 3 POC (Proof of Concept) sont visibles sur leur stand, tous avec des constructeurs différents.

Le premier met en œuvre un réseau SDN mêlant des switches standards Cisco et Juniper gérés par la couche VSM de LSB. Une matrice de 100×100 flux HD est simulée. Le second POC, en collaboration avec Imagine Communications (ex Harris Communication), démontre l’intégration du SDN Sony (LSM pour Live System Manager) avec les panneaux de contrôle Magellan d’Imagine. Le SDN gère un réseau sur la base d’un simple switch Cisco. Les flux qui transitent sur ce réseau sont 4K et HD et font intervenir des convertisseurs IP/SDI, les flux sont affichés sur des moniteurs SDI 4K. Le troisième POC est la copie conforme du second mais s’appuie sur des systèmes de contrôle et des switches Evertz.

L’objectif de Sony est donc de rassurer, quitte à inviter des concurrents directs sur son stand : leurs technologies, comme ceux d’une grande majorité des constructeurs s’appuient sur des infrastructures courantes, supportant l’ensemble des standards du marché. L’interopérabilité est complète, même avec les systèmes plus propriétaires comme Evertz, et cela fonctionne. De quoi être rassuré !

Ce contenu a été publié dans IP. Vous pouvez le mettre en favoris avec ce permalien.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *