SDP, H.264 et H.265 dans les diagnostics RTSP : les métadonnées qui décident si la vidéo peut démarrer

De nombreux échecs RTSP sont décrits comme « le flux de la caméra n'est pas lu ». Cette phrase cache la limite de diagnostic la plus importante: "que prétendait la caméra dans SDP, et la charge utile du média correspondait-elle à cette affirmation ?" SDP est souvent la première preuve structurée disponible dans une session RTSP. Il déclare les pistes multimédias, les types de charges utiles, les noms de codecs, les fréquences d'horloge, les URL de contrôle et les paramètres spécifiques au codec. Si le SDP est erroné, incomplet ou non pris en charge par le consommateur, un flux peut échouer avant que la première trame ne soit décodée.

Ce que SDP devrait prouver

Après « DESCRIBE », un client doit savoir si le flux contient de la vidéo, quel type de charge utile correspond à quel codec et comment la piste multimédia doit être configurée. Pour le diagnostic de la caméra, inspectez :

• Section média m=vidéo
• URL de suivi a=control
• Type de charge utile a=rtpmap et nom du codec
• Paramètres du codec a=fmtp
• H.264 sprop-parameter-sets lorsqu'ils sont présents
• Signalisation H.265 VPS/SPS/PPS lorsqu'elle est disponible
• si la fréquence d'horloge annoncée est attendue

Si SDP annonce H.264 mais que la caméra envoie autre chose, le récepteur n'est pas déraisonnable. Si SDP omet la preuve des paramètres essentiels et que le flux ne l'envoie jamais dans la bande, le décodeur peut ne pas disposer de suffisamment d'informations pour commencer.

Les ensembles de paramètres H.264 ne sont pas des preuves facultatives

Les décodeurs H.264 ont besoin d'informations sur les paramètres de séquence et d'image. Dans les déploiements de caméras RTSP, cette preuve peut apparaître dans les charges utiles SDP, RTP intra-bande, ou les deux. Des problèmes apparaissent lorsqu'une caméra suppose que le récepteur sait déjà quelque chose qu'il ne sait pas.

Un dossier de diagnostic propre répond :

• le SPS était-il visible ?
• le PPS était-il visible ?
• les charges utiles incluaient-elles une trame IDR ?
• le flux a-t-il commencé au milieu du GOP ?
• l'identifiant au niveau du profil semblait-il plausible ?
• le mode de mise en paquets correspond-il à la structure de charge utile observée ?

Ceci est particulièrement important lorsqu’un joueur travaille et qu’un autre ne travaille pas. Un spectateur tolérant peut survivre à des métadonnées douteuses. Un pipeline d’enregistrement, d’analyse ou de conformité peut le rejeter.

H.265 ajoute plus de limites de compatibilité

Le H.265 est courant sur les caméras modernes, en particulier lorsque la bande passante est importante, mais il est moins universellement pris en charge que le H.264 dans les outils plus anciens et les consommateurs intégrés. H.265 apporte également des preuves VPS en plus des SPS et PPS. Un déploiement qui indique uniquement « RTSP fonctionne » peut quand même échouer car le profil de codec ou la livraison des paramètres réels se situe en dehors des limites prises en charge par le consommateur.

Pour les équipes de terrain, un article, un ticket ou un rapport utile ne doit pas simplement dire « passer au H.264 ». Il faudrait expliquer pourquoi :

• le consommateur actuel ne prend pas en charge H.265
• les jeux de paramètres H.265 sont manquants ou en retard
• le type de charge utile ne correspond pas au mappage de codec attendu
• le flux est valide mais en dehors des limites du produit
• le profil de la caméra doit être modifié pour ce flux de travail

Ce niveau de clarté évite les changements répétés par essais et erreurs.

SDP doit être comparé à RTP

SDP est une revendication. RTP est la preuve qui suit. Il faut comparer les deux.

Exemples :

• SDP affirme que le type de charge utile 96 est H.264, mais RTP arrive avec un type de charge utile différent.
• SDP contient une piste vidéo, mais aucun RTP ne suit « PLAY ».
• SDP indique H.265, mais le produit en aval ne prend en charge que H.264.
• SDP omet les jeux de paramètres et RTP ne les envoie jamais avant les tranches.
• RTP arrive, mais la structure de l'unité NAL n'est pas cohérente avec le codec annoncé.

Ces cas nécessitent des actions suivantes différentes. Sans comparer SDP et RTP, ils ressemblent tous au même vague échec « pas de vidéo ».

Pourquoi l'inspecteur RTSP fait apparaître ces preuves

RTSP Inspector est conçu pour les ingénieurs de flux, les fournisseurs de caméras et les intégrateurs de vidéosurveillance qui ont besoin de preuves reproductibles. Ce n'est intentionnellement pas un lecteur multimédia générique. Son travail consiste à inspecter le chemin de contrôle RTSP, les métadonnées SDP, le flux RTP/RTCP et la préparation H.264/H.265.

Cela rend le résultat utile dans les conversations d'assistance :

• fournisseur de caméra : correction du SDP ou de la mise en paquets
• équipe réseau : correction du chemin de livraison RTP
• Équipe VMS : ajuster le profil de codec pris en charge
• intégrateur terrain : changer de profil de flux ou de mode de transport
• client : comprendre pourquoi la lecture n'est pas une preuve de l'intégrité du protocole

Dans les diagnostics RTSP, SDP n'est pas un texte passe-partout. Il s’agit du premier contrat proposé par le stream. Si ce contrat est rompu, le reste du pipeline est en train de deviner.