Pistes audio RTSP, AAC et SDP inconnues : pourquoi un flux vidéo échoue avant la lecture

Certains flux de caméra RTSP échouent non pas parce que la vidéo n'est pas disponible, mais parce que la session contient plus que ce que le client attend. Une caméra peut annoncer de la vidéo, de l'audio, des métadonnées, des pistes privées, de l'audio de canal arrière ou des sections multimédias spécifiques au fournisseur dans SDP. Un consommateur strict peut rejeter la session entière lorsqu'il rencontre une piste non prise en charge.

Des recherches telles que « L'audio RTSP AAC ne fonctionne pas », « Piste inconnue dans SDP », « Le flux RTSP échoue avec l'audio activé » ou « La caméra fonctionne après la désactivation de l'audio » pointent vers la même limite de diagnostic : SDP décrit la session et chaque piste annoncée peut affecter la compatibilité.

SDP peut faire de la publicité bien plus que de la vidéo

Une réponse RTSP « DESCRIBE » peut inclure plusieurs sections multimédia :

• m=vidéo
• m=audio
• pistes de métadonnées
• pistes d'application
• charges utiles privées du fournisseur
• contrôler les URL par piste

Pour chaque piste, le client doit décider s'il peut la configurer, l'ignorer ou échouer. Certains clients sont tolérants. D'autres sont stricts. Si un moteur de restreaming ou un produit d'analyse attend uniquement une piste vidéo prise en charge, des sections SDP inconnues peuvent provoquer un échec surprenant.

AAC Audio a sa propre limite de compatibilité

AAC sur RTP est assez courant, mais tous les consommateurs RTSP ne gèrent pas proprement chaque charge utile audio. SDP devra peut-être décrire le mode, la configuration, la fréquence d'horloge, les canaux et le type de charge utile. Si ces champs sont manquants ou inhabituels, un client peut échouer lors de l'installation ou ultérieurement lors du dépaquetage.

Les problèmes audio peuvent apparaître comme :

• le flux s'ouvre uniquement lorsque l'audio est désactivé
• Erreur d'analyse SDP
• type de charge utile non pris en charge
• SETUP échoue sur la piste audio
• la vidéo fonctionne dans VLC mais échoue dans un chemin d'acquisition plus strict
• l'enregistreur rejette la session même si la piste vidéo est valide

Ce dernier cas est important : une piste audio non prise en charge peut bloquer l'accès à une piste vidéo utilisable en fonction du comportement du client.

Les pistes inconnues doivent être signalées et non masquées

Si SDP contient une section multimédia inconnue, un outil de diagnostic doit la conserver. Masquer les pistes non prises en charge rend plus difficile l’explication des échecs de compatibilité.

Les preuves utiles comprennent :

• section complète des médias SDP
• type de charge utile
• valeur rtpmap
• valeurs fmtp
• URL de contrôle de suivi
• si SETUP a été tenté
• si un échec s'est produit sur la piste vidéo, audio ou de métadonnées

Cela permet aux ingénieurs de décider s'il convient de désactiver la piste, de la filtrer, de modifier le profil de la caméra ou d'ajuster la prise en charge en aval.

Désactivez l'audio comme test, pas comme diagnostic

La désactivation de l'audio est une solution de contournement courante. Cela peut être valable, en particulier pour les workflows d'analyse qui n'ont besoin que de vidéo. Mais cela doit être traité comme un test :

• la vidéo et l'audio échouent
• la vidéo uniquement réussit
• SDP modifié après la désactivation de l'audio
• charge utile non prise en charge ou piste disparue
• Le chemin vidéo RTP est resté le même

Cette comparaison prouve que l'échec est dû à la composition de la session et non à l'accessibilité de base du réseau.

Où s’adapte l’inspecteur RTSP

L’inspecteur RTSP doit garder la structure de la session visible. Sa limite n’est pas la lecture ; c'est une explication du protocole. Pour les flux RTSP multipistes, cela devrait aider à répondre :

• combien de titres SDP a-t-il annoncé ?
• quelles pistes étaient prises en charge ?
• quelle piste a échoué à la configuration ?
• la vidéo RTP est-elle arrivée ?
• l'audio ou les métadonnées ont-ils bloqué le consommateur ?
• la prochaine action devrait-elle être un changement de profil de caméra ou un changement d'analyseur en aval ?

Lorsqu'un flux de caméra « ne fonctionne pas », la piste vidéo peut fonctionner correctement. La piste non prise en charge à côté peut être la véritable raison de l'échec de la session.