2026-06-02

RTSP se connecte mais n'affiche aucune vidéo : ce qu'il faut inspecter avant de blâmer le joueur

Un chemin de diagnostic pratique pour les flux de caméras RTSP qui s'authentifient et se connectent mais affichent toujours un écran noir ou aucune vidéo décodée.

L'un des tickets de support de caméra les plus courants semble simple: "l'URL RTSP se connecte, l'authentification réussit, mais le spectateur ne montre aucune vidéo. L’instinct naturel est d’essayer un autre joueur. Cela peut être utile, mais cela ne répond pas à la question d'ingénierie : le flux a-t-il échoué au niveau du contrôle RTSP, de la négociation SDP, de la livraison RTP ou de la préparation du codec ?" Pour les intégrateurs de vidéosurveillance, les ingénieurs VMS et les fournisseurs de caméras, cette distinction est importante. Un joueur peut masquer la perte de paquets, réutiliser l’ancien état du décodeur ou réessayer silencieusement les modes de transport. Un rapport de diagnostic doit expliquer quelle partie du cours d’eau s’est avérée saine et laquelle ne l’était pas.

Séparez le succès du contrôle du succès des médias

RTSP est un protocole de contrôle. Une séquence réussie « DESCRIBE », « SETUP » et « PLAY » prouve que la caméra a accepté la session. Cela ne prouve pas que les paquets RTP sont arrivés. Cela ne prouve pas non plus que la charge utile est réellement H.264 ou H.265 sous la forme annoncée par SDP.

Un premier passage utile enregistre :

les codes d'état RTSP pour OPTIONS, DESCRIBE, SETUP et PLAY
si le corps du SDP contient une section multimédia vidéo
le type de charge utile négocié pour la piste vidéo
si les paquets RTP arrivent après PLAY
si l'horodatage RTP et les numéros de séquence avancent
si la première charge utile vidéo contient des preuves de paramètres de codec

Si le contrôle réussit mais qu'aucun RTP n'arrive, le problème vient généralement du transport, du pare-feu, du NAT, du mode caméra ou de la disponibilité du flux côté serveur. Si RTP arrive mais qu'il n'y a pas de vidéo prête à décoder, le problème se déplace vers la charge utile, la mise en paquets ou les métadonnées du codec.

Pourquoi SDP est la première frontière de preuves

SDP indique au client ce que la caméra prétend envoyer. Pour H.264, les ingénieurs recherchent les valeurs « rtpmap » et « fmtp » telles que le mode de mise en paquets, l'ID de niveau de profil et les « jeux de paramètres sprop ». Pour H.265, le SDP peut transporter les informations VPS, SPS et PPS différemment, et de nombreux consommateurs ont des limites de prise en charge plus strictes.

Lorsque le SDP indique H.264 mais que les octets multimédias ne contiennent pas la structure d'unité NAL attendue, l'échec n'est pas un « problème de lecteur » générique. Il s'agit d'un décalage entre les métadonnées annoncées et la réalité de la charge utile. Lorsque SDP omet les jeux de paramètres et que le flux RTP ne les envoie jamais en bande, un décodeur peut attendre indéfiniment.

C'est pourquoi un flux de travail d'inspection RTSP devrait conserver le SDP à côté des preuves médiatiques, et non enfoui dans le journal d'un joueur.

L’arrivée RTP ne suffit pas

Même lorsque les paquets RTP arrivent, la vidéo peut toujours échouer. Les trames H.264 et H.265 dépendent souvent de paquets antérieurs. Un paquet manquant peut rendre la tranche suivante indécodable. Une livraison dans le désordre peut ressembler à de la corruption. Une charge utile qui démarre au milieu du GOP peut ne pas être prête pour le décodage jusqu'à ce que l'image clé et le jeu de paramètres suivants apparaissent.

Les preuves minimales à collecter sont :

Continuité de la séquence RTP
progression de l'horodatage
comportement du bit marqueur
cohérence du type de charge utile
Catégories d'unités H.264 ou H.265 NAL
SPS, PPS et pour la visibilité VPS H.265
première préparation aux images clés

Cela explique pourquoi « VLC le joue » et « notre pipeline d'analyse le rejette » peuvent tous deux être vrais. Certains téléspectateurs récupèrent de manière agressive. Les systèmes d’ingénierie ont souvent besoin de preuves conformes aux normes.

TCP versus UDP est un choix de diagnostic

La commutation du transport RTSP d'UDP vers TCP est une étape de dépannage courante, mais elle ne doit pas être considérée comme une panacée. L'entrelacement TCP peut éviter le blocage des ports UDP et réduire la perte de paquets causée par la politique réseau. Il peut également masquer si le chemin UDP prévu pour le déploiement fonctionne.

Un bon rapport de terrain enregistre les deux tentatives :

RTSP sur TCP entrelacé : les médias arrivent-ils ?
Unicast RTP sur UDP : les paquets arrivent-ils sur les ports négociés ?
RTCP : les commentaires de l'expéditeur indiquent-ils le timing et le nombre de paquets ?

Si TCP fonctionne et qu'UDP échoue, la réponse n'est probablement pas la prise en charge des codecs. Il s'agit probablement d'un chemin réseau, d'un pare-feu, d'un NAT ou d'une allocation de port. Si les deux transports fournissent RTP mais que le décodage échoue toujours, inspectez la structure du codec.

Où s’adapte l’inspecteur RTSP

RTSP Inspector est conçu pour cette limite exacte. Il ne s’agit pas de devenir un lecteur vidéo ou un NVR. Il capture les preuves concernant la session RTSP, le SDP, le flux RTP/RTCP et la préparation H.264/H.265 afin qu'un ingénieur puisse expliquer pourquoi « connecté » n'est pas devenu « vidéo utilisable ».

Le résultat utile n'est pas une capture d'écran d'une fenêtre de lecteur noire. C'est une réponse reproductible :

Le contrôle RTSP a réussi
SDP a annoncé ce codec et ce type de charge utile
RTP est arrivé ou n'est pas arrivé
la séquence de paquets était continue ou interrompue
la preuve des paramètres du codec était présente ou manquante
l'action suivante appartient au réseau, à la configuration de la caméra, au micrologiciel ou au consommateur de flux

C’est la différence entre regarder un flux et en diagnostiquer un.

Preuve reproductible pour « RTSP se connecte mais n'affiche aucune vidéo : ce qu'il faut inspecter avant de blâmer le joueur »

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 « RTSP se connecte mais n'affiche aucune vidéo : ce qu'il faut inspecter avant de blâmer le joueur », 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 à « RTSP se connecte mais n'affiche aucune vidéo : ce qu'il faut inspecter avant de blâmer le joueur » est la suivante : Un chemin de diagnostic pratique pour les flux de caméras RTSP qui s'authentifient et se connectent mais affichent toujours un écran noir ou aucune vidéo décodée. 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 : RTSP se connecte mais n'affiche aucune vidéo : ce qu'il faut inspecter avant de blâmer le

Vérifiez « RTSP se connecte mais n'affiche aucune vidéo : ce qu'il faut inspecter avant de blâmer le joueur » 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 : Un chemin de diagnostic pratique pour les flux de caméras RTSP qui s'authentifient et se c

Si « Un chemin de diagnostic pratique pour les flux de caméras RTSP qui s'authentifient et se connectent mais affichent toujours un écran noir ou aucune vi » 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 : Séparez le succès du contrôle du succès des médias

Vérifiez « Séparez le succès du contrôle du succès des médias » 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 : Pourquoi SDP est la première frontière de preuves

Si « Pourquoi SDP est la première frontière de preuves » 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 : L’arrivée RTP ne suffit pas

Vérifiez « L’arrivée RTP ne suffit pas » 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 : TCP versus UDP est un choix de diagnostic

Si « TCP versus UDP est un choix de diagnostic » 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 : Où s’adapte l’inspecteur RTSP

Vérifiez « Où s’adapte l’inspecteur 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 8 : Preuve reproductible pour « RTSP se connecte mais n'affiche aucune vidéo : ce qu'il faut i

Si « Preuve reproductible pour « RTSP se connecte mais n'affiche aucune vidéo : ce qu'il faut inspecter avant de blâmer le joueur » » 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 : Comment rédiger une réponse directement réutilisable ?

Vérifiez « Comment rédiger une réponse directement réutilisable ? » 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 : Quelles données rendent le cas reproductible ?

Si « Quelles données rendent le cas reproductible ? » 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
RTSP se connecte mais n'affiche aucune vidéo : ce qu'il faut inspecter avant de blâmer le joueur	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Un chemin de diagnostic pratique pour les flux de caméras RTSP qui s'authentifient et se connectent mais affichent toujo	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Séparez le succès du contrôle du succès des médias	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Pourquoi SDP est la première frontière de preuves	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
L’arrivée RTP ne suffit pas	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
TCP versus UDP est un choix de diagnostic	É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 :