2026-06-02

Flux de caméras multidiffusion RTSP et UDP : pourquoi la découverte fonctionne mais le média n'arrive pas

Comment diagnostiquer les flux de caméra RTSP où la découverte ONVIF, le contrôle du trafic ou la configuration de multidiffusion fonctionnent mais où le média RTP n'arrive jamais.

Les réseaux de caméras mélangent souvent RTSP unicast, RTP multicast, découverte ONVIF, VLAN, commutateurs PoE, pare-feu et NVR. Le symptôme peut prêter à confusion: "la caméra est découverte, l'URL RTSP est valide, DESCRIBE renvoie SDP, mais les paquets multimédia n'arrivent jamais." Il s’agit d’une limite protocolaire classique. La découverte n'est pas un média. Le contrôle RTSP n'est pas une livraison RTP. L’accessibilité en multidiffusion n’est pas la même que l’accessibilité en monodiffusion.

La découverte ONVIF est une conversation UDP différente

La découverte ONVIF utilise généralement la multidiffusion UDP sur une adresse et un port de découverte. Si la découverte réussit, cela prouve qu'au moins un chemin de contrôle de style multidiffusion a fonctionné pour la découverte. Cela ne prouve pas que les groupes de multidiffusion RTP sont autorisés, joints, acheminés ou transférés.

Erreurs courantes :

en supposant que la découverte ONVIF prouve le chemin du média RTP
test à partir d'un VLAN différent de celui du NVR
autorisant TCP 554 mais bloquant les ports multimédias UDP
bloquer le trafic du groupe de multidiffusion au niveau du commutateur
oublier la surveillance IGMP ou le comportement du demandeur
tester l'URL directe de la caméra pendant que le NVR utilise un chemin différent

Le rapport doit nommer le type de trafic : découverte, contrôle RTSP, média RTP ou retour RTCP.

La multidiffusion nécessite une appartenance à un groupe

Pour le RTP multicast, le récepteur doit rejoindre le groupe multicast. Les commutateurs et les routeurs peuvent nécessiter un comportement IGMP pour transférer correctement le trafic. Si la multidiffusion est désactivée, filtrée ou mal configurée, le contrôle RTSP peut toujours fonctionner alors que le média n'arrive jamais.

Preuve utile :

SDP déclare une adresse de multidiffusion ou un transport unicast
L'en-tête de transport SETUP confirme le mode demandé
interface récepteur et VLAN
adresse du groupe de multidiffusion
si les paquets RTP atteignent le point de capture
si RTCP apparaît
si le mode unicast se comporte différemment

Si le RTP unicast fonctionne mais pas le multicast, le problème vient probablement de la configuration du réseau multicast, et non du H.264.

Les médias UDP peuvent être bloqués pendant le fonctionnement du contrôle TCP

Les pare-feu autorisent souvent TCP 554 ou 8554 mais bloquent les ports UDP. NAT peut également casser les médias UDP. Cela crée un modèle commun :

La connexion TCP réussit
DESCRIBE réussit
SETUP réussit
PLAY réussit
aucun RTP n'arrive

Le passage à TCP entrelacé est une comparaison utile. Si TCP entrelacé fonctionne, le serveur RTSP et le codec sont probablement fonctionnels. Le chemin multimédia UDP nécessite une attention particulière.

Que capturer

Pour les cas de multidiffusion et UDP, capturez :

En-têtes de requête et de réponse RTSP
Adresse média SDP et informations de suivi
en-tête de transport de SETUP
ports client et serveur
groupe de multidiffusion
Arrivée ou absence du paquet RTP
Arrivée ou absence du paquet RTCP
même test sur TCP entrelacé

Ces preuves aident l'équipe réseau à corriger le routage, le pare-feu ou le transfert multidiffusion au lieu de demander au fournisseur de la caméra de modifier les paramètres du codec.

Où s’adapte l’inspecteur RTSP

RTSP Inspector est conçu pour les preuves de protocole, et non pour les suppositions visuelles. Dans les cas de multidiffusion et UDP, sa valeur indique l'endroit où le flux s'est arrêté :

la découverte a fonctionné mais RTSP a échoué
RTSP a fonctionné mais RTP n'est jamais arrivé
UDP a échoué mais TCP entrelacé a fonctionné
le groupe de multidiffusion a été déclaré mais aucun paquet n'a atteint le client
RTP est arrivé mais la préparation du codec a échoué

Ce sont des échecs différents. Une fenêtre de lecteur ne peut pas les distinguer de manière fiable. Un rapport protocolaire peut le faire.

Preuve reproductible pour « Flux de caméras multidiffusion RTSP et UDP : pourquoi la découverte fonctionne mais le média n'arrive pas »

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 « Flux de caméras multidiffusion RTSP et UDP : pourquoi la découverte fonctionne mais le média n'arrive pas », 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 à « Flux de caméras multidiffusion RTSP et UDP : pourquoi la découverte fonctionne mais le média n'arrive pas » est la suivante : Comment diagnostiquer les flux de caméra RTSP où la découverte ONVIF, le contrôle du trafic ou la configuration de multidiffusion fonctionnent mais où le média RTP n'arrive jamais. 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 : Flux de caméras multidiffusion RTSP et UDP : pourquoi la découverte fonctionne mais le méd

Si « Flux de caméras multidiffusion RTSP et UDP : pourquoi la découverte fonctionne mais le média n'arrive pas » 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 2 : Comment diagnostiquer les flux de caméra RTSP où la découverte ONVIF, le contrôle du trafi

Vérifiez « Comment diagnostiquer les flux de caméra RTSP où la découverte ONVIF, le contrôle du trafic ou la configuration de multidiffusion fonctionnent mais 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 3 : La découverte ONVIF est une conversation UDP différente

Si « La découverte ONVIF est une conversation UDP différente » 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 4 : La multidiffusion nécessite une appartenance à un groupe

Vérifiez « La multidiffusion nécessite une appartenance à un groupe » 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 5 : Les médias UDP peuvent être bloqués pendant le fonctionnement du contrôle TCP

Si « Les médias UDP peuvent être bloqués pendant le fonctionnement du contrôle TCP » 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 6 : Que capturer

Vérifiez « Que capturer » 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 7 : Où s’adapte l’inspecteur RTSP

Si « Où s’adapte l’inspecteur RTSP » 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 8 : Preuve reproductible pour « Flux de caméras multidiffusion RTSP et UDP : pourquoi la décou

Vérifiez « Preuve reproductible pour « Flux de caméras multidiffusion RTSP et UDP : pourquoi la découverte fonctionne mais le média n'arrive 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 9 : Comment rédiger une réponse directement réutilisable ?

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

Vérifiez « Quelles données rendent le cas reproductible ? » 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.

Matrice d’acceptation

Point	Preuve à conserver	Critère de réussite
Flux de caméras multidiffusion RTSP et UDP : pourquoi la découverte fonctionne mais le média n'arrive pas	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Comment diagnostiquer les flux de caméra RTSP où la découverte ONVIF, le contrôle du trafic ou la configuration de multi	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
La découverte ONVIF est une conversation UDP différente	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
La multidiffusion nécessite une appartenance à un groupe	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Les médias UDP peuvent être bloqués pendant le fonctionnement du contrôle TCP	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Que capturer	É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 :