EBU Network Technology Seminar 2019 : un point sur l’IP dans nos régies

L’édition 2019 du Network Technology Seminar a donné lieu à deux journées très riches d’échanges et de présentations autour de quelques thématiques « phares » :

par Claire Mérienne-Santoni et Edmond Debar

France Télévisions – innovations & développements

Infrastructures de production live IP

D’abord, un témoignage quasi unanime de l’ensemble des pionniers des infrastructures interopérables en tout IP. Premier constat : « one size does not fit all », il n’y a sans doute pas de format universel pour tous les usages, et il est nécessaire de trouver le meilleur compromis correspondant à chaque cas d’exploitation. Si le 2110 apparaît comme un remplaçant sérieux du SDI à l’intérieur des sites de production, ce n’est pas forcément le meilleur choix pour une liaison de contribution. Quant aux moyens de captation mobiles qui se doivent d’être opérationnels en quelques minutes quel que soit le site de connexion, force est de reconnaitre qu’aujourd’hui l’utilisation de formats propriétaires type Dante pour l’audio ou NDI pour la vidéo présentent des avantages indéniables et n’ont pas encore d’alternative interopérable « full-stack » sur étagère. Dans cette optique, il est d’ailleurs intéressant de noter que des interfaces NDI / 2110 semblent faire leur apparition…

Deuxième constat : la route de la migration du Broadcast vers l’IP n’est pas un long fleuve tranquille. Qu’il s’agisse de la difficulté à définir une architecture de distribution de la synchro PTP fiable, de trouver des outils d’orchestration et de contrôle des équipements, ou du manque de choix de solutions sur le marché, voire du manque d’implication de certains constructeurs pour résoudre les problèmes d’intégration, tous les projets récents décrivent une situation plus nuancée que ce que les sirènes du marketing continuent d’afficher.

CBC – La nouvelle maison de Radio Canada

Alain Lamarre de CBC a ainsi décrit en détail les difficultés rencontrées dans le déploiement de la synchronisation à base de PTP pour la Nouvelle Maison de Radio-Canada à Montréal. Plusieurs itérations ont été nécessaires pour trouver l’architecture la plus fiable et répondant aux contraintes du multi-sites. Il est ainsi marquant de voir que parmi les sociétés qui témoignent de déploiement à base de PTP, il n’y en n’a pas deux qui ont abouti au même schéma de distribution. De plus, certaines décrivent le fait qu’avec deux architectures identiques basées sur des switches de même référence, on n’obtient pas toujours deux comportements identiques. Les fabricants réseau ont-ils implémenté PTP à la légère (en redéveloppant chacun leur propre implémentation de la norme plutôt que d’intégrer des « stacks » existants ) ou manquent-ils encore d’expérience pour accompagner au mieux leurs clients dans ce domaine ?

TPC – Metechno

Un autre bâtiment entièrement basé sur IP est en cours d’intégration, en Europe cette fois, c’est celui de TPC, la société de production de la télévision publique Suisse. Là aussi, Sandro Furter décrit un design difficile de la distribution de synchro PTP ayant nécessité plusieurs itérations. Il pointe également les difficultés liées à l’absence de format de contrôle et monitoring standard, particulièrement pour les besoins de mapping des canaux audio (la télévision suisse diffusant 4 langues, cela est donc loin d’être anecdotique). NMOS IS08, dédié au mapping audio n’était pas disponible au moment de leur appel d’offre et n’est donc pas implémenté. Mais c’est également le cas de IS-07 (Rouges et Tally), IS-06 (contrôle du réseau), IS-09 (standardisation des API), IS-010 (Autorisation d’accès)… Au final, le système utilise une combinaison d’IS-04 et IS-05 pour la découverte, l’enregistrement des devices et le management de connexion, d’API propriétaires ou non de différentes origines, d’interfaces Web, et de SNMP, ce qui on l’imagine bien est loin d’être simple et optimisé pour la maintenance et l’exploitation…

Les deux images ci-dessous illustrent la proportion de problèmes rencontrés par type de flux rapportés aux débits de ces flux : ce ne sont pas les flux les plus gourmands en bande passante qui sont les plus problématiques :

Les flux audio consomment beaucoup moins de bande passante mais génèrent beaucoup plus de difficultés, notamment en raison de l’absence d’un protocole de mapping des canaux audio.

Dernier point mis en avant : l’omniprésence dans le domaine audio d’interfaces disposant d’une seule interface réseau, et donc leur inadéquation avec la nécessité d’une architecture réseau Main/Backup. Il faut donc penser des solutions de secours alternatives…

Deux nouveaux bâtiments tout IP pour la BBC

La BBC est en train de terminer la réception du nouveau bâtiment de Cardiff qui abritera trois chaînes de télévision et trois services radio pour le Pays de Galle. La mise on air est prévue pour fin 2019. L’infrastructure est basée sur le format SMPTE2110, mais seule la moitié des sources sont natives 2110, il y a donc encore une quantité importante de gateways dans les baies. L’architecture réseau est en Spine&Leaf, à base de Cisco et de son logiciel DCNM, avec deux réseaux séparés en redondance l’un de l’autre. Le marché Broadcast a été remporté par Gras Valley, qui fournit les mélangeurs, les mosaïques et les gateways SDI/IP, les caméras sont des Sony. Les horloges PTP sont fournies par Meinberg et les outils de mesure sont des Tektronix PRISM. Le contrôle Broadcast est fourni par Atos avec son système BNCS, à base de drivers spécifiques à chaque fabricant et de SNMP. BNCS pilote l’application GV Convergent qui elle même s’interface avec Cisco DCNM pour le contrôle du réseau. Le projet initial prévoyait d’utiliser NMOS (qui est d’ailleurs en partie implémenté) mais il aurait fallu quelques mois de plus pour permettre son intégration complète par les différents fabricants, ce qui n’était pas possible dans les délais impartis. La BBC a donc du se résoudre à un certain nombre de contournements pour obtenir un contrôle satisfaisant des équipements.

Le système utilise une grande part de hardware générique, y compris pour les applications Broadcast, ce qui a permis de réduire les coûts et de virtualiser la plupart des services (dont BNCS), mais qui en revanche pose la question de la durée d’amortissement, qui devient de fait plus courte, obligeant les Broadcasters à adapter leur modèle économique.

Les principaux avantages et principaux risques de la migration SDI vers IP selon la BBC.

Au chapitre des difficultés, la BBC pointe le manque d’outils de contrôle et de monitoring, associé au manque de maturité de nombreux produits de ce point de vue, mais aussi l’intégration de PTP, complexe et coûteuse en équipement réseau, ainsi que le coût très élevé des connecteurs optiques, loin d’être négligeable dans ce type d’infrastructure… On note également des difficultés d’interopérabilité entre AES67 et 2110-30 et plus globalement entre les fabricants issus du monde de la radio, qui intègrent des protocoles spécifiques au monde audio et pas forcément compatibles avec celui de la vidéo sur IP, et utilisent d’autres modèles de redondance que le 2022-7 utilisé dans le monde de la vidéo. Dans ce contexte , Mark Patrick souligne l’utilité des développements autour du projet LIST, porté par l’UER .

L’intégration des équipements Dante pose notamment quelques problématiques avec la nécessité d’un domaine PTP spécifique, au final dans certains cas il s’avère pertinent de repasser par du MADI pour interconnecter les deux mondes…

Le projet de renouvellement du bâtiment de Belfast quant à lui est en phase de démarrage et tire profit des expériences de celui de Cardiff. L’objectif est d’aller encore plus loin en terme de flexibilité des infrastructures et d’optimisation des ressources. La flexibilité est même intégrée au cœur du bâtiment avec la notion de pièces «multi-usages », un studio donné peut ainsi en fonction du besoin devenir une régie ou une salle de montage. Le principe, ne figer que le minimum : murs, portes et fenêtres, acoustique, alimentation électrique et réseau, climatisation, points de connexion éclairage et meubles, tout le reste doit pouvoir être adapté. Cela passe notamment par l’utilisation de décors virtuels via AR et VR.

Les principales questions à l’étude dans le cadre de cette transformation pensée sur le long terme : comment orchestrer les transferts de charge entre les nœuds de calculs pour rendre réelle au quotidien l’optimisation des ressources processeur ? Explorer la notion de Media Orienté Objet comme base essentielle vers les contenus personnalisés. Comment supporter la multiplicité des formats vidéo (y compris la version verticale) pour fournir des contenus multi-supports, comment éviter les SPoF (Single Point of Failure) dans les nouvelles architectures ? Comment assurer une interopérabilité – un conseil pour cela : « Be conservative on what you send, Be liberal on what you accept ». Comment gérer la redondance ? Le double streaming est complexe, il faut conserver des notions de séparations de zone dans l’architecture réseau. Pour trouver des solutions à ces questions, la BBC pointe qu’il est indispensable de se doter d’un laboratoire de test.

Est-on proche de voir le bout du tunnel ?

On semble continuer de croire que le bout du tunnel est proche et que de toutes façons nous n’avons guère le choix, c’est en effet le monde du Broadcast qui doit s’adapter au marché de l’IT et non l’inverse, réalité de marché oblige. Malgré tout, quelques doutes commencent à être émis sur la viabilité à terme de la suite de protocoles NMOS qui est censée assurer les fondations de la pyramide :

L’EBU, au sein du JT-NM, continue de mettre toutes ses forces au service de cette vision d’un monde post-SDI aussi interopérable que le monde SDI. Après un premier test d’interopérabilité à grande échelle à Houston dont les résultats sont disponibles ici : http://jt-nm.org/jt-nm_tested/, une deuxième édition est prévue fin août à l’IRT, pour inciter les constructeurs à poursuivre leurs efforts. Face à ce constat de douloureuse mutation, des voix s’élèvent également pour se demander si ce n’est pas le symptôme d’une industrie vieillissante qui a du mal à se renouveler et devrait peut-être laisser la place à de nouveaux acteurs plus agiles.

L’envers de la médaille de ces infrastructures « tout-IP » comporte néanmoins de nombreux avantages parmi lesquels le gain de place, d’efficacité et de souplesse dans les workflows, qui facilitent l’adaptation aux nouveaux enjeux de notre secteur.

Radio Télévision Suisse

Matthias Coinchon de la RTS (Radio Télévision Suisse) explique les enjeux et les besoins liés à la transformation du rôle de nos entreprises. De diffuseurs de télévision et radio linéaires, nous devenons producteurs et fournisseurs de contenus audiovisuels multi-formats, multiplateformes avec un besoin de personnalisation des contenus. Selon lui, pour être efficaces, il est impossible d’unifier les workflows de fabrication, nos entreprises doivent mettre en adéquation chaque chaine de fabrication en fonction du contenu produit : radio, télé, taille de l’évènement…

Pour un workflow de radio filmée les priorités sont à mettre sur une infrastructure simple et une automatisation extrême. Des systèmes plug and play « propriétaires » comme NDI ou Dante sont parfaitement adaptés et il manque cruellement de standards sur ce créneau de production. Pour les systèmes de production légère dans lesquelles la latence a une importance moindre, l’utilisation des infrastructures IT et télécom et du Cloud semblent pertinentes. De plus des standards émergent en alternative à Zixi pour le transport des flux par réseau terrestre. Nous parlerons plus tard de SRT et de RIST. Les travaux de standardisation actuel autour de NMOS et de SMPTE 2110 et la « Pyramide UER » ont leurs applications pour les systèmes de production lourde. Les essences sont en partie travaillées non compressés (Bâtiments / Camion de production) et les infrastructures ont besoin d’être résiliantes, sécurisées, évolutives et distribuées.

Or ce qui nous a fait rêver dans la migration vers les technologies IP, c’est la possibilité d’adresser l’ensemble des workflows possibles avec une seule solution modulaire.

Dans les trois scénarios décrits, il n’y a aucune incompatibilité technique, pourquoi ne pas l’adresser avec une solution unique ? C’est bien une problématique de maturité des standards que nous pousse à segmenter ainsi les « types » de workflow. À ce jour, les processus de standardisation sont encore en cours pour adresser l’entièreté des type de production. Et s’il manque cruellement de standards sur les systèmes de vidéos compressées, ce n’est qu’une question de temps.

ARISTA : Architecture réseau pour la production Live

L’adoption des technologies réseaux aligne le Broadcast sur les grands acteurs IP de la planète. Ainsi toute l’expérience acquise par l’industrie nous bénéficie et permet d’optimiser la résilience, la fiabilité et la disponibilité des infrastructures. Le message d’Arista est clair : nous avons l’expérience et la connaissance des infrastructures réseau, concentrez-vous sur les couches applicatives qui sont votre valeur ajoutée.

Quatre architectures sécurisées asservies à un SDN (Software Defined Network) sont détaillées en fonction de leur capacités :

  1. L’architecture « Spline » (agrégation des mots Spine & Leaf) basée sur deux chassis offrant un grand nombre de ports pour les solutions de moins de 2000 serveurs. Une infrastructure dédiée à de petites installations sur lesquelles les besoins d’évolution seraient limités. Elle concentre « façon SDI » les connexions réseau des équipements.
  2. L’architecture « MLAG » (Multi Ling Agregation) avec deux switches en coeur de réseau interconnectés par plusieurs liens. Les deux switches et leur dimension limiteront le nombre de switches connectés et donc la taille de l’infrastructure qui sera limitée à 10.000 serveurs. Cette infrastructure « Layer 2 » est très répandue, c’est l’infrastructure type des petits centres de données et des installations audio car elle est non seulement simple à mettre en œuvre, mais aussi certains systèmes de contrôle utilisent L2 comme protocole de découverte. Les deux cœurs permettent au système d’être résilient, mais une panne aura des conséquences importantes.
  3. L’architecture « ECMP » (Equal Cost Multi Path) qui garantit un nombre de sauts identiques pour aller d’un point à un autre quelque soit le chemin réseau pris. Cette architecture est scalable jusqu’à plus de 100.000 serveurs mais impose un routage (L3)
  4. L’architecture L2 over L3 qui fait intervenir le tunneling VXLAN. Cela a l’avantage d’associer la simplicité du layer 2 et la capacité d’évolution des infrastructures Layer 3. Ces infrastructures supportent plus de 100.000 serveurs.

De l’avis d’Arista, les architectures « layer 2 » ne sont pas adaptées à la production live sur IP en ST.2110. Le ST.2110 est caractérisé par des flux multicast à hauts débits. Des flux venant d’équipements réseau distants vont venir inonder les querier ICMP des switches centraux, cela requiert de très gros tuyaux, créé de grands domaines de défaillance et limite l’évolutivité.

Les infrastructures « layer 3 » sont à privilégier car aujourd’hui les switches savent router, les flux multicast sont routables par PIM et la segmentation permet de limiter la taille des domaines de défaillance. Les quierer ICMP ne sont plus inondés car les contrôleurs Broadcast vont gérer les flux réseau inter-switch.

Un nouveau codec lossless pour la production live ?

Du côté des formats, beaucoup d’attentes du côté du JPEG-XS qui sur le papier présente tous les atouts pour devenir le nouveau format pivot de production interne pour l’UHD. Basé sur le format TICO, JPEG-XS sera compatible avec la norme SMPTE2110-22 dédiée à la vidéo compressée, il promet une compression quasi-lossless dans des ratios jusqu’à 10 pour 1, avec une latence plus faible que JPEG2000 (quelques lignes vidéo) tout en supportant des résolutions allant de la HD à 16K, le HDR et le HFR (jusqu’à 120 fps), et en étant peu gourmand en ressources de décodage. Reste à savoir s’il tiendra ses promesses, et surtout s’il sera disponible en version software. Les standardisations finales étant attendues pour fin 2019, il faudra attendre début 2020 pour tester les premières implémentations et confronter ce codec à la réalité.

Les débits promis en JPEG-XS

Nouveaux usages, nouveaux workflow

SRT/RIST: des transports par Internet qui ont le vent en poupe.

Durant ce séminaire, on a beaucoup parlé des standards concurrents de Zixi pour le transport de la vidéo par liens terrestres. Ils pourraient faire drastiquement baisser les couts de contribution, de distribution et d’ingest « Cloud ». Deux standards open source semblent de plus en plus répandus. SRT est le plus ancien, supporté par Microsoft Azure, la plateforme Cloud de Microsoft. Il a été créé en 2013 et rendu open source en 2017. L’alliance SRT compte plus de 210 membres et plus de 700 clients. RIST a été créé en 2018 par le Video Service Forum, un regroupement d’utilisateurs et d’industriels du secteur audiovisuel. Il a le support d’Amazon Web Services et le code a été ouvert en 2019. Son forum compte déjà 30 membres et 10 implémentations. Sur le plan des fonctionnalités le RIST semble le plus avancé mais essentiellement dédié au transport de la vidéo alors que le SRT s’applique sur tous les flux UDP.

Des tests ont été menés pour évaluer le comportement des trois standards dans des environnements selon le degré de perturbation. SRT semble le plus robuste pour les environnements dont les pertes restent modérées. Il semblerait aussi que des fonctionnalités intègrent le protocole SRT dans les prochains mois, comme la FEC (Forward Error Correction) ou la sécurisation des flux en 2022-7. Il est à noter que la plupart des fournisseurs de solution de transport intègrent les deux protocoles, ce sera donc plus au niveau fonctionnel (AWS vs Azure) et au niveau des fonctionnalités que le choix entre les deux protocoles se fera.

Une production automatisée d’un orchestre en live à la BBC

La BBC a voulu tester la diffusion d’une production live automatisée. Cette expérimentation s’est basée sur un concert de musique classique. L’audience cible était donc un public de niche et à la recherche de bon contenu. Le succès de la conquête de ce public exigeant avec une production basée sur du matériel avec des caméras à faible cout (PTZ robotisée) allait dépendre de la qualité de la production finale… Un enjeu de taille quand on considère la performance d’un orchestre. Cette production aura affaire à un grand nombre de musiciens, à des interactions complexes et nécessitera des compétences spécialisées pour représenter l’interprétation du chef d’orchestre et l’intention du compositeur.

L’expérimentation a été menée avec 5 personnes dont 3 opérateurs caméra. Elle a mis en œuvre 8 caméras dont 6 PTZ automatiques. Ces caméras étant moins onéreuses, il est plus facile d’en mettre plus et d’avoir un contenu plus attrayant en augmentant le nombre de plan par minute. Chaque opérateur ayant plus de caméras cela devient devient beaucoup plus stressant de travailler sur ces productions, de plus il faut prévoir et enregistrer de nombreux plans. L’automatisation prend ici tout son sens mais la BBC n’a pas réussi à trouver le produit idéal. Il a fallu rajouter une personne qui « programme » la réalisation. Cependant les œuvres ne peuvent pas être jouées entièrement lors des répétitions ce qui empêche d’apprendre et de modifier les programmations. CuePilot, un logiciel dédié à la production live TV a été choisi car il désormais possible de contrôler des caméras PTZ.

Etude de l’œuvre et conception de la réalisation

Création des séquences dans un tableur.

Programmation dans CuePilot : l’opérateur peut à tout moment prendre la main sur ce séquençage.

L’économie d’argent entre une captation live classique et une captation PTZ est sensible, même en rajoutant les couts cachés supplémentaires (+ de codeurs / décodeurs, + de bande passante). Cependant il n’y a pas de différence de cout de production entre une prod PTZ et une prod PTZ automatisée. David Chalmers (BBC) explique par contre que la différence de qualité perçue est par contre au bénéfice de la solution automatisée.

En conclusion, l’expérimentation menée par la BBC est interessante sur plusieurs niveaux. La qualité de la production est grandement améliorée alors que la complexité opérationnelle n’a pas augmentée. La BBC cherche maintenant à explorer d’autre cas d’usage de ce type de production tout en continuant à l’améliorer. Un des axes d’amélioration étant d’éviter tout mouvement de caméra, un autre étant de rationaliser les rôles de chacun des opérateurs au cours du spectacle.

Expérimentations à la RTBF de production live à base de softwares

Le POC de la RTBF réduit a sa plus simple expression.

du NDI et du Dante…

Le choix a été fait de partir sur le protocole propriétaire de Newtec, le NDI qui permet le transport de vidéo compressée supportant bien le passage au tout logiciel. De même, pour l’audio c’est Dante qui a été choisi. Tous les flux Live en provenance de la régie finale de la RTBF étaient convertis en NDI par 4 passerelles SDI/NDI et mis à disposition en multicast sur le réseau.

Au final le système était stable mais l’approche 100% IT s’accompagne de défis IT tels que la gestion des mises à jour, la maintenance des postes de travail ou encore les problématiques d’authentification. Des questions restent ouvertes sur l’usage de telles technologies sur des infrastructures plus grandes avec en point d’orgue la question sur les flux multicast NDI.

BBC production live pour le Web « OBVan in a Box »

Une autre expérience de la BBC, leur service des sports a testé cette année le concept de l' »OB in a Box » : une régie légère construite autour de la solution logicielle « simply live ». Cette régie SDI, qui tient dans un rack d’une quinzaine de U, leur permet de couvrir et de produire plus d’évènements sportifs. L’interface est fournie par un mini-PC NUC sur lequel est connecté un écran tactile qui permet d’opérer le mélangeur, le serveur de replay et l’habillage (en NDI). Le mélangeur vidéo du système pourrait avoir jusqu’à 16 entrées, mais le modèle utilisé dans cette expérimentation ne disposait que de 8. Le système a été utilisé dans les deux modes : réalisation locale et remote : d’un site central la BBC il était possible de prendre la main sur le NUC de la « box ».

Différents tests ont été réalisés : dans le hall d’un évènement E-Sport, dans un salon de coiffure pendant la coupe du monde de football et enfin pendant les matches préliminaires à la coupe d’Angleterre de Football.

L’expérimentation fut probante : les budgets de production maitrisés, réduits et sans coûts satellites. Cet OBVan in a box a non seulement permis de réaliser des programmes inédits mais il a également fait émerger des idées sur d’autres types de production. Son usage a aussi permis une meilleure couverture de certains évènements comme la FA Cup. L’objectif affiché pour cette mini-régie est d’en améliorer la partie graphique (utilisation d’HTML 5), de la passer en full IP et de la réutiliser.

Enfin à l’opposé, Grass Valley présentait une remote production pour les championnats du monde de ski d’Are, en Suède. Liaison fibre optique privée sur 600km entre le lieu du championnat et les studios de Stockholm. 80 caméras remontées en vidéo non compressée vers la station (mais un réalisateur qui a quand même tenu à être sur place et disposait donc d’un mélangeur qui pilotait à distance la réalisation !) . Une économie de 10% sur les coûts de production.

Cloud / OpenStack

Il est commun de mentionner que le passage des technologies SDI vers les technologies IP est une première étape qui permettra le passage aux technologies Cloud. Ildiko Vasca de la fondation Openstack vient donc éclaircir la notion de Cloud et tous les concepts qui en découlent. Openstack est un ensemble de logiciels Open Source permettant de déployer des infrastructures de Cloud Computing (infrastructure en tant que service). Un logiciel Open Source est un logiciel dont on peut inspecter, modifier ou améliorer le code. Attention Open Source ne signifie pas gratuit pour l’entreprise, il faut mettre des ressources à disposition pour coder, partager l’expérience, aider les autres organisations afin d’adresser le même problème sans parler des ressources nécessaires à l’intégration des logiciels.

La fondation Open Source a notamment travaillé avec l’ ETSI (European Telecommunications Standards Institute) et l’OPNFV (Open Network Function Virtualization) pour standardiser un concept d’architecture réseau qui utilise les technologies de la virtualisation informatique pour virtualiser les fonctions du réseau et les représenter sous forme de blocs qui pourront être connectés afin de créer des services de communication. La fondation OpenStack chapote de nombreux projets et se déclare prête à assister la communauté du Broadcast dans le challenge de la migration vers le Cloud (on premise ou non…) de ses infrastructures.

De ce NTS nous retiendrons essentiellement que, même si l’avenir de la production IP s’éclaircît, l’architecture réelle idéale de la régie IP de référence n’existe pas encore. Il y a encore beaucoup de travaux a réaliser, que ce soit au sein des associations de normalisation pour avancer sur les différentes normes MPTE ou NMOS, que ce soit chez les constructeurs afin de s’y conformer ou que ce soit chez les usagers finaux afin de valider les interopérabilités et la conformité des solutions avec les workflows réalistes. Néanmoins, loin de s’étioler, le champs des possibles semble encore s’élargir et un certain nombre de concepts sont en train de devenir réalité dans l’univers Broadcast : adaptabilité des infrastructures, optimisation des ressources, agnosticité au format, production simultanée de formats et de contenus différents…

Ce contenu a été publié dans Audio, informatique, IP, Normes, Technologies. 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 *