EBU NTS 2017 : Les régies IP, le temps des questions

Les 20 et 21 juin s’est tenu à Genève le NTS (Network Technology Seminar) organisé par l’UER (Union Européenne des Radiodiffuseurs).

Durant deux jours se sont succédés 26 présentations et 4 débats de constructeurs, d’organismes, d’alliances et de diffuseurs européens sous la houlette d’un modérateur membre de l’UER. On y parle technologies avant de parler produits et chaque présentation est suivie d’un jeu de questions réponses très animé.

Par Edmond Debar – France Télévisions – innovations&développements

Depuis 2 ans, l’engouement pour cet évènement va croissant, le NTS s’est joué cette année à guichet fermé. En plus des inscriptions physiques, des inscriptions « streaming » ont été nécessaires. Cela a contraint l’UER à rechercher un outil permettant de poser des questions en ligne, d’où l’heureuse utilisation de sli.do, un outil vraiment intéressant. Chacun pouvait voter afin de faire remonter les questions les plus pertinentes en haut de la file.

Cet engouement est lié au fait que l’ensemble du monde du Broadcast a enfin pris conscience du délicat virage technologique qui l’attend : l’IP. Les acteurs plus traditionnels de l’IT sont aussi venus en masse pour apporter leur expertise. De nombreuses chaines de télévision ou de radio ont des projets concrets qui vont voir arriver l’IP de bout en bout dans les années à venir.

Les chantiers technologiques :

Le chapitre « Cloud & infrastructure IP » est l’un des six chantiers technologiques de l’EBU. Il est étroitement connecté à deux autres : Data et Cyber-sécurité. L’ensemble de ces trois chantiers sera couvert par le NTS 2017.

La JT-NM (Join Task for Networked Media) qui représente les efforts communs de l’UER, de la VSF (Vidéo Service Forum), de l’AMWA et du SMPTE décrit l’adoption des technologies sur une roadmap instructive :

La ligne verticale rouge est un curseur qui permet de se positionner dans le temps afin de voir l’arrivée des technologies et des standards. Notons que l’échelle de temps indique les différents salons du Broadcast. Ce sont en effet par rapport à ces grandes dates clés que les R&D des équipementiers fournissent les efforts nécessaires pour le développement de leurs nouveaux produits afin de bénéficier des effets d’annonces lors de ces salons.

Parmi toutes ces dates, il faut noter l’adoption « réelle » du SMPTE 2110, norme qui sépare  les essences (Audio, Vidéo & Métadonnées) en 3 flux IP différents au contraire du SMPTE 2022 actuel et ne sera effective que pour le NAB 2018. Le NMOS (Networked Media Open Specification) sera postérieur au SMPTE 2110 et ne sera ratifié au plus tôt que pour l’IBC 2018.

On ne commencera à parler de « virtualisation » des équipements qu’à partir du NAB 2019.

Les initiatives actuelles

Certains broadcasters se sont lancés dans l’aventure. Des échéances prévues dépendent des technologies possiblement adoptées. Si certains se lancent en SMPTE 2022, d’autres font le choix, audacieux certes, de prévoir des infrastructures en 2110, norme non ratifiée complètement aujourd’hui.

Ainsi CBC / Radio Canada associe au déménagement de sa maison mère l’arrivée massive de l’IP dans les régies et les studios. Un début d’installation en aout 2018 avec pour objectif d’être « on-air » le 31 décembre 2019. Date à priori compatible avec une infrastructure 2110. Le bâtiment prévu est presque 3 fois plus petit que l’actuel et l’objectif est évidemment de diminuer fortement le volume d’équipements techniques.

De nombreuses questions fusent de l’auditoire : le SMPTE 2110 sera-t-il ratifié et définitif ? Notre interlocuteur, Felix Poulin explique que ce passage à l’IP est obligatoire pour simplifier les infrastructures et surtout permettre la virtualisation des outils. Le choix technique final n’est cependant pas encore entériné.

Notre interlocuteur rentre alors dans des considérations techniques en expliquant les deux profils de la synchronisation du temps en SMPTE 2110 (sous-partie n°21) : l’émetteur/récepteur étroit (narrow sender/receiver) et l’émetteur/récepteur large (wide sender/receiver).

Avoir deux profils peut créer des problèmes. Il est obligatoire d’avoir des récepteurs larges car ils acceptent l’ensemble des flux, quel que soit leur type (wide/narrow). De ce fait, le cœur de l’infrastructure de CBC /Radio Canada sera IP & SMPTE 2110 de façon à assurer la compatibilité avec tous les équipements connectés en périphérie.

La radio publique suédoise SR présente un projet qui a récemment abouti. Il n’est donc nulle question de SMPTE 2110 ou de SMPTE 2022. On parle d’ACIP (Audio Contribution over IP), de production déportée, de sécurité et d’interface. Les détails dans cet article.

La BBC Cymru Wales doit aussi déménager pour occuper des locaux neufs mi 2020 et, comme CBC / Radio Canada, la BBC Wales en profite pour faire le saut technologique.

Le choix technique se porte aussi sur le 2110/AMWA NMOS, comme pour CBC / Radio Canada, mais le projet semble plus abouti : en effet la BBC a donné le marché à Grass Valley qui a proposé une infrastructure redondée autour de switches Cisco. Un autre aspect intéressant est la « sécurisation du projet global avec une solution de repli vers une technologie SDI. La BBC explique aussi que la cyber-sécurité est au centre de ses préoccupations, elle conservera donc des passerelles IP/SDI-SDI/IP afin de garantir une imperméabilisation des différents réseaux. L’infrastructure globale sera donc hybride, un projet vraiment intéressant à suivre.


La Sky (GB) présente son projet d’évolution de ses régies vers l’IP. Le projet, nommé Tardis est contraint à un calendrier bien plus serré.

La nouvelle régie devra être en ligne dans quelques mois, dès fin 2017, de ce fait un certain nombre d’impasses sont faites : une synchro temps qui ne sera pas 100% PTP, et surtout une infrastructure principalement sur la base de passerelles. Seuls des multiviewers, des serveurs de transcodage et d’ingest seront nativement IP.


Une autre présentation intéressante fut celle de Chris Lock de Google qui a expliqué le concept et l’infrastructure des Youtube Spaces. Il s’agit de moyens de production (Studio, Régies, …) qui sont mis gratuitement à la disposition des Youtubers à succès (plus de 10k abonnés). À ce jour, il existe 9 sites : 3 en Amérique du nord, 3 en Europe (dont Paris & Londres), 1 en Inde, 1 au Brésil et 1 au Japon. Ces espaces sont construits dans des espaces de bureaux multi-locataires génériques et sans isolation acoustique, ils sont constitués de 2 studios et d’une régie commune. Techniquement, ils sont prévus pour être modulaires, évolutifs vers l’UHD et normes suivantes et les infrastructures sont IP dans la mesure du possible. Pour ses derniers studios, Google utilise les protocoles Dante (Audio) et Aspen (Video-standard propriétaire Evertz) pour des flux UHD 50p qui transitent sur des liens 10 Gbps et se trouve confronté à des problèmes de poussière (sic) et de compétence d’intégration réseau dans un monde audiovisuel. Ils envisagent de créer un cursus de formation spécifique. Les évolutions prévues pour ces infrastructures sont logiques : migration de l’ASPEN vers le  SMPTE 2110, l’intégration de NMOS, la mutualisation des réseaux de données et de vidéo (aujourd’hui séparés) et la virtualisation afin d’avoir des pools de ressources dont les fonctions peuvent être changées. Enfin Google va continuer la généralisation de ces infrastructures avec les ouvertures prochaines de deux sites : un a Berlin et un a Dubai.


Alex Rawcliffe, du département de recherche de la BBC, explique le point de vue de son département pour les futurs studios IP en présentant le nouveau studio « Xenon » basé sur le « Cloud » au sens large et qui n’est interfacé que par des browsers web. La BBC R&D travaille aussi sur OpenStack afin de proposer encore une couche de virtualisation autour du Cloud. Xenon travaille pour des évènements de courtes durées et sur lesquels les demandes et les besoins peuvent être très variables d’un jour à l’autre. En entrée de Xenon, des flux vidéo fournis par des sources externes Broadcast traditionnelles. Pour Xenon la BBC s’est appuyée sur les services d’Amazon, le Cloud leur permet d’ajuster les ressources à la demande. En contrepartie, la sécurité a été fortement étudiée, avec la création d’espaces réseaux publics pour ce qui doit être exposé et d’espaces réseaux privés pour le process. La BBC a beaucoup de choses à finir, notamment les interfaces utilisateurs, les outils de gestion des API et un grand programme de tests est prévu pour cet été. L’objectif est de montrer une plateforme fonctionnelle pour l’IBC, en septembre prochain, dans la « future zone ».


 Les présentations techniques

Lors du séminaire, un très grand nombre de présentations techniques a eu lieu. Des présentations qui allaient des explications les plus minimalistes aux concepts les plus élaborés.

Voici de manière synthétique ce que nous avons retenu :

  1. Le SMPTE 2110 (présentation de John Mailhot, Grass Valley) reste à terminer. Sur les 7 sous-systèmes, seuls les 3 votes FCD (Final Community Draft) des sous-systèmes 10 (System Timing), 20 (Uncompressed Video) et 30 (PCM Audio) ont été approuvés. Il reste donc 4 chantiers : celui du façonnage du trafic (21, traffic shapping) qui est presque achevé, et ceux des profils audio non-PCM (31), des données auxiliaires (40) et le chantier de l’intégration avec SMPTE 2022-6 (50). Il reste beaucoup de travail pour finaliser ce SMPTE 2110, le voir arriver fini pour le NAB 2018 sera, à mon avis, déjà un grand succès.
  1. Le SMPTE 2059 (présentation de Nikolaus Kerö et Thomas Kernen) requiert une attention particulière et des switches « compatibles », l’utilisation de switches « deep packet buffers » recommandés dans les applications audiovisuelles posent notamment d’énormes problèmes.
  1. En partant d’un succinct historique d’avancées technologiques, Richard Cartwright, de Streampunk Media, alerte sur le fait qu’aujourd’hui tout est du logiciel et que tout passe par des API (Interface de programmation donnant accès a des fonctions d’un logiciel). Il reprend les différents paradigmes exposés lors du séminaire et les critiques : des architectures de référence, il supprime les systèmes intégrés, il reprend l’usage des différents protocoles, TCP, UDP et HTTP en recommandant l’usage d’http pour être « Cloud compatible », enfin il jette un dernier pavé dans la mare en ajoutant que, justement, SMPTE 2110 n’est pas Cloud compatible.
  1. Le projet FIMS (Framework for Interoperable Media Services, projet commun entre l’UER et l’AMWA) dont les objectifs sont de créer un ensemble de librairies et composants logiciels et de fournir des « best practices » pour la mise en œuvre de workflows média dans un environnement Cloud a mis en œuvre une démonstration pour le NAB avec Amazon. La démonstration met en évidence des déplacements d’essence de données, la création de fichier proxy, d’imagettes et le renseignement d’une base de données sémantique, tout cela déclenché à partir de l’envoi d’un fichier JSON dans l’espace public d’Amazon. L’interface semble claire, et la démonstration probante, à quelques problèmes de rafraichissement du navigateur web près et surtout il a été démontré la pertinence d’une integration dans le Cloud pour des opérations et des workflows média. L’intervenant (Jean-Pierre Evain de l’EBU) a vanté la puissance et l’efficacité du format de fichier JSON-LD pour le renseignement d’une base de données sémantique. Les principales réflexions, pour la mise en œuvre de cette démonstration furent la localisation des données : local/distante, ou encore les espaces publics ou privés. La génération de données sémantiques et la liaison avec les données fut vraiment aisée, et c’est le point principal de cette démonstration. Les objectifs à venir sont nombreux, parmi ceux-ci, certains se distinguent car le but est aussi de définir les scripts et des librairies standardisées, de réaliser, pour l’IBC prochain, une démonstration mixant les services Cloud (Amazon+Azur), ou encore une démonstration commune de FIMS avec NMOS.
  1. Prem Jonnalagadda de Barefoot Networks présente un nouveau concept de switch programmable (Software Defined Switch) regroupé sous l’architecture PISA (Programmable Independent Switch Architecture). Les constats menant à cette architecture sont partagés avec les promoteurs des SDN, mais à la différence du SDN, cette solution n’adresse pas un ensemble de switches, mais chacun des switches indépendamment. Afin de programmer les switches, notre intervenant présente le langage de programmation P4 (Programming Pack-independent Packet Processors), un langage simple issu du travail d’un consortium, une initiative open-source. Les documents relatifs au travail du groupe sont visibles sur P4.org et dispose d’un github afin de gérer les versions de code, les bugs, les requêtes et l’ensemble des taches dévolues à ce type de site Web. Un des avantages est que l’utilisation de la mémoire peut être optimisée, car elle sera allouée la où elle sera utile, et non plus « figée dans le silicium » comme dans le cas des switches traditionnels.

Un processeur fonctionnel pour ce type de switch existe déjà, il dispose d’une bande passante de 6.5 Tbps, c’est à priori le processeur de switch le plus performant du monde et ne consomme pas plus d’énergie que l’ensemble des processeurs à fonction fixe requis pour un switch. La programmation P4 semble facile : en une seule journée un programmeur peut apprendre à programmer la puce sur l’environnement Capalino.

Une application concrète a été mise en œuvre chez Fox, avec une réplication multicast (fonction réalisable par un switch traditionnel) complétée par une translation d’adresse NAT, ces deux fonctions ne peuvent pas être associées dans le cas d’un switch classique.

Une autre application traite d’une meilleure répartition de charge dans le cas d’architecture « Spine & Leaf » en évitant que les gros trafics ne prennent systématiquement les mêmes liens, ce qui permet une meilleure utilisation de la bande passante.

Enfin une dernière application permet de descendre au sein de header des trames RTP afin de router plus efficacement les packets a leur destinataire.

La conclusion de l’intervenant fait un peu rêver : maintenant que nous avons P4, on peu créer de nouveaux protocoles, de nouvelles applications, supprimer des fonctions ou protocoles inutiles, utiliser de nouveaux compteurs, faire de nouveaux diagnostics, utiliser des tables de routage dynamiques adaptées…

  1. Enfin la sécurité n’a pas été en reste, en toile de fond dans toutes les interventions, elle a fait l’objet d’un débat et une présentation spécifique du groupe de travail a eu lieu. C’est le chairman de ce groupe, Andreas Schneider, qui a exposé les différentes recommandations afin d’avoir la bonne approche pour apporter la sécurité dans le Cloud. La sécurité doit être étudiée dans toutes les strates des infrastructures : réseau, hardware, système et applicatifs. On retiendra de cette présentation que l’ensemble des principes existe déjà, qu’il a déjà fait l’objet de nombreuses publications et que l’objectif du groupe est surtout de les rassembler, de les adapter et de nous les rendre compréhensibles. Le groupe propose donc des questions à poser aux fournisseurs de Cloud et des clés pour décrypter les réponses de ceux-ci. Enfin il insiste sur la confusion fréquente qui existe entre les termes sécurité et disponibilité, il faut donc réfléchir dans les deux sens, dans un cas on ne diffuse pas de news, dans l’autre cas on diffuse des nouvelles fausses, on parle de problème d’intégrité, et les dommages liés a ce type de problèmes sont bien plus importants que dans le cas d’un simple problème de disponibilité. Les chantiers sont donc nombreux : l’authentification, l’encryption des données et la gestion des clés correspondantes interviennent dans les architectures à mettre en œuvre.

Le groupe propose des architectures Cloud de référence en fonction des besoins exprimés, l’ensemble de ces recommandations est visible sur le site de l’EBU dans le document R146 publié en Juin2017.

Conclusions

Comme chaque année, le NTS fut instructif, mais les questions restent nombreuses et les choix guère évidents. Même si certains se jettent dans l’espoir d’une finalisation rapide des standards SMPTE, le choix en terme d’architectures réseaux semblent se diversifier : programmable ou non, au niveau global ou non, avec ou sans buffers, Cloud ou non… C’est pour cela que, suite au NTS, plusieurs décisions ont été prises pas l’EBU, avec en premier lieu la création d’un groupe de travail sur les meilleures façons de construire une architecture réseau « média » et enfin un travail particulier sur les différentes affirmations de Richard Cartwright pour la « Cloudification » des architectures Broadcast. Rendez-vous l’année prochaine car, même si les chantiers sont nombreux, l’EBU a à cœur de faire avancer les standards, de la manière la plus claire, la plus pertinente et la plus rapide possible.

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

Une réponse à EBU NTS 2017 : Les régies IP, le temps des questions

  1. Nicolas moreau dit :

    Excellent article. Merci pour cette vision d’ensemble.

Laisser un commentaire

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