2026-06-18

Dépannage du flux RTSP : le guide de diagnostic complet pour les flux de caméra

Flux de travail de diagnostic RTSP complet : couche de connexion, erreurs du plan de contrôle (400/401/404/454/461/500/503), échecs du plan média (H.264/H.265/RTP/RTCP), gestion de session et comparaison avec Wireshark/VLC. Chaque problème RTSP est mappé sur une page de diagnostic.

Il s'agit de la page centrale pour les diagnostics du flux de caméra RTSP. Chaque problème RTSP suit un modèle: "il échoue au niveau de la couche de connexion, du plan de contrôle ou du plan média. Ce guide mappe chaque défaillance courante sur une page de diagnostic spécifique et vous indique les preuves à collecter."

Triage rapide: "où est l’échec ?"

Avant de lire une page spécifique, déterminez quelle couche échoue: ""

Le client peut-il atteindre la caméra ? → Problèmes de couche de connexion
DESCRIBE renvoie-t-il un SDP valide ? → Problèmes de plan de contrôle
Les paquets RTP arrivent-ils et décodent-ils correctement ? → Problèmes de plan média

Si vous ne savez pas quelle couche échoue, commencez par le workflow de diagnostic systématique.

Connection layer: reaching the camera

These problems happen before any RTSP command is sent. TCP handshake fails, TLS negotiation fails, or the network path is blocked.

RTSP connects but no video — The most common symptom. Camera appears online but no media stream.
RTSP over TLS (RTSPS) debugging — TLS certificate errors, handshake failures, cipher suite negotiation.

Plan de contrôle : erreurs de commande RTSP

Il s'agit d'erreurs au niveau du protocole renvoyées par la caméra en réponse à DESCRIBE, SETUP ou PLAY. Le code d'erreur vous indique exactement ce qui ne va pas.

400 requêtes incorrectes

RTSP 400 Bad Request : DESCRIBE failed — URL mal formée, en-têtes non pris en charge, interférence de proxy. Couvre les formats d'URL Axis, Dahua et Hikvision.

401 Non autorisé

Boucle d'authentification RTSP 401 — Digest vs authentification de base, paramètres nonce/realm, pourquoi l'authentification réussit dans VLC mais échoue dans votre application.
Exploration approfondie de l'authentification RTSP digest — Expiration occasionnelle, correspondance de domaine, gestion obsolète = vraie.
Diagnostic de l'URL de la caméra 401/404 — Lorsque l'URL fonctionne dans un client mais pas dans un autre.

404 introuvable

Diagnostics d'URL de caméra 401/404 — Chemin de flux incorrect, formats d'URL spécifiques à la caméra.
URL de contrôle d'agrégation et configuration SDP 404 — Lorsque l'URL de contrôle dans SDP ne correspond pas à l'URL DESCRIBE.

454 Session introuvable

RTSP 454 Session Not Found — Incompatibilité d'ID de session, sessions expirées, JOUER avant la CONFIGURATION.

461 Transport non pris en charge

RTSP 461 Transport non pris en charge : échec de la configuration — Négociation de transport UDP vs TCP, ffmpeg "échec de la méthode SETUP : 461", erreurs d'intégration Frégate/Scrypted/NVR.

Erreurs de serveur 500/503

Erreur du serveur interne RTSP 500 — Défaillance côté caméra. Quand conclure que le micrologiciel de l’appareil photo est en cause.
Service RTSP 503 non disponible — Épuisement des ressources de la caméra, trop de flux simultanés, limites de bande passante.

Transports et réseaux

UDP RTP bloqué par le pare-feu/NAT — Le contrôle RTSP fonctionne mais le média UDP RTP est bloqué. Règles de pare-feu, traversée NAT, configuration du port du protocole RTSP, repli entrelacé TCP.
Incompatibilité des canaux entrelacés TCP — Lorsque les canaux RTP/RTCP entrelacés ne correspondent pas entre le client et le serveur.
Réponse du serveur de transport sans correspondance — Le serveur répond avec des paramètres de transport différents de ceux demandés.
Débogage UDP multidiffusion — Configuration RTSP/RTP multidiffusion, IGMP, TTL et infrastructure réseau.
Délai d'expiration RTSP : UDP vs TCP entrelacé — Pourquoi le délai d'expiration des flux est différent sur UDP par rapport à TCP.

Media plane: RTP, codec, and payload problems

Control plane works perfectly — DESCRIBE returns SDP, SETUP succeeds, PLAY returns 200 OK — but video is broken. These are media plane problems.

RTP packet analysis

RTP dynamic payload type mismatch — "Unknown write" RTP/NDPI errors. How to map dynamic payload IDs to SDP rtpmap lines.
RTP packet loss diagnosis — RTP error in primary stream. Freezes, macroblocks, decoder errors. Read sequence numbers and RTCP reports to find the loss.
RTP timestamp drift — Audio/video sync loss, frame timing errors, clock rate mismatch.
RTP marker bit and frame boundaries — How the RTP marker bit signals H.264 access unit boundaries.
RTP sequence number wraparound — 16-bit sequence number rollover and how to detect actual loss vs wraparound.
RTP SSRC change mid-stream — When the camera changes SSRC mid-stream and the client loses sync.

H.264 and H.265 codec issues

H.264 FU-A fragmentation and reassembly — Missing fragments, start/end bit bugs, NAL unit reassembly failures, "invalid NAL unit" errors.
H.264 packetization mode 0 vs 1 — Single NAL vs non-interleaved mode. SDP parameter configuration.
H.264 SPS/PPS missing — Decoder errors when parameter sets are missing from SDP or RTP stream.
H.265 stream not working — H.265/HEVC failures and H.264 fallback behavior.
SDP H.264/H.265 diagnostics — Reading SDP for H.264/H.265: profile-level-id, sprop-parameter-sets, packetization-mode.

Audio and metadata tracks

Audio track AAC unknown track SDP — AAC audio tracks appearing as "unknown" in clients.

ONVIF and camera-specific

ONVIF works but RTSP URL fails — ONVIF discovery succeeds but direct RTSP connection fails.
Main stream vs sub stream — When the main stream works but the sub stream doesn't, or vice versa.

RTCP et gestion de sessions

Rapports de l'expéditeur RTCP : gigue et perte — Lecture des paquets RTCP SR pour comprendre la qualité du réseau du point de vue de la caméra.
RTCP BYE : le flux se termine de manière inattendue — Lorsque la caméra envoie RTCP BYE et met fin au flux.
RTCP CNAME et synchronisation audio/vidéo — Utilisation de RTCP CNAME pour synchroniser les pistes audio et vidéo.
RTSP TEARDOWN et nettoyage de session — Fuites de ressources de la caméra, échecs de reconnexion, état de flux occupé.
Délai d'expiration de la session RTSP et keepalive — Pourquoi les flux s'arrêtent après environ 30 secondes et comment les maintenir en vie.
RTSP Range header and NPT — Contrôle de la position de lecture avec les paramètres Range et NPT.
En-tête RTSP Scale et trick play — Avance rapide, rembobinage et contrôle de la vitesse via l'en-tête Scale.

Comparison and alternatives

RTSP Inspector vs Wireshark/VLC/ONVIF Device Manager — When to use a dedicated RTSP diagnostic tool vs a general network analyzer.
Wireshark RTSP alternative — Why RTSP diagnostics need more than packet capture.

Commencer

Vous débutez avec les diagnostics RTSP ? Commencez ici :

Flux de travail de diagnostic systématique — Le modèle à trois couches et la collecte de preuves.
Connectez-vous à un flux — Configuration de votre première connexion RTSP.
Guide de dépannage — Pannes courantes et leurs correctifs.

Preuve reproductible pour « Dépannage du flux RTSP : le guide de diagnostic complet pour les flux de caméra »

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 « Dépannage du flux RTSP : le guide de diagnostic complet pour les flux de caméra », 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 à « Dépannage du flux RTSP : le guide de diagnostic complet pour les flux de caméra » est la suivante : Flux de travail de diagnostic RTSP complet : couche de connexion, erreurs du plan de contrôle (400/401/404/454/461/500/503), échecs du plan média (H.264/H.265/RTP/RTCP), gestion de session et comparaison avec Wireshark/VLC. Chaque problème RTSP est mappé sur une page de diagnostic. 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 du flux RTSP : le guide de diagnostic complet pour les flux de caméra

Vérifiez « Dépannage du flux RTSP : le guide de diagnostic complet pour les flux de caméra » 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 2 : Flux de travail de diagnostic RTSP complet : couche de connexion, erreurs du plan de contr

Si « Flux de travail de diagnostic RTSP complet : couche de connexion, erreurs du plan de contrôle (400/401/404/454/461/500/503), échecs du plan média (H.2 » 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 3 : Triage rapide: "où est l’échec ?"

Vérifiez « Triage rapide: "où est l’échec ?" » 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 4 : Connection layer: reaching the camera

Si « Connection layer: reaching the camera » 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 5 : Plan de contrôle : erreurs de commande RTSP

Vérifiez « Plan de contrôle : erreurs de commande RTSP » 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 6 : 400 requêtes incorrectes

Si « 400 requêtes incorrectes » 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 7 : 401 Non autorisé

Vérifiez « 401 Non autorisé » 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 8 : 404 introuvable

Si « 404 introuvable » 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 9 : 454 Session introuvable

Vérifiez « 454 Session introuvable » 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 10 : 461 Transport non pris en charge

Si « 461 Transport non pris en charge » 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.

Matrice d’acceptation

Point	Preuve à conserver	Critère de réussite
Dépannage du flux RTSP : le guide de diagnostic complet pour les flux de caméra	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Flux de travail de diagnostic RTSP complet : couche de connexion, erreurs du plan de contrôle (400/401/404/454/461/500/5	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Triage rapide: "où est l’échec ?"	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Connection layer: reaching the camera	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Plan de contrôle : erreurs de commande RTSP	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
400 requêtes incorrectes	É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 :