Les solutions de streaming grand public privilégient généralement la fluidité et la robustesse plutôt que la réactivité.

• YouTube Live : souvent plusieurs secondes de latence.
• Streaming TV/IPTV : plusieurs secondes à plusieurs dizaines de secondes.
• Visioconférence : généralement quelques centaines de millisecondes.

Dans notre cas, l’objectif est de maintenir une latence inférieure à 250 ms afin de conserver une cohérence visuelle avec les données industrielles affichées en temps réel.

Pourquoi utiliser MediaMTX et WebRTC ?

Le problème du flux RTSP, c’est qu’il se lit très bien sur des logiciels comme VLC ou FFPLAY, mais il ne peut pas s’afficher directement dans un navigateur web classique.

Pour contourner ce blocage, nous utilisons MediaMTX. Ce serveur multimédia sert de traducteur, il récupère le flux RTSP de la caméra et le convertit dans un format adapté au web.

Pour cette expérimentation, nous diffusons la vidéo via WebRTC. C’est LA technologie de référence pour transmettre de la vidéo en temps réel et l’afficher directement dans un navigateur web avec un délai réduit au maximum.

En résumé, voici le rôle de chaque élément :

• La caméra IP capture et compresse la vidéo.

• RTSP permet d’accéder au flux fourni par la caméra.

• MediaMTX sert de passerelle entre la caméra et le navigateur.

• WebRTC affiche la vidéo dans le navigateur avec une faible latence.

Matériel nécessaire

La bonne nouvelle, c’est que cette mise en œuvre demande assez peu d’équipement. Pour reproduire cette configuration, il vous faudra :

• Une caméra IP compatible RTSP.

• Un injecteur PoE adapté à votre modèle de caméra.

• Deux câbles réseau RJ45.

• Un ordinateur sous Linux disposant d’un port Ethernet.

• Un navigateur web standard.

Les 4 étapes de l’expérimentation

Pour mettre en place notre flux vidéo à faible latence, nous allons procéder en quatre grandes étapes :

1. Raccorder la caméra au poste Linux dans un réseau isolé.

2. Identifier l’adresse IP de la caméra et vérifier son flux RTSP.

3. Installer et configurer MediaMTX.

4. Ouvrir le flux WebRTC dans un navigateur pour enfin mesurer sa latence.

1. Raccordement et recherche de la caméra

L’intérêt d’un branchement en réseau isolé

Lors d’une première mise en service, on ne connaît pas toujours l’adresse IP par défaut de la caméra.
Pour faciliter sa détection et éviter de se heurter aux règles de sécurité du réseau de l’entreprise, la meilleure méthode consiste à relier directement la caméra au poste Linux via l’injecteur PoE.

Le schéma de branchement est le suivant :

À ce stade, la caméra et l’ordinateur sont physiquement connectés, mais ils ne peuvent pas encore communiquer.
Pour que le dialogue s’établisse, leurs adresses IP doivent impérativement appartenir au même sous-réseau.

2.Identifier l’interface Ethernet sous Linux

Avant de partir à la recherche de la caméra sur le réseau, nous devons d’abord identifier le nom de la carte réseau (l’interface Ethernet) de votre ordinateur.

Ouvrez un terminal et exécutez la commande suivante :

$ ip link show

Selon votre matériel et la distribution Linux que vous utilisez, le nom de cette interface peut varier. Vous rencontrerez généralement des appellations comme :

• enp0s31f6

• enp2s0

• eth0

Pour la suite de cet article, nous utiliserons enp0s31f6 comme exemple de référence.

Écouter les premières communications de la caméra

Au démarrage, une caméra IP émet généralement différentes trames sur le réseau pour chercher d’autres équipements ou simplement annoncer sa présence. C’est précisément ce « bavardage » qui va nous permettre de découvrir son adresse IP.

Sous Linux, nous allons utiliser l’outil tcpdump. Il s’agit d’un renifleur de paquets qui permet d’écouter les communications passant par notre carte réseau.

Lancez la commande suivante en gardant à l’esprit que enp0s31f6est notre interface de test :

$ sudo tcpdump -i enp0s31f6 -n -e 'arp or udp'

Une fois la commande lancée, le terminal écoute en continu.

L’astuce consiste maintenant à forcer la caméra à s’exprimer, coupez l’alimentation de l’injecteur PoE, patientez quelques secondes, puis remettez-le sous tension.

Lors du redémarrage de la caméra, de nouvelles requêtes vont apparaître dans votre terminal. Vous devriez repérer une ligne qui ressemble à ceci :

ARP, Request who-has 10.120.163.1 tell 10.120.163.115

Dans cet exemple, 10.120.163.115 est très probablement l’adresse IP de la caméra.

L’astuce gain de temps : Il se peut que vous n’ayez pas du tout à faire cette manipulation. Pensez à vérifier la documentation officielle de votre caméra IP, l’adresse IP par défaut y est très souvent indiquée !

Que signifie ARP ?

Address Resolution Protocol est un mécanisme réseau utilisé par les équipements d’un réseau local. Son rôle est simple, il permet de retrouver l’adresse physique (l’adresse MAC) qui correspond à une adresse IP donnée.

Placer l’ordinateur dans le même réseau

Maintenant que nous avons démasqué l’adresse de la caméra (dans notre exemple, la 10.120.163.115), notre ordinateur doit s’adapter.
Pour qu’ils puissent discuter ensemble, l’ordinateur doit être configuré avec une adresse IP appartenant au même sous-réseau.

Voici à quoi doit ressembler votre configuration :

Équipement	Adresse IPv4	Masque de sous-réseau
Caméra IP	10.120.163.115	/24 (ou 255.255.255.0)
Ordinateur	10.120.163.116	/24 (ou 255.255.255.0)

Remarquez que les trois premiers groupes de chiffres sont identiques. Seul le dernier groupe permet de différencier les appareils.
L’adresse de l’ordinateur doit obligatoirement être différente de celle de la caméra, sous peine de créer un conflit réseau qui bloquerait toute communication.

Pour attribuer cette nouvelle adresse de manière temporaire à votre poste Linux, utilisez ces commandes en adaptant toujours le nom de l’interface à votre cas.

$ sudo ip address add 10.120.163.116/24 dev enp0s31f6
$ sudo ip link set enp0s31f6 up

Tester la connexion

Tout est branché et configuré. Vérifions que le courant passe ! Vous pouvez tester la connexion avec un simple « ping » vers l’adresse de la caméra :

$ ping 10.120.163.115

Si tout fonctionne correctement, la caméra devrait vous répondre. Le résultat attendu ressemblera à ceci :

64 bytes from 10.120.163.115: icmp_seq=1 ttl=64 time=0.5 ms

L’interface web de la caméra

Si le ping ne donne rien, pas de panique ! Passez directement au test via votre navigateur web.

Tapez l’adresse de la caméra dans la barre de recherche : http://10.120.163.115 ou https://10.120.163.115.

Vous devriez arriver sur la page d’accueil de la caméra. Connectez-vous avec les identifiants administrateur généralement fournis dans la documentation.
Cette interface web est votre centre de contrôle, elle vous permettra d’ajuster les réglages vidéo et surtout, de récupérer la fameuse URL RTSP dont nous aurons besoin à l’étape suivante.

Règle de sécurité incontournable : Le mot de passe par défaut de la caméra doit impérativement être remplacé avant son intégration définitive sur votre réseau de production.

Vérifier l’affichage du flux RTSP

En règle générale, l’URL RTSP générée par votre caméra se présente sous ce format : rtsp://utilisateur:mot-de-passe@adresse-ip:port/chemin-du-flux

Pour visionner ce flux directement, vous pouvez utiliser des lecteurs multimédias classiques comme VLC ou FFplay.

Pourquoi faire ce test ?

Avant d’ajouter notre passerelle WebRTC, il est indispensable de vérifier que la caméra diffuse correctement son flux de base.
Si ça bloque ici, rien ne sert d’aller plus loin !

Sous Linux, le lecteur FFplay qui est fourni avec la suite FFmpeg permet d’effectuer ce test très rapidement.
Ouvrez votre terminal et lancez cette commande :

$ ffplay -rtsp_transport tcp 'rtsp://utilisateur:mot-de-passe@adresse-ip:port/chemin-du-flux'

Pourquoi TCP ?

Pour ce tout premier test qui consiste uniquement à récupérer les images, nous forçons l’utilisation du protocole de communication TCP.
TCP privilégie la fiabilité de la transmission, lorsqu’une donnée est perdue, elle est retransmise.
Cette vérification constante peut ajouter un léger délai, mais elle garantit l’intégrité du flux, ce qui facilite grandement le premier test

Détail technique : Les guillemets simples ('...') entourant l’adresse RTSP sont très importants.
Sans eux, si votre URL contient un caractère &, le terminal Linux l’interprétera comme une commande de séparation et l’affichage échouera.

Après avoir validé la commande, une fenêtre FFplay doit s’ouvrir sur votre écran et afficher l’image de la caméra en direct.
Si l’image est correctement affichée, la chaîne suivante est validée :

3.Afficher le flux dans un navigateur avec MediaMTX

Petit rappel : à quoi sert MediaMTX ?

Comme nous l’avons vu, le flux RTSP de la caméra se lit très bien sur VLC ou FFPLAY, mais il est incapable de s’afficher nativement dans un navigateur web. C’est là qu’intervient MediaMTX.

Il s’agit d’un serveur multimédia ultra-léger qui va jouer le rôle de traducteur ou passerelle.
Il récupère le flux RTSP de la caméra, et le convertit à la volée en WebRTC, un format parfaitement compris par les navigateurs.
Gros avantage, MediaMTX est un exécutable autonome, il ne nécessite aucune installation lourde ou environnement complexe sur votre machine !

Installation et configuration de MediaMTX

Avant de télécharger le logiciel, nous devons vérifier l’architecture de votre processeur. Dans votre terminal, tapez :

$ uname -m

Les résultats les plus courants sont x86_64 pour les PC classiques ou aarch64 pour les architectures ARM, comme les Raspberry Pi.
Rendez-vous ensuite sur le site officiel  de MediaMTX et téléchargez l’archive correspondant à votre architecture matérielle.

Extraction et préparation des fichiers

Une fois l’archive téléchargée, nous allons lui créer un espace dédié.
Exécutez les commandes suivantes pour créer un dossier et vous y rendre :

$ mkdir -p "$HOME/mediamtx"
$ cd "$HOME/mediamtx"

Déplacez l’archive que vous venez de télécharger dans ce nouveau dossier, puis extrayez-la (adaptez le nom du fichier selon la version téléchargée) :

$ tar -xzf mediamtx_*_linux_amd64.tar.gz

Vérifiez que tout s’est bien passé en listant le contenu du dossier avec la commande ls -la.
Vous devriez y trouver trois fichiers importants : mediamtx, mediamtx.yml et LICENSE.

Pour que le programme puisse fonctionner, nous devons lui donner les droits d’exécution :

$ chmod +x mediamtx

Avant de modifier le fichier de configuration mediamtx.yml, il est fortement recommandé d’en faire une copie.
Cela vous permettra de revenir facilement à la configuration initiale en cas d’erreur de frappe :

$ cp mediamtx.yml mediamtx.yml.original

Configurer les flux vidéo dans MediaMTX

Le cœur du système se trouve dans le fichier mediamtx.yml.
C’est lui qui définit les paramètres globaux et liste les flux que le serveur doit gérer.

Pour l’éditer, vous pouvez utiliser votre éditeur de texte graphique habituel, ou bien l’ouvrir directement dans le terminal avec nano :

$ nano mediamtx.yml

Une configuration de base pour notre caméra ressemblera à ceci :

Pourquoi forcer l’UDP ?

Dans cette configuration, le paramètre rtspTransport: udp est crucial, il force MediaMTX à récupérer le flux RTSP de la caméra en utilisant le protocole UDP.

Rappelez-vous lors de notre premier test, nous avions utilisé TCP pour garantir que l’image arrivait bien.
Ici, nous faisons l’inverse, l’UDP ne demande pas la retransmission automatique d’un paquet de données s’il se perd en route.
Cette absence de vérification évite les files d’attente réseau et privilégie au maximum la réactivité.
En contrepartie, si un paquet est perdu, vous verrez une brève dégradation visuelle de l’image, mais le direct ne sera pas retardé.

L’UDP ne fait pas tout : Le protocole UDP évite les délais de retransmission, mais il ne garantit pas à lui seul une faible latence, la latence finale dépend de toute la chaîne : la caméra, le codec, la fréquence d’image, le réseau, MediaMTX, le navigateur et même votre écran !

Par ailleurs, nous utilisons l’UDP ici, car nous sommes dans un réseau isolé, sur un réseau d’entreprise chargé, le TCP pourrait s’avérer être un choix plus stable.

4.Lancement du serveur et affichage WebRTC

Une fois le flux déclaré et le paramètre UDP enregistré, vous pouvez quitter l’éditeur de texte. Il est temps de démarrer MediaMTX avec la commande suivante :

$ ./mediamtx

Le serveur tourne !
Ouvrez maintenant votre navigateur web et saisissez l’adresse suivante dans la barre d’URL en remplaçant par le nom de votre flux défini dans le YAML :

http://localhost:8889/cheminduflux

Après quelques instants de chargement, l’image de la caméra doit apparaître en direct dans votre navigateur.

Ne fermez pas votre terminal : Tant que MediaMTX tourne, le terminal reste ouvert et affiche les journaux du serveur. Ces messages sont très utiles pour suivre son fonctionnement en direct et identifier une éventuelle erreur. Si vous fermez la fenêtre, la vidéo s’arrêtera !

À ce stade, la chaîne complète est fonctionnelle :

Mesurer la latence du flux

Il existe plusieurs méthodes pour mesurer la latence d’un flux vidéo. La méthode la plus simple et la plus visuelle ne demande aucun outil complexe, il suffit de partager votre écran en deux parties.

• D’un côté : ouvrez un chronomètre affichant les centièmes ou les millièmes de seconde.

• De l’autre : placez la fenêtre de votre navigateur affichant le flux vidéo de la caméra.

Orientez la caméra vers votre écran pour qu’elle filme le chronomètre, lancez le compte à rebours, laissez tourner quelques secondes, puis faites une capture d’écran de l’ensemble.

Sur cette image figée, vous ferez apparaître simultanément deux informations :

1. La valeur du chronomètre en temps réel.

2. La valeur du chronomètre visible dans le flux de la caméra .

Il ne vous reste plus qu’à faire une simple soustraction : Latence = [Valeur du chronomètre réel] – [Valeur visible dans le flux vidéo]

Exemple de calcul :

Chronomètre réel : 05,28 s
Chronomètre visible à l’image : 05,05 s

Latence = 05,28 – 05,05
Résultat = 0,23 s

Pour obtenir un résultat vraiment représentatif, ne vous contentez pas d’une seule mesure.
Répétez cette capture d’écran à différents moments du test, cela vous permettra de calculer une latence moyenne et surtout de vérifier si le retard reste stable dans le temps ou s’il se dégrade.

À retenir : La latence que vous venez de mesurer est une latence ‘de bout en bout’. Elle inclut le traitement de toute la chaîne, depuis la capture physique de la lumière par le capteur de la caméra, jusqu’à l’affichage final des pixels dans votre navigateur web, en passant par le réseau et le serveur MediaMTX.

Les résultats : quelle est la latence réelle ?

La méthode du chronomètre n’a pas été utilisée qu’une seule fois, pour s’assurer de la stabilité du système, nous avons effectué des relevés à différents moments.

L’objectif  est de vérifier la latence immédiate, mais aussi s’assurer que le flux ne se désynchronise pas lors d’une utilisation prolongée.

Au total, 35 mesures ont été réalisées avec MediaMTX sur une durée d’environ une heure. Voici les résultats :

Indicateur	Résultat avec MediaMTX
Latence moyenne	198,3 ms
Latence médiane	200 ms
Latence minimale	170 ms
Latence maximale	270 ms

Le constat est très positif, la majorité des mesures se situe autour de 200 ms, soit un cinquième de seconde.
Surtout, aucun accroissement progressif du retard n’a été observé pendant l’heure de fonctionnement. Le flux est parfaitement stable.

Objectif atteint

MediaMTX répond parfaitement à notre besoin initial, il permet de récupérer un flux RTSP, d’imposer le transport UDP pour la rapidité, et de le convertir en WebRTC pour un affichage web ultra-fluide. Le tout avec une architecture simple, légère et robuste pour l’industrie.

 

Conclusion et perspectives

Cette expérimentation nous a permis d’afficher le flux d’une caméra IP en direct dans un navigateur web, en maintenant une latence moyenne très basse, autour de 200 ms.

Vous avez désormais entre les mains une base légère, fiable et facilement reproductible pour vos démonstrations techniques ou vos usages pédagogiques.
C’est l’architecture parfaite pour lier visuellement une opération mécanique aux données remontées en direct sur un tableau de bord.

Bonnes pratiques pour un déploiement réel

Si la connexion directe entre la caméra et le PC est idéale pour se faire la main, notez que nos mesures finales ont été réalisées sur un VLAN dédié. Dans un véritable environnement industriel ou institutionnel, ce déploiement doit impérativement être préparé avec votre service informatique. Il faudra définir ensemble l’adressage IP, le VLAN, les ports autorisés, les règles de pare-feu et les droits d’accès au flux.

Et pour la suite ? L’intégration sur Raspberry Pi

Maintenant que la chaîne logicielle est validée sur un poste Linux classique, la prochaine étape logique est d’installer MediaMTX sur un nano-ordinateur comme le Raspberry Pi.

L’objectif est de rendre la solution beaucoup plus compacte et autonome sur le terrain.
Il faudra bien sûr mener une nouvelle campagne de tests pour vérifier la température du matériel, la stabilité globale et la latence dans cette configuration miniature.