Réponse directe
Traitez le flux RTSP de la caméra comme un protocole d'acquisition et placez une passerelle autorisée entre le réseau de caméras et les clients du navigateur. Choisissez WebRTC pour une latence interactive ou HLS pour une livraison tampon évolutive.
Pourquoi cela arrive
Les piles multimédias des navigateurs modernes n'exposent généralement pas un lecteur RTSP brut. Une passerelle doit gérer l'authentification de la caméra, la compatibilité des codecs, la diffusion de la session et un transport Web natif.
Les navigateurs ont normalement besoin d'une passerelle qui convertit le flux de la caméra en un chemin de diffusion Web natif.
Un test contrôlé
Tracez les limites d'ingestion, de passerelle, de navigateur et d'authentification avant de sélectionner le logiciel.
Modifiez une variable à la fois. Conservez le modèle de caméra, le micrologiciel, le point final et le compte enregistrés ; testez ensuite l'accessibilité du réseau, la réponse du protocole, le transport multimédia et le décodage en tant que couches distinctes.
Utilisez un compte dédié en lecture seule et un outil de diagnostic local fiable. Rédigez les informations d’identification, les adresses privées et les données d’identification avant de partager la sortie.
Séquence diagnostique
| Vérifier | Action | Preuve de progrès |
|---|---|---|
| Latence | Définissez le délai verre à verre maximum. | La cible pointe vers WebRTC, HLS ou un autre mode de livraison. |
| Échelle | Estimez les spectateurs simultanés et la répartition des caméras. | Une caméra n'est pas ouverte une fois par navigateur sans plan. |
| Codec | Faites correspondre la sortie de la caméra à la prise en charge du décodage du navigateur. | Le passthrough ou le transcodage est choisi délibérément. |
| Confiance | Conservez les informations d’identification de la caméra à la passerelle. | Les navigateurs reçoivent un accès limité, pas les mots de passe des caméras. |
Des preuves à conserver
L'enregistrement de l'architecture doit indiquer qui termine RTSP, qui authentifie les spectateurs, si la vidéo est transcodée et où les tampons ajoutent de la latence.
Note de délimitation et de sécurité
Ne placez jamais un RTSP URL privé portant des informations d'identification dans du JavaScript côté client ou dans un lecteur en ligne public.
Pour la visualisation à distance, utilisez un VPN géré au lieu d'exposer RTSP ou les ports d'administration de la caméra directement à l'Internet public.
SmartRTSP
SmartRTSP est une visionneuse RTSP et ONVIF axée sur la caméra pour les appareils Apple, Windows et Android. Il convient aux contrôles de visualisation directe, de découverte et multi-caméras ; conservez un NVR ou VMS dédié lorsqu’un enregistrement continu, une exportation de preuves ou des contrôles d’entreprise centralisés sont requis.
Questions fréquemment posées
Chrome ou Safari peuvent-ils ouvrir rtsp:// directement ?
Ne concevez pas autour de la lecture brute directe de RTSP ; utilisez une passerelle contrôlée et un chemin de livraison Web natif.
Quand dois-je choisir WebRTC ?
Lorsque la visualisation interactive ou opérationnelle nécessite une faible latence et que l’infrastructure de session ajoutée est acceptable.
Quand HLS est-il mieux adapté ?
Lors d'une diffusion large de HTTP, la mise en cache et la tolérance à la latence basée sur les segments comptent plus que l'interactivité.
Références principales
- IETF RFC 7826 — Protocole de diffusion en temps réel 2.0
- W3C — Spécification WebRTC 1.0
- IETF RFC 8216 — HTTP Diffusion en direct
- MDN — Formats de conteneurs multimédia et de codecs sur le Web
Guide SmartRTSP associé
Ouvrir le guide associéChoisissez WebRTC, HLS ou une autre sortie Web native au lieu de vous attendre à ce qu'un navigateur ouvre directement une caméra RTSP URL.