Réponse directe
Mesurez le temps exact jusqu’à l’échec. Un intervalle cohérent suggère l'expiration de la session, la veille de la batterie ou un délai d'inactivité configuré ; les décrochages variables indiquent plus souvent une perte du Wi-Fi, un encombrement ou une pression du décodeur.
Pourquoi cela arrive
Sans preuve de timing, toutes les déconnexions se ressemblent. L'état de session RTSP, la politique d'alimentation de la caméra et le chemin du support peuvent échouer indépendamment après un démarrage réussi.
Séparez la disponibilité du flux, la description du média, le transport, le décodage et la synchronisation avant de modifier les paramètres de la caméra.
Un test contrôlé
Exécutez un flux pendant au moins deux fois l'intervalle d'échec habituel tout en enregistrant l'accessibilité, les réponses RTSP et les erreurs de paquet ou de décodage.
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 |
|---|---|---|
| Intervalle | Chronométrez trois échecs après un JEU réussi. | Un modèle stable ou variable est établi. |
| Session | Vérifiez le comportement de maintien en vie et les valeurs de délai d'expiration pris en charge. | Le client maintient ou renouvelle correctement la session. |
| Pouvoir | Vérifiez si la caméra ou le hub est en veille sans activité. | Le fonctionnement continu sous tension est confirmé. |
| Réseau | Inspectez le signal Wi-Fi, les compteurs de commutation et les changements d’adresse. | Le chemin reste stable tout au long de la fenêtre de défaillance. |
Des preuves à conserver
Une petite chronologie montrant la connexion, la dernière bonne image, l'erreur RTSP et la tentative de récupération est plus utile qu'une capture d'écran d'une vignette gelée.
Note de délimitation et de sécurité
Ne traitez pas un appareil photo à batterie comme une source RTSP continue à moins que le fabricant ne documente explicitement ce mode.
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
Pourquoi mon flux s'arrête-t-il presque au même moment ?
Un intervalle répétable correspond souvent à un délai d'expiration de session, à une politique d'inactivité ou à une veille de la batterie.
Un téléspectateur doit-il se reconnecter automatiquement ?
Oui, mais avec un recul limité et un état visible afin de ne pas masquer le défaut sous-jacent ni surcharger la caméra.
Une autre application pourrait-elle déconnecter cette visionneuse ?
Certaines caméras limitent les sessions simultanées. Testez donc avec d'autres spectateurs et les connexions NVR sont fermées.
Références principales
- IETF RFC 7826 — Protocole de diffusion en temps réel 2.0
- FFmpeg — RTSP options et exemples de protocole
- SmartRTSP — plateforme officielle et informations sur le produit
Guide SmartRTSP associé
Ouvrir le guide associéUtilisez l'intervalle de défaillance répétable pour identifier les limites de maintien en vie, de veille de la batterie, de Wi-Fi et de sessions simultanées.