Les constructeurs des produits audiovisuels intègrent désormais de plus en plus les prises RJ45 (prises réseau). Les protocoles de communications sont variés et les taux de compression s’améliorent au niveau du streaming.
Qu’est-ce qu’une adresse IP ?
Une adresse IP se décompose dans une suite de chiffres séparée par des points. Elle est utilisée quotidiennement dès que l’utilisateur se connecte à son téléviseur et à sa box Internet ou quand il lit un mail sur son téléphone. Pour que l’adresse IP puisse communiquer avec d’autres adresses, elle doit posséder également un masque de réseau et une passerelle, une autre série de chiffres. Elle a besoin de cette route pour pouvoir dialoguer.
On retrouve donc ici les routeurs et switch qui peuvent attribuer des adresses IP (DHCP) et des routes aux appareils connectés. Cela peut se faire d’une façon dynamique (DHCP) ou d’une façon statique. Dans ce dernier cas, l’utilisateur doit attribuer manuellement cette adresse avec son masque de réseau et sa passerelle.
Pour les caméras et les autres appareils, les constructeurs attribuent une adresse statique locale à l’appareil et une interface pour y accéder via un navigateur Internet. Il suffit alors de modifier l’adresse IP de l’ordinateur pour accéder à la caméra sans passer par sa box. Ensuite, on peut modifier les paramètres pour les adapter à ses besoins et contraintes, à son réseau.
Comment reconnaître une adresse IP dite locale ?
Il y a plusieurs plages IP qui sont typiquement réservées pour un LAN (le réseau local). Elles commencent généralement par 10.xxx.xxx.xxx ou 192.168.XXX.XXX. Elles sont donc facilement reconnaissables. Une adresse également très commune est l’IP 127.0.0.1. Elle permet de se connecter à son propre réseau, ce qui peut aussi avoir son utilité.
Ces adresses IP permettent donc de se connecter aux caméras et autres mélangeurs localement. Afin d’être efficaces, les logiciels et matériels « écoutent » si des données leurs sont adressées sur un port spécifique. Ce port se présente sous la forme suivante : 192.168.XXX.XXX:PORT. Une adresse IP peut ainsi « écouter » de très nombreuses données différentes (ports différents). En fonction du port choisi, elle adressera la « requête » (instruction) à une partie spécifique de l’appareil ou de l’ordinateur.
Pour cela, la requête va utiliser une route. Par exemple, lorsqu’on utilise son navigateur pour aller sur un site, l’ordinateur adresse une requête à la carte réseau, qui va ensuite au routeur, puis vers Internet et enfin vers le site. Cette route passe ainsi par plusieurs chemins au travers de routeurs Internet, chacun défini par une adresse IP. Lorsque la requête quitte le réseau local, la box par exemple, elle reçoit donc une identité différente, une adresse IP dite « publique ».
Le chemin utilisé dépend de votre fournisseur d’accès et de l’adresse physique du site Internet auquel on accède. Dans une navigation vers des sites Internet classiques, la vitesse et le chemin utilisés sont sans grande importance. Au contraire, dans un streaming vers Internet ou une vidéo dans le cloud c’est crucial. Lorsque l’on produit de la vidéo sur IP, il y a de nombreux goulots d’étranglement. Ils commencent sur le réseau local, puis sur le routeur et la box Internet, et enfin sur tous les routeurs Internet…
L’IP pour contrôler, l’IP pour diffuser
Les constructeurs sont nombreux à utiliser une interface informatique pour contrôler les caméras, gérer les mélangeurs ou encore les diffusions. Ces appareils sont connectés à l’ordinateur soit par USB, soit par le réseau ou encore par des connexions SDI/HDMI.
Il faut bien comprendre la logique de cet accès par IP. Même si l’USB est présent sur tous les ordinateurs, on se heurte à des limitations par le nombre de ports USB disponibles. Le réseau est ici vraiment la solution. L’accès par IP est simple à concevoir et est universel pour l’interface de la caméra, du mélangeur via une API et une IP. Deux exemples d’applications tierces : Bitfocus Companion et CentralControl, permettent d’accéder à une multitude d’appareils audiovisuels.
Schéma du réseau local
Dans cet exemple, l’ordinateur portable dispose de l’IP 192.168.1.66 à un réseau 255.255.255.0 avec la passerelle 192.168.1.1., ici le routeur vers Internet. On trouve à l’IP 192.168.1.94 une caméra IP avec le port 4 600 ouvert pour accéder aux paramètres de la caméra.
Il suffit maintenant de se connecter aux interfaces de ces appareils avec le navigateur Web par exemple, ou avec votre Companion de Bitfocus ou encore Centralcontrol.io pour accéder aux fonctions de base et, selon le cas, à l’interface de programmation (API).
Lancer un Rec d’un l’hyperdeck connecté peut alors se résumer à un clic à partir de l’ordinateur, changer de position d’une caméra PTZ pour un autre preset se fait de la même manière, et tout cela à partir d’un ordinateur du réseau. C’est tout l’intérêt du réseau local et tout l’intérêt pour s’intéresser à cette IP, à la vidéo sur IP par extension.
Comment accéder par l’extérieur, c’est-à-dire par Internet, au réseau local ?
Ici l’IP 192.168.1.1, le routeur et passerelle, dispose de deux adresses IP. L’adresse que l’on connaît déjà mais aussi son adresse publique, dans l’exemple 91.24.15.171. Cette dernière adresse désigne votre routeur vu de l’Internet. Lorsque l’on a besoin d’y accéder depuis l’extérieur, pour du télétravail, pour de la remote production, il faut paramétrer son pare-feu pour l’on puisse accéder à une adresse IP interne et ses services ouverts.
Prenons l’exemple d’un vMix installé sur l’ordinateur (192.168.1.66). L’interface de vMix, sa « surface de contrôle », ou son interface Web, est à l’écoute 192.168.1.66:8089. Si vous êtes sur votre réseau, il suffit de taper cette adresse dans le navigateur pour y accéder. Mais comment faire pour y accéder de l’extérieur ? C’est là le rôle de votre Firewall et du service NAT (Network Address Translation) dont le rôle est d’écouter les ports externes et de forwarder la requête externe vers la bonne adresse IP et le bon port interne. Ce sont les règles NAT qu’il faut définir. Donc il faut déclarer le port externe que l’on veut « ouvrir » et vers quel port et IP cette requête doit être envoyée (routée).
Pour reprendre l’exemple ci-dessus avec le Web Panel de vMix sur l’adresse IP 192.168.1.66:8089, il faut indiquer au serveur NAT quel port externe écouter. Cela peut être n’importe quel port mais restons simple prenons le port 8 089 que l’on veut transférer vers l’adresse 192.168.1.66 et le port 8 089. Dès sa validation votre adresse publique et son port 8 089 seront automatiquement envoyés vers l’IP 192.168.1.66 et le port 8 089. La relation entre le port externe et le port interne n’est pas obligatoire, voire recommandée. Vous pourriez déclarer le port externe 10 217, et le router vers votre adresse IP 192.168.1.66 et le port 8 089.
La caméra PTZ diffuse par exemple un flux SRT sur son port 5 023. Celui-ci est accessible à vMix sur le réseau. L’application VLC permet aussi de visionner ce flux, cependant impossible d’y accéder depuis l’extérieur du réseau. Là encore le serveur NAT permet de faire la relation entre l’IP et le port local, et l’IP publique et le port attribué. Le NAT est très flexible et l’on peut attribuer de très nombreux ports pour les router vers le réseau interne.
Ces notions très basiques sur l’IP publique et l’IP locale permettent de comprendre tout le potentiel de l’adressage IP et les usages que l’on peut imaginer sur des réseaux étendus avec ou sans Internet. Se rapprocher d’informaticiens au sein d’une équipe de production audiovisuelle permet d’aller bien plus loin, de prendre en compte d’autres aspects du réseau informatique et son importance. Le réseau n’est pas réservé aux applications bureautiques mais doit intégrer aussi tous les aspects de l’audiovisuel et ses contraintes dont la bande passante.
De la remote production (REMI) au cloud en une IP
Par le biais de l’IP, on peut donc accéder quasiment au monde entier. C’est une des approches et la clé du succès du NDI, protocole proposé par VIZRT. Chaque source IP devient une source potentielle pour une production vidéo. La légèreté de commandes informatiques permet en quelques microsecondes d’obtenir le résultat souhaité. Faire de la remote production (production à distance) entre deux lieux, deux réseaux est facile. On peut rapidement se sentir à l’aise avec des temps de réponses quasi instantanés. On connaît le réseau local, et l’on connaît le réseau local distant.
Cependant cette configuration n’est pas parfaite. Les deux réseaux sont limités par une série de goulots d’étranglement, par l’informatique et ses possibilités, mais aussi les appareils de connexion réseau, les routeurs… D’autres protocoles comme le SRT permettent aussi de véhiculer de la vidéo.
Comment alors optimiser la remote production ?
Au lieu de faire des allers-retours entre ces deux réseaux locaux distants par le biais de l’Internet avec des temps de réponse aléatoires, il est préférable d’utiliser le cloud. Une seule voie montante via le NDI ou le SRT avec un traitement en ligne dans le cloud et une diffusion vers les destinations de son choix. Les seuls échanges se font alors par le biais des commandes IP à grande vitesse entre le réseau local et Internet.
Le traitement vidéo à distance (dans le cloud) peut sembler complexe et peu sécurisant. Cependant les principaux fournisseurs proposent des configurations adaptées et compétitives. Le hardware est configurable à souhait et des datacenters sont regroupés par régions permettant de limiter les distances entre votre réseau local, les caméras et le cloud. En fonction de la chaîne de diffusion, l’utilisateur bénéficie alors d’un flux vers d’autres plates-formes avec une qualité et une vitesse inégalées.
L’obstacle de la timeline IP
Le temps réel est un argument de poids dans l’audiovisuel et cela particulièrement en régie, mais aussi sur les écrans de retours en studio ou sur des manifestations événementielles. Peut-on imaginer un retour d’images décalées de quelques secondes ? L’autre obstacle, et non des moindres, est la synchronisation des sources, et cela autant pour l’audio que la vidéo. Deux écueils à surmonter.
Souvent une régie se trouve dans un autre local, voire un autre lieu avec un car-régie. Quelle que soit la localisation, il y aura fatalement un léger décalage temporel. Quelques millisecondes ou quelques centaines de millisecondes, en tout cas moins d’une seconde. L’encodage de la caméra, transfert des données sur le réseau, décodage ou transcodage sont des facteurs de latence, autant que le transfert lui-même.
Si l’encodage est rapide, le transfert des données reste dépendant du réseau et d’Internet. Cependant, il s’agit ici la plupart du temps d’une fraction de seconde, qui se réduit comme une peau de chagrin au fur et à mesure de l’avancée des technologies. Ce qui pourrait être réellement frustrant c’est la désynchronisation temporelle des images et du son. Mais là encore, les serveurs de temps (NTP) sont nombreux sur Internet, et l’ordinateur ou le smartphone sont synchronisés avec ce type de services à intervalles réguliers de même que les appareils audiovisuels.
L’approche réseau informatique, réseau IP, est aujourd’hui un cheminement indispensable. Sa facilité de mise en œuvre et son positionnement universel permettent de contrôler n’importe quel équipement sur la planète. Le matériel audiovisuel, bien qu’encore fortement ancré SDI ou HDMI, passe également de plus en plus vers l’IP ou intègre celle-ci dans ces options. Si la latence et la synchronisation restent les principales objections pour une migration totale de la production vidéo vers le cloud, il existe déjà des technologies éprouvées pour régler ces problèmes.
Que ce soit pour le contrôle ou la diffusion, l’IP dispose donc aujourd’hui de sérieux atouts pour faire migrer les points forts des anciens systèmes vers les réseaux locaux et les réseaux distants. L’évolution est inéluctable dans un monde où tout appareil est connecté. La bande passante est de plus en plus large et la compression de plus en plus efficace. Divers convertisseurs permettent de relier les deux méthodes de contrôle et de diffusion, et par conséquent de migrer la production vidéo au fur et à mesure vers les réseaux IP et sur le cloud.
Article paru pour la première fois dans Mediakwest #55, p. 118-121
