2026-06-20

Flux de travail de dépannage RTSP de la caméra IP: \"de l'URL aux preuves RTP

Les pannes de caméra IP sont souvent mal diagnostiquées car le premier test est un lecteur.

Les pannes de caméra IP sont souvent mal diagnostiquées car le premier test est un lecteur. Un lecteur peut prouver qu'une vidéo apparaît parfois, mais cela explique rarement pourquoi un flux échoue dans un NVR, un pipeline d'analyse, une passerelle de navigateur ou un réseau client. RTSP Inspector est conçu pour le chemin de diagnostic: "contrôle RTSP, déclarations SDP, livraison RTP, synchronisation RTCP et structure H.264/H.265." Utilisez ce hub comme premier flux de travail lorsqu'une caméra se connecte, se bloque, présente des problèmes, échoue uniquement sur UDP ou fonctionne dans un outil mais pas dans un autre.

Le flux de travail

Step	Que prouver	Des preuves à recueillir
1. Confirmez l'URL	Le chemin RTSP est-il réel et accessible ?	OPTIONS, DESCRIPTION, code d'état, CSeq, redirection et chemin de la caméra
2. Résoudre l'authentification	La caméra a-t-elle accepté les informations d'identification et le schéma d'authentification ?	Boucle 401, domaine Digest, occasionnel, solution de secours de base et statut final
3. Lisez SDP avant les médias	La caméra a-t-elle déclaré les pistes et codecs utilisables ?	contrôler les URL, les types de charges utiles, les fréquences d'horloge, les paramètres H.264/H.265, les pistes audio
4. Vérifiez le transport	Le programme d'installation a-t-il négocié TCP, UDP, multidiffusion ou une incompatibilité ?	En-tête de transport, canaux entrelacés, ports client/serveur, NAT, comportement du pare-feu
5. Mesurer les médias	RTP et RTCP ont-ils prouvé une perte, une gigue, une synchronisation ou une défaillance du codec ?	intervalles de séquence, horodatages, bit de marquage, SSRC, rapports d'expéditeur, SPS/PPS, FU-A

Commencez par l'URL et les codes d'état

Si le chemin du flux est erroné, toute théorie médiatique fait perdre du temps. Commencez par Diagnostics d'URL de caméra RTSP 401 et 404, RTSP 400 Bad Request et ONVIF fonctionne mais l'URL RTSP échoue.

L'inspecteur RTSP garde visible l'échange du plan de contrôle : OPTIONS, DESCRIBE, SETUP, PLAY, codes d'état, en-têtes et preuves d'authentification rédigées. C'est la base d'un dossier de support qui en dit plus que "VLC ne l'a pas lu".

Lisez SDP avant de blâmer le décodeur

SDP vous indique si la caméra a déclaré correctement le flux. Utilisez SDP, H.264 et H.265 dans les diagnostics RTSP, manquant H.264 SPS/PPS dans les flux RTSP, et Mode de mise en paquets H.264 RTP 0 vs 1 lorsque la lecture démarre mais que les décodeurs ou les analyses échouent.

Le but est de séparer l’échec des métadonnées de l’échec de la livraison des médias. Une caméra peut s'authentifier et néanmoins publier de mauvais types de charge utile, des paramètres de codec manquants, des URL de contrôle erronées ou des choix H.265 non pris en charge.

Prouver la limite de transport

De nombreux étuis pour appareils photo sont des étuis de transport. Délai d'expiration RTSP : UDP, TCP entrelacé ou chemin réseau, RTSP UDP bloqué par un pare-feu ou NAT, RTSP 461 non pris en charge transport et RTSP sur TCP entrelacé canal incompatibilité couvrent les limites communes.

L'inspecteur RTSP est utile car il ne s'arrête pas à "essayer TCP". Il montre la négociation SETUP, la réponse de transport, la preuve de réception RTP/RTCP et le mappage de canal qui décident si les paquets peuvent arriver.

Mesurer la santé des médias

Une fois le média arrivé, mesurez-le. Perte de paquets RTP dans les flux de caméra, Rapports de l'expéditeur RTCP, gigue et perte de paquets, horodatage RTP drift, et Bit de marqueur RTP et limites de trame H.264 aident à transformer les problèmes visibles en preuves de paquets et de synchronisation.

C'est là que RTSP Inspector diffère d'un joueur. La réponse n’est pas seulement « la vidéo a été gelée ». La réponse est de savoir si les numéros de séquence RTP ont été ignorés, les horodatages ont dérivé, les rapports RTCP se sont arrêtés ou le flux H.264 n'avait pas la structure dont le décodeur avait besoin.

Comparez honnêtement les outils de diagnostic

Utilisez Inspecteur RTSP vs VLC pour le débogage de la caméra lorsque la question est lecture ou diagnostic. Utilisez RTSP Inspector vs ONVIF Device Manager lorsque la découverte fonctionne mais que le chemin du support échoue. Utilisez RTSP Inspector vs Wireshark pour les diagnostics de caméra lorsque l'équipe dispose déjà d'outils d'analyse de paquets.

Pour une large couverture, le Guide de dépannage du flux RTSP et la FAQ sur les diagnostics RTSP rassemblent les questions les plus courantes des équipes de caméras.

Configuration et étape suivante

Utilisez Aide à la connexion de l'inspecteur RTSP pour démarrer une session de diagnostic et Aide au rapport de l'inspecteur RTSP lorsque les preuves doivent quitter l'application. Parcourez l'index du blog RTSP Inspector pour connaître les cas spécifiques de code d'état, de transport, de RTP, de RTCP et de codec.

Preuve reproductible pour « Flux de travail de dépannage RTSP de la caméra IP: "de l'URL aux preuves RTP »

La réponse directe est qu’un écran noir ou un code isolé ne prouve pas l’origine d’une panne de caméra. Un diagnostic fiable relie requête et réponse RTSP, transport négocié, session valide, puis numéros de séquence RTP, horodatages et éléments RTCP. Pour « Flux de travail de dépannage RTSP de la caméra IP: "de l'URL aux preuves RTP », partez de la couche la plus proche du symptôme, tout en conservant une chronologie unique afin de ne pas confondre contrôle, réseau et décodage.

Avant de modifier caméra, pare-feu ou VMS, établissez un test de référence. Notez l’URL RTSP sans mot de passe, l’heure, le chemin, le transport demandé, la réponse du serveur et l’arrivée du premier paquet média. Testez séparément UDP et TCP interleaved si l’équipement les propose. Ne changez pas à la fois chemin, identifiants et transport : un second essai réussi ne dirait pas quelle variable a corrigé l’écart.

Couche	Preuve à conserver	Question de décision
RTSP	méthode, statut, en-têtes, CSeq et Session	Le serveur accepte-t-il précisément l’opération ?
SDP	control, payload type, clock rate et codec	La piste décrite est-elle celle attendue ?
Transport	client_port, server_port ou interleaved	Les deux extrémités utilisent-elles le même canal ?
RTP	SSRC, séquence, timestamp et marker	Les unités arrivent-elles dans un ordre explicable ?
RTCP	sender report, CNAME et BYE	Horloge, identité et fin sont-elles traçables ?
Décodeur	SPS/PPS/VPS et packetization mode	Le payload reçu permet-il l’initialisation ?

Séparez « aucun média reçu » de « média reçu mais indécodable ». L’absence de RTP après SETUP et PLAY réussis dirige vers UDP, NAT, pare-feu ou une réponse Transport différente de l’offre. Des trous de séquence prouvent perte ou réordonnancement. Une séquence continue sans image déplace l’enquête vers payload type, fréquence d’horloge, limites d’image et paramètres H.264 ou H.265. Cette frontière est plus utile qu’un message générique du lecteur.

Comment rédiger une réponse directement réutilisable ?

Écrivez trois phrases : dernière opération réussie, première preuve en échec, prochain test discriminant. Exemple : « DESCRIBE, SETUP et PLAY réussissent ; aucun RTP n’arrive aux ports annoncés ; un essai TCP interleaved séparera blocage UDP et mauvais chemin média. » N’accusez ni caméra ni réseau sans réponse ou paquet qui matérialise cette limite.

Quelles données rendent le cas reproductible ?

Conservez OPTIONS, DESCRIBE, SETUP et PLAY, le SDP, la réponse Transport et l’identifiant Session nettoyé. Pour RTP, relevez SSRC, première et dernière séquence, clock rate, nombre de trous et durée. Mentionnez le résultat dans VLC ou un autre VMS comme test différentiel, pas comme preuve que le client qui fonctionne respecte toutes les frontières.

Quand tester le serveur ou le client ?

Examinez le serveur s’il refuse une méthode, fournit une URL control absente, renvoie un transport incompatible ou change SSRC ou horloge sans transition. Examinez le client s’il réutilise un nonce expiré, perd Session, demande UDP sans ouvrir les ports ou assimile chaque fin de NAL à une fin d’access unit. Entre les deux, paquet et heure doivent accompagner chaque conclusion.

Comment valider le rapport ?

Recommencez avec une connexion neuve et comparez les chronologies jusqu’à la première divergence. Retirez mots de passe et valeurs Authorization complètes. Reliez chaque conclusion à CSeq, séquence ou timestamp. La documentation RTSP associée couvre les étapes voisines ; RTSP Inspector permet de tester un flux RTSP et de collecter localement les preuves sans téléverser la vidéo vers un service public.

Réponse directe et limite d’acceptation

La réponse courte à « Flux de travail de dépannage RTSP de la caméra IP: "de l'URL aux preuves RTP » est la suivante : Les pannes de caméra IP sont souvent mal diagnostiquées car le premier test est un lecteur. 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 : Flux de travail de dépannage RTSP de la caméra IP: "de l'URL aux preuves RTP

Pour « Flux de travail de dépannage RTSP de la caméra IP: "de l'URL aux preuves RTP », 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 2 : Les pannes de caméra IP sont souvent mal diagnostiquées car le premier test est un lecteur

Ne fermez « Les pannes de caméra IP sont souvent mal diagnostiquées car le premier test est un lecteur. » 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 3 : Le flux de travail

Pour « Le flux de travail », 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 : Commencez par l'URL et les codes d'état

Ne fermez « Commencez par l'URL et les codes d'état » 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 5 : Lisez SDP avant de blâmer le décodeur

Pour « Lisez SDP avant de blâmer le décodeur », 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 6 : Prouver la limite de transport

Ne fermez « Prouver la limite de transport » 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 : Mesurer la santé des médias

Pour « Mesurer la santé des médias », 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 8 : Comparez honnêtement les outils de diagnostic

Ne fermez « Comparez honnêtement les outils de diagnostic » 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 9 : Configuration et étape suivante

Pour « Configuration et étape suivante », 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 : Preuve reproductible pour « Flux de travail de dépannage RTSP de la caméra IP: "de l'URL

Ne fermez « Preuve reproductible pour « Flux de travail de dépannage RTSP de la caméra IP: "de l'URL aux preuves RTP » » 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.

Matrice d’acceptation

Point	Preuve à conserver	Critère de réussite
Flux de travail de dépannage RTSP de la caméra IP: "de l'URL aux preuves RTP	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Les pannes de caméra IP sont souvent mal diagnostiquées car le premier test est un lecteur.	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Le flux de travail	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Commencez par l'URL et les codes d'état	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Lisez SDP avant de blâmer le décodeur	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Prouver la limite de transport	É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 :