Fabrice Gosnet, spécialiste et formateur, a répondu à ces interrogations dans le cadre d’une intervention sur la Satis TV. Il nous explique comment organiser au mieux un projet qui implique de transporter l’audio et la vidéo sur les réseaux informatiques…

Sonovision : Quelles sont les bases actuelles ? D’où partons-nous ?

Fabrice Gosnet : Aujourd’hui, c’est très simple, Ethernet est absolument partout. Très souvent, on me dit : « Le tout IP, c’est le futur ! ». Ce n’est pas vrai, l’IP, c’est le présent et c’est maintenant, grâce à des solutions propriétaires telles que Dante ou SDVoE ou encore NDI qui ont permis, ces dix dernières années, de démocratiser l’usage de la technologie IP sur les réseaux et principalement pour l’audiovisuel. Si je prends l’exemple d’Artnet, une autre solution propriétaire, qui est un protocole lumière, elle existe depuis plus de dix ans. Le signe qui montre qu’il y a un vrai besoin d’interconnexions et d’interopérabilités, ce sont les « standards » qui, eux, ont été placés et créés en même temps comme, par exemple, AES67 qui est l’essence même de l’interopérabilité pour l’audio sur IP par exemple. Les protocoles SMPTE pour la vidéo sur IP tels que 2022 ou ST2110, l’AVB/TSN ou l’sACN qui est un protocole pour la lumière sur IP, sont toutes des solutions qui ont permis que l’audiovisuel sur IP se soit démocratisé.

Souvent, l’installation audiovisuelle est indépendante du réseau du client mais elle est parfois mélangée, voire dans le même réseau. Cela doit changer la façon d’améliorer les choses, ce ne sont pas les mêmes contraintes ?

Tout à fait. L’une des principales consignes que je donne lors d’un travail de conseil avec les intégrateurs est : « Ne vous méprenez pas dans ce que je vais dire. » Je ne dis pas qu’ils font des erreurs, ils veulent absolument concevoir la plus belle installation pour le système audiovisuel de leur client mais ils oublient quelques fois de prendre en considération un point important : qui va utiliser le système ? Souvent, on fait l’erreur d’opter pour la solution technique la plus parfaite et « futur proof », celle qui sera le plus à même de répondre aux besoins dans les années futures mais il faut surtout se pencher sur la personne qui va utiliser ce système. C’est vraiment pour moi le point le plus important.

Comment aborder ce projet audiovisuel sur réseau ?

Je vais donner trois exemples. Imaginez que vous êtes dans un réseau autonome, c’est-à-dire que nous allons créer une installation pour un client et que ce système est tout seul, qu’il n’est pas connecté à un réseau informatique classique de l’immeuble ou qu’il ne sera pas connecté à Internet, bref il ne sert qu’à l’audiovisuel. Dès le départ, nous allons faire l’audit des besoins techniques avec les gens de la salle, faire le listing des équipements techniques dont ils auront besoin pour pouvoir atteindre leur but. Surtout, la question à se poser sera encore : qui va utiliser le système ?

En effet, si vos techniciens, très compétents dans le son, la vidéo, la lumière, n’ont pas de connaissance en réseau informatique, il va peut-être falloir privilégier l’utilisation de switchs. Une référence comme Luminex, qui est une société que je connais bien pour avoir travaillé avec elle, a dès le départ choisi des switchs avec des préfigurations conçues pour cela : pas besoin de rentrer dans les lignes de commande ou des choses trop compliquées, il suffit juste de paramétrer le switch en fonction de vos besoins.

Comme je le disais, les switchs sont préconfigurés et cela va vous faciliter la tâche. Il y a pleins de marques qui sont apparues comme Agora Ghost, ELC, Swisson… Ces switchs sont plus chers que les switchs dits « classiques » mais, par expérience, surtout en termes de support, nous allons dépenser plus d’argent après pour former les gens, pour dépanner le système, alors que si dès le départ la bonne infrastructure réseau avait été sélectionnée, les problèmes ne seraient pas là.

Le deuxième exemple que nous pouvons avoir c’est si nous créons un nouveau réseau qui sera à la fois convergent et en IT (Information Technology) dès le départ. Vous allez travailler en collaboration avec les gens de l’IT, de l’informatique puisqu’ils seront là. Nous ferons également un audit des besoins techniques. Par contre, à la fin, il faudra faire attention : qui administrera le système ?

Si le département IT et le département informatique sont là, il y a de fortes chances que cela soit eux qui gèrent ce système. Mais souvent les gens de l’IT ne comprennent pas les gens de l’AV et vice versa. Et pourtant, ils convergent !

Sur beaucoup de configurations sur lesquelles j’ai pu travailler, nous prenons un cœur de réseau IT qui va être gérer par le département IT, puis en fin de ligne, nous allons plutôt mettre des switchs AV pour que les utilisateurs finaux puissent, eux, toucher à ces switchs. Cependant, le département IT en aura toujours le contrôle à distance et pourra les monitorer.

Enfin, le troisième exemple. Lorsque vous faites une intégration directement dans un réseau IT existant, de notre côté, nous allons faire l’audit des besoins techniques mais aussi de l’existant et là, très clairement, c’est l’IT qui va décider ! Ce sont eux qui vont vous imposer les choix, cela risque de restreindre un peu plus vos souhaits audiovisuels.

Il y a d’autres scénarii possibles mais globalement, nous pouvons les réunir via ces trois cas de figure.

Côté audiovisuel, pouvons-nous dire que tous les flux audiovisuels sur le réseau sont identiques ? Il y a l’IT avec le problème de données et puis l’audiovisuel avec ses propres standards, est-ce cohérent ?

Nous sommes assez tolérants s’il y a un peu de latence concernant les flux informatiques classiques dans une société : envois d’emails, visioconférences… Pour un système audiovisuel, ce n’est pas possible ! Il faut comprendre les différents flux qui vont transiter sur un réseau audiovisuel.

Sur les trois grandes familles de protocoles, nous avons les poids légers comme la lumière sur IP qui ne prend pas le plus de débit ni de bande passante. Elle utilise l’unicast, le broadcast et le multicast. Cela ne nécessite pas la plupart du temps de QoS ni l’IGMP snooping.

Après, nous avons les poids moyens qui concernent l’audio sur IP où il y a une bonne utilisation du débit. Pour avoir une idée, si vous partez de 128 canaux en Dante, vous serez dans les alentours de 190 mégabits par seconde, ce qui est correct. L’audio n’est pas un gros dévoreur de bande passante mais par contre, il est extrêmement sensible aux jitters, c’est-à-dire la variation de délai et la variation de synchronisation sur un délai.

Nous imaginons bien, principalement avec la latence, que lorsque que quelqu’un parle ou lorsque nous écoutons un musicien jouant de la caisse claire, on veut entendre et voir en même temps ! Cela ne nécessite pas la QoS en mode autonome. Les gens utilisent souvent des switchs classiques et vont pouvoir faire transiter l’audio sur IP mais n’utilisent pas la QoS. C’est là où il faut être vigilant. À partir d’un certain nombre de canaux et surtout à partir du moment où nous rentrons dans un réseau convergé, un réseau où le son, la vidéo et la lumière sont mélangés sur le même réseau, il faudra alors mettre en place la QoS.

Si vous utilisez du multicast, vous n’aurez pas la plupart du temps, besoin d’IGMP snooping en mode autonome. Si vous êtes dans un réseau convergé, il faudra faire attention à l’IGMP.

Il y a enfin un poids lourd : la vidéo sur IP ! Imbattable pour ce qui est de prendre le plus de place sur un réseau informatique, elle utilise énormément de débit, surtout dans les formats non compressés. Je pense particulièrement à ST2110 ou SDVoE qui sont des protocoles nécessitant une vraie bande passante. Ils utilisent l’unicast et le multicast. Utiliser la QoS, l’IGMP snooping avec une infrastructure qui puisse supporter les Jumbo Frames est là fortement recommandé.

Ethernet est un protocole de communication. Vous pouvez l’imaginer comme un train dont les wagons vont être envoyés. Lorsque vous avez à faire avec des Jumbo Frames, il s’agit de très grands wagons ! Il faut donc que votre infrastructure réseau puisse les supporter…

Quelles sont les clés pour mettre en œuvre un réseau qui va bien fonctionner ?

Il faut, dès le départ, que les utilisateurs comprennent comment l’information est envoyée sur le réseau. Actuellement, je vous fais une très belle démonstration d’unicast : je ne parle qu’à vous. Dans le principe de l’unicast, la source va uniquement envoyer aux récepteurs qui auront besoin de ce paquet. C’est le switch qui va commuter ce paquet pour aller jusqu’au destinataire.

Imaginons maintenant une configuration avec un stade, par exemple, où nous souhaitons faire une multidiffusion et envoyer le même signal partout à tous les amplificateurs. L’unicast n’a pas vraiment de sens puisqu’il faudrait répéter à chaque fois la même phrase pour chaque destinataire. Cela prendrait trop de processing et trop de temps, cela inclurait de la latence.

Pour cela, une autre méthode de communication a été créée : le broadcast. La source va envoyer le message mais avec un format un peu spécial en adresse de destination que le switch va reconnaître. À partir du moment où ce paquet va rentrer dans le switch, il va répéter ce paquet à tous les ports actifs, sur toutes les sorties. Cela devient un problème si certains récepteurs ne veulent pas recevoir le paquet.

C’est pour cela qu’il y a une troisième méthode de communication : le multicast. Le switch va jouer un rôle prédominant. Si votre switch ne supporte pas l’IGMP snooping (Internet Group Management Protocol), lorsque vous allez envoyer un flux multicast dans le switch, ce dernier va le répéter, en faire du broadcast et vous perdrez alors malheureusement tout l’avantage de ce système-là.

Avec le multicast, c’est différent. Prenons un exemple, vous souscrivez à une newsletter sportive sur le surf. Imaginons que je sois le serveur qui vous la distribue. Je reçois toutes les newsletters et pourrai vous envoyer celle sur le surf à condition que le switch soit équipé du système IGMP snooping. Le multicast, c’est à la demande.

L’avantage de l’unicast, cela vient bien d’un point A à un point B. Avec le multicast, s’il y a plusieurs récepteurs, nous n’envoyons le message qu’une seule fois.

Exactement. C’est le switch qui va dupliquer la trame et qui va l’envoyer à ceux qui l’auront demandé. C’est ce qu’on appelle un service à la demande.

Un deuxième challenge à voir : la qualité de service. Par exemple, en conduisant, on nous apprend à laisser la voie libre pour laisser passer une ambulance. Le marqueur qui va déclencher cette alerte est la sirène et le gyrophare de l’ambulance.

Dans le switch, les paquets ne vont pas se déplacer pour laisser passer. Par contre, lorsque les paquets vont être émis pour les équipements audiovisuels, ils vont être marqués avec cet indicateur. Le switch va le reconnaître et va ensuite créer des files d’attente. En fonction de la qualité du switch, vous en aurez entre un et huit. La file d’attente n°1 aura une priorité plus basse que la file d’attente n°4.

Sur d’autres types de protocole tels que l’audio, il y aura des priorités plus hautes et en particulier dans les réseaux audio et vidéo, vous aurez l’horloge qui, elle, servira à synchroniser tous les équipements. Elle a une priorité extrêmement importante car c’est elle qui sera dans les files d’attente les plus hautes, comme c’est le cas de l’ambulance, afin de s’assurer que la synchronisation de tous les équipements est bien faite en temps et en heure.

C’est le système de priorité du réseau. Y a-t-il encore d’autres paramètres à prendre en compte ?

Les clients ne pensent pas souvent à la latence. Elle a plusieurs origines. La première est la conversion. Lorsque nous allons convertir par exemple le son d’un micro analogique via une stage box, un convertisseur, il va y avoir un temps d’encodage. Je prends l’exemple de la traduction : quand quelqu’un dit « hello », le son est émis, la personne au milieu comprend ce mot « hello » et doit ensuite processer ce message pour le traduire. Ce sera exactement la même chose avec un convertisseur. Il ne faudra pas mettre trop de conversions dans toute la chaîne audio numérique pour ne pas se retrouver avec de la latence.

Concernant le traitement des données, lorsque vous faites de l’IGMP snooping, c’est le switch qui prend les décisions comme nous l’avons évoqué précédemment. Quand il reçoit les paquets, le switch va les inspecter. Cela va prendre un petit temps de traitement. Ce sera la même chose avec la qualité de service.

Cumuler la latence de conversion avec la latence de traitement de données et sans faire attention au nombre de sauts, augmentera cette latence.

Un saut, c’est juste le fait qu’un paquet passe d’un équipement réseau à un autre. Par exemple, un switch ou un routeur est un saut. Il faudra faire attention à ne pas mettre trop de sauts dans toute la chaîne en particulier en audio et en vidéo qui sont extrêmement sensibles à la latence.

Nous risquons d’augmenter la latence si nous mettons de l’IGMP et de la qualité de service, mais le réseau n’est pas toujours le plus responsable de cette latence… C’est bien souvent plus l’encodage et le décodage…

C’est vrai mais tout le secret est dans la charge réseau. Si vous avez énormément de données, il faudra vraiment faire appel à la qualité de service et à l’IGMP snooping. Si vous avez une faible quantité de données, cela n’aura pas de sens. J’ai plusieurs fois recommandé aux clients de désactiver ces fonctions-là. Il faut aussi être vigilant lorsque vous mélangez des équipements par exemple en 10 Gbits et en 100 Mbits. Si vous n’avez pas l’IGMP snooping avec des flux multicast, lorsque le flux multicast va rentrer dans le switch, il va malheureusement broadcaster. Et si vous avez des équipements avec des interfaces réseaux qui font 100 Mbits, elles vont se trouver arroser avec beaucoup d’autres données et cela va saturer. Ce sont vraiment les basics.

Pour un réseau convergé, nous allons principalement essayer d’indiquer tous les départements : son, vidéo, lumière. Nous allons les séparer avec une technologie appelée VLAN, autrement dit des réseaux virtuels. C’est-à-dire que nous allons segmenter des réseaux virtuels à l’intérieur d’une architecture globale. Les switchs AV comme les switchs Luminex marchent très bien. L’arrivée de Netgear dans le monde AV avec ces switchs dédiés est un signe que la technologie Ethernet est mûre dans ce métier, nous pouvons l’utiliser !

Bio

Fabrice Gosnet est formateur et consultant spécialisé en réseaux audiovisuels, en informatique dédiée à l’audiovisuel. Fort d’une expérience de quatorze ans en design de réseaux, en design de produits, en support technique et en formation à l’international, il a fondé Goosera, une société offrant ses services de consulting pour aider à concevoir des réseaux dédiés à l’audiovisuel, optimiser des réseaux existants voire les dépanner.

A.V.N.T, un projet, cinq niveaux

Possédant des connaissances approfondies dans le son, la vidéo et la lumière, la plupart des techniciens en audiovisuel ont des lacunes au niveau des compétences réseaux. Faisant ce constat, Fabrice Gosnet a mis en place le projet A.V.N.T. (AudioVisual Network Technician).

L’A.V.N.T. – qui est un projet européen à la base – propose cinq niveaux différents de formation pour que chaque technicien puisse se former tout au long de sa carrière.

Le niveau 1, lumière ou audio, va principalement se focaliser sur les équipements terminaux, que ce soit consoles ou stagebox. Le niveau 2 concerne les fondamentaux aussi bien le Backbone que la dorsale, tandis que le niveau 3 s’intéressera au Switch IT. Quant au niveau 4, il aborde les réseaux avancés et le niveau 5 prend la forme d’un workshop.

Article paru pour la première fois dans Sonovision #22, p. 22-26. Abonnez-vous à Sonovision (4 numéros/an + 1 Hors-Série) pour accéder à nos articles dans leur totalité dès la sortie du magazine.