2026-06-02

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

Comment diagnostiquer les flux RTSP avec des pistes audio, des charges utiles AAC, des sections multimédias SDP inconnues et des échecs de compatibilité client.

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.

Preuve reproductible pour « Pistes audio RTSP, AAC et SDP inconnues : pourquoi un flux vidéo échoue avant la lecture »

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 « Pistes audio RTSP, AAC et SDP inconnues : pourquoi un flux vidéo échoue avant la lecture », 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 à « Pistes audio RTSP, AAC et SDP inconnues : pourquoi un flux vidéo échoue avant la lecture » est la suivante : Comment diagnostiquer les flux RTSP avec des pistes audio, des charges utiles AAC, des sections multimédias SDP inconnues et des échecs de compatibilité client. 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 : Pistes audio RTSP, AAC et SDP inconnues : pourquoi un flux vidéo échoue avant la lecture

Vérifiez « Pistes audio RTSP, AAC et SDP inconnues : pourquoi un flux vidéo échoue avant la lecture » 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 : Comment diagnostiquer les flux RTSP avec des pistes audio, des charges utiles AAC, des sec

Si « Comment diagnostiquer les flux RTSP avec des pistes audio, des charges utiles AAC, des sections multimédias SDP inconnues et des échecs de compatibili » 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 : SDP peut faire de la publicité bien plus que de la vidéo

Vérifiez « SDP peut faire de la publicité bien plus que de la vidéo » 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 : AAC Audio a sa propre limite de compatibilité

Si « AAC Audio a sa propre limite de compatibilité » 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 : Les pistes inconnues doivent être signalées et non masquées

Vérifiez « Les pistes inconnues doivent être signalées et non masquées » 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 : Désactivez l'audio comme test, pas comme diagnostic

Si « Désactivez l'audio comme test, pas comme 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 « Pistes audio RTSP, AAC et SDP inconnues : pourquoi un flux vid

Si « Preuve reproductible pour « Pistes audio RTSP, AAC et SDP inconnues : pourquoi un flux vidéo échoue avant la lecture » » 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
Pistes audio RTSP, AAC et SDP inconnues : pourquoi un flux vidéo échoue avant la lecture	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Comment diagnostiquer les flux RTSP avec des pistes audio, des charges utiles AAC, des sections multimédias SDP inconnue	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
SDP peut faire de la publicité bien plus que de la vidéo	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
AAC Audio a sa propre limite de compatibilité	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Les pistes inconnues doivent être signalées et non masquées	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Désactivez l'audio comme test, pas comme 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 :