Réponse directe
Définissez un objectif de latence, mesurez chaque étape et supprimez les files d'attente évitables tout en préservant une protection suffisante contre la gigue pour le réseau réel. Commencez par la caméra GOP et la mise en mémoire tampon de l'encodeur avant de blâmer WebRTC.
Pourquoi cela arrive
Un protocole à faible latence ne peut pas effacer le retard déjà créé par l'encodeur de la caméra, le transcodeur ou un tampon de lecteur surdimensionné. Chaque file d’attente peut également échanger sa résilience contre de la vitesse.
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é
Utilisez une source de temps visible ou une méthode d'horodatage synchronisé pour comparer la capture et l'affichage dans des conditions de réseau normales et dégradées.
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 |
|---|---|---|
| Caméra | Mesurez le comportement de l’encodeur et des images clés. | Le retard de la source est connu. |
| Porte | Identifiez le temps de décodage, de transcodage et d’attente. | Les coûts de transfert et de conversion sont séparés. |
| Réseau | Mesurez le RTT, la perte et la gigue sur le chemin cible. | Le tampon de gigue est dimensionné à partir de preuves. |
| Navigateur | Mesurez le délai de rendu et la récupération après une perte. | L'expérience répond à l'objectif affiché. |
Des preuves à conserver
Publiez un tableau du budget de latence, et non un seul chiffre idéal. Incluez l’appareil, le codec, l’état du réseau et la méthode de mesure.
Note de délimitation et de sécurité
Réduire chaque tampon à zéro peut créer des blocages et des artefacts ; la cible est une latence limitée avec une résilience acceptable.
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
WebRTC garantit-il une latence inférieure à la seconde ?
Non. L'encodeur de la caméra, la passerelle et le réseau peuvent consommer le budget avant que le navigateur reçoive le média.
Que dois-je régler en premier ?
Mesurez les files d'attente de la caméra GOP et de la passerelle avant de réduire le tampon de gigue du navigateur.
Le relais peut-il réduire les délais ?
Oui, lorsque le navigateur prend en charge le codec source et la mise en paquets, car le transcodage peut être évité.
Références principales
- IETF RFC 7826 — Protocole de diffusion en temps réel 2.0
- W3C — Spécification WebRTC 1.0
- FFmpeg — RTSP options et exemples de protocole
- IETF RFC 5905 — Protocole de temps réseau version 4
Guide SmartRTSP associé
Ouvrir le guide associéRéduisez le délai de bout en bout dans l’encodage de la caméra, l’ingestion, la passerelle, le réseau, la gigue et le décodage du navigateur au lieu de régler aveuglément un tampon.