Guide RTSP : Caméras IP, Encodeurs et NVR vers N'importe Quelle Destination

Le Problème des Flux de Caméras IP

Les caméras IP, NVR et encodeurs matériels parlent tous RTSP. C’est le protocole universel de la vidéosurveillance et de la vidéo on-premise — chaque appareil Hikvision, Dahua, Axis, Reolink, Amcrest et Bosch expose des flux RTSP.

Mais RTSP a été conçu pour la lecture en réseau local, pas pour la diffusion en direct. Quand vous devez pousser ces flux caméra vers YouTube, Facebook, un CDN ou une équipe de production distante, RTSP seul ne suffit pas.

OBS gère ça très bien quand un opérateur mixe les caméras en direct — scènes, overlays, transitions. Mais si vous avez juste besoin d’un pipeline fiable “caméras en entrée, multistream en sortie” qui tourne 24/7 sans personne devant, OBS fait plus que nécessaire et moins que souhaité : reconnexion basique uniquement (pas de logique de retry configurable), pas de monitoring par caméra, pas de failover si un flux tombe.

Qu’est-ce que RTSP ?

RTSP (Real Time Streaming Protocol) est un protocole en mode pull. La caméra fait tourner un serveur, et les clients s’y connectent pour recevoir le flux vidéo. C’est l’inverse de protocoles comme SRT ou RTMP où l’encodeur pousse vers un serveur.

Caractéristiques principales :

Puisque la caméra est le serveur, le client doit pouvoir l’atteindre. Sur un réseau local, c’est simple. Par internet, il faut du port forwarding — et c’est là que ça se complique.

Appareils qui Utilisent RTSP

Caméras IP (surveillance et broadcast)

Toute caméra IP moderne expose au moins un flux RTSP, souvent deux (flux principal en haute résolution, sous-flux en basse résolution pour la prévisualisation) :

NVR et DVR

Les enregistreurs vidéo réseau exposent chaque caméra connectée comme un canal RTSP séparé. Si vous avez 4 caméras sur un NVR Hikvision, vous obtenez 4 URLs RTSP — même IP, chemins de canaux différents :

rtsp://admin:[email protected]:554/Streaming/Channels/101  (cam 1)
rtsp://admin:[email protected]:554/Streaming/Channels/201  (cam 2)
rtsp://admin:[email protected]:554/Streaming/Channels/301  (cam 3)
rtsp://admin:[email protected]:554/Streaming/Channels/401  (cam 4)

Encodeurs Matériels

Les encodeurs professionnels comme Teradek, Matrox Monarch et Kiloview exposent aussi le RTSP pour le monitoring local et l’enregistrement. Certaines caméras PTZ utilisées en production live (comme PTZOptics, BirdDog) exposent le RTSP en plus du NDI.

Encodeurs Logiciels

OBS, vMix et Wirecast peuvent exposer des sorties RTSP via des plugins ou des serveurs intégrés. Moins courant, mais utile pour récupérer le flux d’une station de production distante.

Le Problème du NAT

La plus grande faiblesse du RTSP pour les workflows distants, c’est la traversée NAT. Puisque la caméra est le serveur, le client doit l’atteindre. Sur le même réseau local, pas de problème. Par internet :

Scénario 1 — Même LAN (facile) :

Caméra (192.168.1.10:554)  ←── pull RTSP ──  Vajra Cast (192.168.1.50)

Pas de port forwarding. Pas de problème NAT. C’est la configuration recommandée.

Scénario 2 — Distant, une seule caméra (gérable) :

Routeur (IP publique) :554 → 192.168.1.10:554 (caméra)
                                    ↑
                        Vajra Cast (distant) pull depuis IP publique:554

Un port forward par caméra. Expose la caméra sur internet — vérifiez que l’authentification est activée.

Scénario 3 — Distant, plusieurs caméras (galère) :

Routeur :
  :554 → 192.168.1.10:554 (cam 1)
  :555 → 192.168.1.11:554 (cam 2)
  :556 → 192.168.1.12:554 (cam 3)
  :557 → 192.168.1.13:554 (cam 4)

Quatre port forwards avec translation de port. Fragile, difficile à maintenir, et un risque de sécurité — les caméras IP exposées sur internet sont une cible privilégiée pour les botnets (Shodan les indexe en quelques minutes).

La meilleure approche pour le distant : Installer Vajra Cast sur le même LAN que les caméras. Pull RTSP en local, puis push en sortant via SRT ou RTMP. Les connexions sortantes passent le NAT sans port forwarding, et SRT ajoute le chiffrement que RTSP n’a pas.

Comment Vajra Cast Gère le RTSP

Vajra Cast pull les flux RTSP en entrée et les route vers n’importe quel protocole de sortie. L’architecture est simple :

Caméra IP (RTSP) ──pull──> Vajra Cast ──push──> YouTube (RTMP)
Caméra IP (RTSP) ──pull──>      │      ──push──> Facebook (RTMP)
Caméra IP (RTSP) ──pull──>      │      ──push──> CDN (SRT)
Caméra IP (RTSP) ──pull──>      │      ──push──> Lecteur Web (HLS)

Ce Que Vous Obtenez

• Pull RTSP avec authentification — nom d’utilisateur/mot de passe pour l’accès caméra, transport TCP entrelacé pour la fiabilité
• Ingest multi-caméras — chaque caméra est une entrée séparée, surveillée indépendamment
• Conversion de protocoles — RTSP en entrée, SRT/RTMP/HLS/UDP en sortie, pas besoin de scripts FFmpeg
• Multistreaming — un flux caméra vers un nombre illimité de destinations simultanément
• Failover — mixez caméras RTSP avec des sources SRT ou RTMP en chaînes de priorité. Si une caméra tombe, basculement automatique vers une source de secours
• Monitoring — état de santé par entrée, suivi du débit, état de connexion. Sachez instantanément quand une caméra se déconnecte
• Sortie HLS avec lecteur intégré — partagez une URL pour la lecture dans le navigateur, aucun logiciel requis

Configuration dans Vajra Cast

1. Créez une nouvelle route dans l’interface web
2. Ajoutez une entrée RTSP — collez l’URL RTSP de la caméra
3. Entrez les identifiants (nom d’utilisateur/mot de passe) si la caméra requiert une authentification
4. Ajoutez des sorties — RTMP vers YouTube, SRT vers un serveur distant, HLS pour les spectateurs web
5. Démarrez la route

L’interface web affiche un panneau d’aide avec les formats d’URL RTSP courants par fabricant, pour ne pas avoir à deviner la structure du chemin.

Cas d’Usage

Diffusion Multi-Caméras pour Église / Lieu de Culte

Plusieurs caméras PTZ fixes diffusant vers Facebook + YouTube simultanément. Vajra Cast pull depuis chaque caméra, gère le multistream et fournit un lecteur web pour le site de l’église.

Monitoring en Direct de Caméras de Surveillance

Alimentez un lecteur HLS accessible par le web depuis vos caméras de surveillance pour la visualisation distante sans exposer les ports RTSP sur internet. Ajoutez une sortie SRT pour un transport chiffré vers un centre de surveillance distant.

Production d’Événements en Direct

Combinez caméras RTSP (angles fixes) avec des sources SRT (encodeurs mobiles) et des flux SRTLA agrégés dans une seule configuration de routage. Basculement automatique entre les sources si l’une tombe.

Production Distante (REMI)

Installez Vajra Cast sur site, récupérez les flux des caméras locales via RTSP, et poussez vers le site de production distant via SRT. Cela évite d’exposer les caméras sur internet et ajoute le chiffrement et la correction d’erreur que RTSP n’a pas.

Streaming Retail / Restaurant

Un café veut diffuser sa torréfaction en direct. Une caméra IP, pull RTSP, push RTMP vers YouTube. Configurez et oubliez — Vajra Cast se reconnecte automatiquement si la caméra redémarre.

RTSP vs SRT vs RTMP — Quand Utiliser Quoi

Utilisez RTSP quand vous récupérez des flux depuis des caméras ou encodeurs matériels sur votre réseau local.

Utilisez SRT quand vous transportez de la vidéo sur internet — il gère la perte de paquets, chiffre le flux et traverse le NAT en mode caller.

Utilisez RTMP quand vous poussez vers des plateformes (YouTube, Facebook, Twitch) qui l’attendent.

Vajra Cast vous permet de combiner les trois : RTSP en entrée depuis les caméras, SRT pour le transport, RTMP pour la diffusion vers les plateformes. Un seul pipeline, tous les protocoles.

Trouver l’URL RTSP de Votre Caméra

Si vous ne connaissez pas l’URL RTSP de votre caméra :

1. Vérifiez l’interface web de la caméra — généralement sous Réseau > RTSP ou Avancé > Streaming
2. Consultez la documentation du fabricant — cherchez “[marque] [modèle] RTSP URL”
3. Essayez les formats courants — le tableau ci-dessus couvre les principaux fabricants
4. Utilisez un outil de découverte — ONVIF Device Manager peut détecter automatiquement les caméras et leurs URLs RTSP sur votre réseau
5. Testez avec VLC — Ouvrir un flux réseau > collez l’URL RTSP pour vérifier qu’elle fonctionne avant de l’ajouter à Vajra Cast

Dépannage Courant

Avancé : RTSP dans les Chaînes de Failover

Une des forces de Vajra Cast est le mixage de protocoles dans les groupes de failover. Une caméra RTSP peut servir de source principale avec des backups SRT ou RTMP :

Priorité 1 : Caméra RTSP (angle principal)
Priorité 2 : Encodeur SRT (angle de secours)
Priorité 3 : Caméra RTSP (plan large de secours)

Si la caméra principale se déconnecte (problème réseau, coupure de courant, redémarrage), Vajra Cast bascule vers la source suivante disponible en moins de 200 ms. Quand la source principale revient, le retour peut être automatique.

C’est impossible avec du RTSP seul — il n’y a aucune redondance intégrée. Vajra Cast ajoute la couche de failover dont les workflows de surveillance et de broadcast ont besoin.

Résumé

RTSP est partout — dans chaque caméra IP, NVR et la plupart des encodeurs matériels. Il fonctionne parfaitement sur le réseau local mais peine avec la diffusion internet, le chiffrement et la redondance.

Vajra Cast comble ce fossé : pull RTSP en local, conversion vers le protocole que votre destination attend, ajout du failover, et monitoring de tout depuis un seul tableau de bord. Pas de scripts FFmpeg, pas de bidouilles OBS, pas de caméras exposées sur internet.