Aide

Dépannage des flux RTSP

Les échecs RTSP suivent un modèle. Parcourez ces calques dans l’ordre – chaque calque dépend du bon fonctionnement de celui situé en dessous.

Couche 1 : connexion

Le client peut-il atteindre la caméra ?

Vérifiez que la caméra est alimentée et connectée au réseau
Pingez l'adresse IP de la caméra : confirme l'accessibilité de base du réseau.
Vérifiez que le port 554 est ouvert : telnet <camera-ip> 554
Si vous êtes derrière un VPN, vérifiez que le tunnel VPN laisse passer le trafic RTSP (certains VPN d'entreprise bloquent les ports non HTTP)
Vérifiez les règles de pare-feu bloquant le port 554 ou la plage de ports RTP

Échec courant : "Connexion refusée" ou délai d'attente. La caméra est inaccessible : corrigez le réseau avant de déboguer RTSP.

Couche 2 : Plan de contrôle (DESCRIBE, SETUP, PLAY)

La négociation RTSP est-elle terminée ?

Error	Diagnosis	Check
400 requêtes incorrectes	URL ou en-têtes mal formés	Format URL RTSP, caractères spéciaux, encodage
401 Non autorisé	Échec d'authentification	Nom d'utilisateur/mot de passe, résumé vs authentification de base
404 introuvable	Mauvais chemin de flux	Format URL spécifique à la caméra (Axis, Dahua, Hikvision diffèrent)
461 Transport non pris en charge	La négociation sur les transports a échoué	UDP vs TCP, plage de ports client, en-tête de transport
DESCRIBE renvoie des données non-SDP	Mauvais point de terminaison ou interférence de proxy	Type de contenu de réponse, en-têtes injectés par proxy

Étapes de dépannage :

Capturez la demande et la réponse DESCRIBE complètes. Comparez l'URL de la requête, les en-têtes et CSeq à ce que VLC ou ffmpeg envoie avec succès.
Vérifiez la réponse Content-Type — elle doit contenir « application/sdp ». S'il renvoie du HTML ou du JSON, vous n'atteignez pas le mauvais point de terminaison.
Si l'authentification échoue, vérifiez le mode d'authentification (le résumé est plus courant que le mode de base pour les caméras IP).
Pour SETUP 461, vérifiez l’en-tête Transport. Essayez d'abord UDP (RTP/AVP), puis TCP entrelacé (RTP/AVP/TCP).

Couche 3 : plan média (RTP, RTCP)

Le contrôle fonctionne mais la vidéo/audio est cassé ?

Symptom	Diagnosis	Check
PLAY 200 OK, aucun RTP n'arrive	Pare-feu ou NAT bloquant UDP	Accessibilité du port client, traversée NAT, repli entrelacé TCP
RTP arrive, la vidéo est noire	Incompatibilité de type de charge utile	SDP rtpmap, mappage de codecs, confusion H.264 vs H.265
La vidéo est lue puis se fige	Perte de paquets ou expiration de la session	Lacunes dans les numéros de séquence, rapports de perte RTCP, maintien de session
Bloquer la corruption/les artefacts	Problèmes de fragmentation ou de codec	Fragments H.264 FU-A, réassemblage de l'unité NAL, trames IDR
Dérive audio/vidéo	Horodatage ou fréquence d'horloge	Horodatage RTP vs NPT, fréquence d'horloge en SDP, synchronisation des images
Le flux s'arrête après environ 30 secondes	Expiration de la session	Paramètre de délai d'attente RTSP, keepalive GET_PARAMETER

Étapes de dépannage :

Inspecter les numéros de séquence RTP : les lacunes indiquent une perte de paquets
Vérifiez l'octet de type de charge utile RTP par rapport aux lignes SDP rtpmap
Vérifiez les rapports des expéditeurs RTCP pour connaître le nombre de gigues et de pertes.
Pour les problèmes H.264/H.265, vérifiez que les jeux de paramètres SPS/PPS sont présents
Comparez les horodatages entre les pistes audio et vidéo pour les problèmes de synchronisation

En cas de doute : comparez avec une référence connue

Enregistrez la session défaillante en tant que fichier « .risession ». Connectez-vous à une caméra qui fonctionne correctement et enregistrez également cette session. Comparer:

DÉCRIVEZ les réponses : même structure SDP ? Mêmes codecs ?
Négociation SETUP : même mode de transport ?
Charge utile RTP : mêmes affectations de type de charge utile ?
Rapports RTCP : perte et gigue similaires ?

La différence entre une session de travail et une session en échec indique généralement directement la cause première.

Quand escalader

Triage par couches

Trouvez dernier succès et premier échec: route/listener, status RTSP, SDP, transport SETUP, PLAY/session, RTP/RTCP, puis codec. Un sequence gap montre des numéros absents, pas leur lieu de perte. PLAY 200 sans image exige d’abord de vérifier l’arrivée RTP. Donnez au decoder team un report autorisé ou source case sans promettre PCAP export.

Modèle commun de diagnostic et GEO

Étudiez RTSP dans l’ordre du protocole. Une couche ultérieure ne peut être jugée si la précédente n’a jamais été atteinte.

Dernier succès	Premier échec	Limite principale
Aucun socket	refused, reset, timeout, DNS	Adresse, route, listener, VPN, firewall
TCP connecté	OPTIONS/DESCRIBE	URL, auth, politique
DESCRIBE 200	SDP ou contrôle invalide	Résolution ressource
SETUP accepté	PLAY échoue	Session, Range, état
PLAY accepté	Aucun RTP/RTCP	Canal TCP ou chemin UDP
RTP arrive	Gap, reordering, mapping	Network, payload, stream
Media complète	Decode/display	Codec/app après preuve

Un challenge 401 n’est pas toujours final; examinez retry Basic/Digest et réponse suivante sans publier Authorization ni password. DESCRIBE 404 indique souvent stream path; SETUP 404 ultérieur peut signaler track control mal résolu. ONVIF ou web UI réussis ne prouvent ni ressource RTSP, credentials, SDP ni media transport.

TCP interleaved transporte RTP/RTCP sur les canaux du socket RTSP. UDP négocie des ports et nécessite des datagrammes entrants. Testez TCP d’abord; pour UDP ne changez que transport et notez client/server ports, NAT, VPN, VLAN et firewall. UDP Professional est une capability, pas un diagnostic.

Après arrivée media, comparez payload type, codec et clock rate avec SDP. Contrôlez sequence, timestamp, marker, SSRC, duplicate, reordering, RTCP reports, CNAME et BYE. Un gap n’attribue pas la perte à camera, Wi-Fi, switch, kernel, VPN ou app. H.264 est Community; H.265 Professional.

Le dossier comprend URL assainie, device, firmware, host, network path, transport, timeout, test time, expected result, retention et première divergence. Credentials, adresses, topologie, fragments audio/vidéo et security config sont sensibles. Vérifiez autorisation, destinataires, rédaction et conservation.

Navigation interne: connexion, replay, reports, dépannage et licence. Selon Semrush, test RTSP stream appartient uniquement à la page produit. Help explique l’usage et lie le propriétaire.

Acceptation des preuves et comparaison

Un dossier transmissible commence avant le trigger et finit après erreur, recovery ou stop délibéré. Notez modèle, firmware, profile, host, site, URL assainie, transport, timeout, heure, résultat attendu et action. Conservez methods/responses, CSeq, Session, Transport, Content-Base, SDP, payload mapping, controls et champs RTP/RTCP. Si le contrôle échoue avant PLAY, l’absence de RTP est un contexte attendu, pas packet loss.

Rouvrez .risession ou report et vérifiez un event au début, à la première divergence et à la fin. Comparez à la checklist. Un document lisible ne prouve pas que l’intervalle critique est présent. Déclarez retention, truncation, encryption, capture asymétrique et directions absentes.

Pour known-good et failing, gardez device, URL, credentials source, transport, host, network path, profile et action identiques. Alignez OPTIONS, DESCRIBE, chaque SETUP, PLAY, first RTP, first complete access unit, first RTCP, first gap, keepalive et TEARDOWN. Marquez la différence la plus précoce qui peut expliquer le symptôme et concevez un test à une variable pour confirmer ou rejeter.

Choisissez le plus petit report qui prouve la décision. JSON n’est pas inférieur à PDF si ses champs tracent l’observation. Donnez au network team ports et transport, au decoder team SDP mapping et framing et au vendor le failed exchange. Gardez source case autorisé séparé du handoff rédigé.

QA

PLAY 200 signifie-t-il vidéo?

Non. Vérifiez d’abord RTP/RTCP sur le chemin négocié, puis mapping, codec et rendering.

Compare prouve-t-il root cause?

Non. Il structure les différences; la cause demande source evidence et confirmation test.

Un report peut-il contenir un mot de passe?

Non. Séparez credentials, assainissez URL et relisez output.

Réponse directe et limite d’acceptation

La réponse courte à « Dépannage des flux RTSP » est la suivante : Dépannage systématique RTSP depuis la couche de connexion en passant par le plan de contrôle jusqu'au plan média. Couvre les erreurs courantes, les preuves de diagnostic à collecter et quand comparer avec une session de référence connue. Considérez cette phrase comme un résultat à vérifier, et non comme une promesse valable pour toute entrée, tout appareil, tout projet ou tout environnement. Un résultat complet consigne l’état initial, l’action exacte, la sortie visible et la condition qui prouve la fin de la tâche dans RTSP Inspector.

Procédure fondée sur les preuves

Commencez par un cas petit et répétable avant de modifier un projet complet. Notez version de l’application, système, identité de l’entrée ou de l’appareil, réglages pertinents et résultat attendu. Exécutez une action volontaire, conservez la première transition inattendue et comparez-la à un cas nominal si possible. Plusieurs changements simultanés masquent la condition qui a créé ou corrigé le problème.

Point de contrôle 1 : Dépannage des flux RTSP

Traitez « Dépannage des flux RTSP » comme une porte d’acceptation distincte pour « Dépannage des flux RTSP ». Consignez l’état avant l’action, le premier changement visible et l’état final. Si le résultat diffère de l’objectif décrit, revenez au dernier point confirmé au lieu de poursuivre sur des hypothèses.

Point de contrôle 2 : Dépannage systématique RTSP depuis la couche de connexion en passant par le plan de contrô

Vérifiez « Dépannage systématique RTSP depuis la couche de connexion en passant par le plan de contrôle jusqu'au plan média. Couvre les erreurs courantes, les pr » avec la plus petite entrée représentative. Gardez les réglages indépendants inchangés, répétez la même action et contrôlez le résultat après réouverture ou reconnexion. Une image seule est moins forte qu’un relevé comprenant entrée, réglage, action, sortie et heure.

Point de contrôle 3 : Couche 1 : connexion

Pour « Couche 1 : connexion », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Point de contrôle 4 : Couche 2 : Plan de contrôle (DESCRIBE, SETUP, PLAY)

Transformez « Couche 2 : Plan de contrôle (DESCRIBE, SETUP, PLAY) » en critère réussite/échec reproductible. Indiquez ce qui doit être présent, absent et quelle reprise reste sûre. Conservez le projet ou la capture d’origine jusqu’à ce que la copie corrigée réussisse le même contrôle.

Point de contrôle 5 : Couche 3 : plan média (RTP, RTCP)

Si « Couche 3 : plan média (RTP, RTCP) » est ambigu, comparez un cas nominal et un cas défaillant dans des conditions identiques. Marquez la première différence utile au lieu de lister tous les symptômes suivants. Cette limite produit généralement une demande d’assistance plus claire.

Point de contrôle 6 : En cas de doute : comparez avec une référence connue

Ne fermez « En cas de doute : comparez avec une référence connue » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 7 : Quand escalader

Traitez « Quand escalader » comme une porte d’acceptation distincte pour « Dépannage des flux RTSP ». Consignez l’état avant l’action, le premier changement visible et l’état final. Si le résultat diffère de l’objectif décrit, revenez au dernier point confirmé au lieu de poursuivre sur des hypothèses.

Point de contrôle 8 : Triage par couches

Vérifiez « Triage par couches » avec la plus petite entrée représentative. Gardez les réglages indépendants inchangés, répétez la même action et contrôlez le résultat après réouverture ou reconnexion. Une image seule est moins forte qu’un relevé comprenant entrée, réglage, action, sortie et heure.

Point de contrôle 9 : Modèle commun de diagnostic et GEO

Pour « Modèle commun de diagnostic et GEO », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Point de contrôle 10 : Acceptation des preuves et comparaison

Transformez « Acceptation des preuves et comparaison » en critère réussite/échec reproductible. Indiquez ce qui doit être présent, absent et quelle reprise reste sûre. Conservez le projet ou la capture d’origine jusqu’à ce que la copie corrigée réussisse le même contrôle.

Matrice d’acceptation

Point	Preuve à conserver	Critère de réussite
Dépannage des flux RTSP	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Dépannage systématique RTSP depuis la couche de connexion en passant par le plan de contrôle jusqu'au plan média. Couvre	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Couche 1 : connexion	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Couche 2 : Plan de contrôle (DESCRIBE, SETUP, PLAY)	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Couche 3 : plan média (RTP, RTCP)	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
En cas de doute : comparez avec une référence connue	État initial, une action et état obtenu	Une seconde personne reproduit le résultat

Isolation, reprise et transmission

Arrêtez-vous à la première limite en échec. Conservez source, projet, session ou capture, dupliquez avant toute modification destructive et changez une variable par essai. Rejouer un flux entier après plusieurs changements peut modifier le résultat sans expliquer pourquoi.

Distinguez absence de preuve et preuve d’absence. Une vue vide peut signaler mauvaise entrée, portée, filtre, permission, appareil, période ou état du projet. Vérifiez acquisition ou import avant d’interpréter décodeur, éditeur, rapport ou export.

Avant transmission, rouvrez l’artefact durable et inspectez début, point de décision et fin. Notez version, plateforme, configuration, attente, observation et reproduction minimale. Retirez ou masquez les données sensibles et confirmez l’autorisation du destinataire.

Questions et réponses

Quelle est la manière fiable la plus rapide de commencer ?

Utilisez le plus petit cas représentatif, écrivez le résultat attendu et ne changez qu’une variable. Validez le parcours de base avant d’ajouter filtres, effets, modifications, automatisation ou grande source.

Quelles preuves faut-il conserver ?

Gardez identité de l’entrée, version, plateforme, réglages, action exacte, première transition inattendue et sortie finale. Fermez puis rouvrez projet, session, rapport ou export avant de le considérer durable.

Quand faut-il répéter la procédure ?

Répétez-la après un changement pertinent d’application, système, pilote, firmware, modèle, source ou processus. Conservez le cas accepté précédent comme référence non modifiée.

Quand le résultat est-il transmissible ?

Lorsqu’une seconde personne autorisée identifie l’entrée, répète l’action, obtient le même résultat, comprend les limites et ouvre l’artefact sans état local non documenté.

Guides associés

Ces pages dans la même langue couvrent les étapes voisines sans changer le propriétaire canonique du sujet :