En tant qu’experte de la téléprésence et de la téléopération robotique, l’équipe Awabot Intelligence emploie la technologie WebRTC depuis de nombreuses années, dans le cadre de projets nécessitant le pilotage de robot à distance avec retour vidéo. Qu’est-ce que le WebRTC ? Comment fonctionne cette technologie open source ? Suivez le guide.
Qu’est-ce que le WebRTC ?
Rappelez-vous, aux prémices du Web, des outils de visioconférence tels que Skype imposaient à leurs utilisateurs de télécharger une application dite “lourde” sur leurs ordinateurs. Petit à petit, les usages ont évolué vers davantage de simplicité : ces mêmes solutions se sont adaptées en se rendant disponibles directement depuis un navigateur web, quasiment “en un clic”, devenant ainsi plus légères pour l’utilisateur. Cette alternative est rendue possible grâce au WebRTC ou “Web Real-Time Communication”.
Cet outil opensource est une interface de programmation permettant une communication temps réel avec transport des flux vidéo et audio dans un environnement web. Elle est aujourd’hui utilisée par des applications de visioconférence notoires telles que Google Meet, Discord et également par des solutions de téléprésence comme, au hasard, BEAM.
Un projet ? Contactez nos experts WebRTC
Comment fonctionne le WebRTC ?
L’arrivée du WebRTC a permis la communication temps réel de flux médias dans le navigateur qui, jusqu’alors, faisait grandement défaut au Web. En effet, auparavant, les possibilités pour diffuser des flux vidéo et audio en temps réel dans un navigateur étaient restreintes. Il existait alors deux possibilités :
- WebSockets, permettant un transport de données bi-directionnel persistant ;
- le flux RTSP, privilégiant un transport vidéo unidirectionnel.
La spécification WebRTC, conforme au World Wide Web Consortium (W3C), s’est donc imposée en tant que solution unifiée. Cette brique logicielle permet tout simplement d’encoder, transporter, décoder et synchroniser des flux vidéo et audio en peer-to-peer, entre deux ordinateurs.
Préparer le contenu média pour son transport grâce au codec
Le codec, contraction de “codeur-décodeur”, permet de représenter un flux de données vidéos de façon optimisée.
Pour rappel, une vidéo n’est autre qu’une succession d’images fixes, ayant un certain débit, généralement exprimé en images par seconde. À l’inverse d’un flux vidéo brut dont l’intégralité de chaque frame – chaque pixel – est enregistrée, un flux vidéo “encodé” ne contient quant à lui que les parties “utiles”.
La plupart des codecs actuels fonctionnent de la même manière : une première frame complète est envoyée, puis les “n” prochaines frames ne contiendront que les différences par rapport à la frame précédente.
Exemple : imaginez une vidéo faisant figurer un point blanc qui se déplace sur un fond noir. D’une frame à l’autre, la majorité du contenu de la frame ne change pas. Seul un pixel passe de blanc à noir et inversement. Le but est donc de n’enregistrer que cette faible variation au lieu de l’intégralité de la frame.
Pour résumer, un codec vise à représenter les informations contenues dans un flux en les optimisant, quitte à réduire la qualité vidéo si cela est nécessaire pour son stockage ou bien dans notre cas, pour son transport.
Favoriser la communication en temps réel et en “Peer-to-Peer”
La problématique de la communication temps réel sur Internet réside en partie dans le fait d’identifier deux individus sur le réseau, puis de les mettre en relation de la façon la plus efficace possible, sans passer par un serveur intermédiaire : en Peer-to-Peer (P2P).
Le NAT (Network Address Translation) est un processus de mise en correspondance d’adresses IP publiques / privées qui peut être implémenté au sein des routeurs. Le but est de faire en sorte que plusieurs ordinateurs connectés à un réseau local, ayant des adresses IP privées, puissent communiquer vers l’extérieur, c’est-à-dire, utiliser Internet.
Lors de l’utilisation de certains protocoles, il est possible d’utiliser le mécanisme du NAT pour établir une communication P2P entre deux ordinateurs distants. Le principe est d’utiliser la configuration établie par le NAT pour une communication sortante et d’envoyer des données “de force” (hole punching) afin qu’elle fasse office de canal de communication entrant.
Toutefois, il faut que le correspondant distant dispose d’un certain nombre d’informations nécessaires et utiles à la mise en place du hole punching. C’est là qu’intervient le serveur STUN (Session Traversal Utilities for NAT), dont le rôle est de fournir ces informations, telles que l’adresse IP publique, le type de NAT utilisé, le port de sortie utilisé, etc… Le but va donc être de transmettre ces informations au correspondant distant, grâce à l’intervention du signaling.
Dans le développement d’applications utilisant le WebRTC, le signaling est la partie “libre” en termes d’implémentation. Ainsi, c’est au développeur d’intégrer sa propre solution, permettant d’échanger différentes informations.
Deux types d’informations doivent être échangées :
- le SDP (Session Description protocol), décrivant la configuration en termes de flux média, servant d’invitation (et de réponse à une invitation) entre les deux “clients WebRTC” ;
- les ICE Candidates, contenant notamment les informations recueillies auprès du serveur STUN.
Chronologiquement, les SDP vont être échangés (invitation et réponse), puis une multitude de ICE Candidates vont être communiqués pour tenter de se mettre d’accord et d’établir la communication P2P. Si cette deuxième étape échoue, c’est un serveur TURN (Traversal Using Relays around NAT) qui prendra alors le relais : les flux transiteront par ce dernier.
Un projet ? Contactez nos experts WebRTC
Autres fonctionnalités de la technologie WebRTC
- Il est également possible, à partir du moment où la communication entre les deux “peers” est établie (P2Pou TURN), d’ouvrir ce que l’on appelle un data channel.
Il s’agit ici d’un canal dédié au transport de données quelconques comme les commandes de pilotage des roues d’un robot à distance, par exemple.
- WebRTC dispose également d’un système permettant de faire face aux variations dans le temps des conditions réseaux et ainsi, d’adapter la quantité de données échangées, en particulier sur les flux audio et vidéo. C’est pourquoi il intègre lui-même la partie encodage/décodage de vidéo.
Par exemple, la variation dans le temps du débit de données vidéo est perceptible dans le logiciel de pilotage BEAM : la qualité de la vidéo peut être légèrement inférieure lorsque le robot est en mouvement, et s’améliorer lorsque le robot s’arrête. Cela est dû à la configuration des codecs : le mouvement contient davantage d’informations que l’absence de mouvement.
- Une autre particularité de WebRTC est que cette brique permet de synchroniser dans le temps l’affichage et la diffusion des différents flux média.
Par exemple, dans le cas de l’utilisation d’un robot de téléprésence, il est préférable que la caméra du haut et la caméra du bas soient synchronisées sur l’interface de pilotage. Dans le cas contraire, l’utilisateur aurait l’impression que la tête bouge sans la base ou inversement. Il en est de même pour le son, notamment pour la synchronisation labiale, qui permet d’avoir un rendu réaliste lorsqu’une personne parle.
Vous avez un projet lié à la technologie WebRTC ? Dotée de savoir-faire et compétences complémentaires couvrant l’ensemble des problématiques liées à la robotique de service, l’équipe Awabot Intelligence vous accompagne. Contactez-nous dès maintenant.
