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

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.