2026-06-02

ONVIF fonctionne mais l'URL RTSP échoue : recherche du véritable chemin du flux de la caméra

Pourquoi la découverte ONVIF peut fonctionner lorsque le flux RTSP échoue et comment déboguer les profils de caméra, les URL de médias, l'authentification, le transport et les preuves SDP.

Il est courant qu'une caméra IP apparaisse correctement dans la découverte ONVIF alors que l'URL RTSP échoue toujours. L'appareil est visible sur le réseau, le nom et le modèle de la caméra sont détectés, peut-être même les profils sont répertoriés, mais le flux vidéo lui-même ne s'ouvre pas. Les utilisateurs recherchent « ONVIF fonctionne mais RTSP échoue », « caméra découverte mais pas de vidéo RTSP » ou « comment trouver l'URL RTSP à partir d'ONVIF », car le succès de la découverte donne l'impression qu'il devrait garantir le succès du streaming.

Ce n’est pas le cas.

ONVIF et RTSP sont liés dans de nombreux flux de travail de caméra, mais il ne s'agit pas du même protocole et ils ne prouvent pas la même chose. ONVIF peut vous indiquer qu'une caméra existe et peut fournir un profil multimédia. RTSP doit toujours s'authentifier, décrire le flux, négocier le transport, configurer les pistes RTP et livrer les paquets multimédias.

RTSP Inspector se concentre sur cette seconde moitié : que se passe-t-il réellement lorsqu'une URL RTSP spécifique est utilisée.

Ce que prouve ONVIF

La découverte ONVIF peut prouver que :

La caméra répond à WS-Discovery.
La caméra expose un point de terminaison de service ONVIF.
Le client peut accéder à l'interface de gestion des caméras.
La caméra peut avoir un ou plusieurs profils multimédias.
L'appareil peut signaler les URI de flux via les services multimédias ONVIF.

C’est utile, mais ce n’est pas la même chose que prouver que le flux RTSP fonctionne. La découverte ONVIF peut utiliser un port différent, un comportement d'authentification différent et un chemin de service différent de celui de RTSP.

Une caméra peut réussir la découverte ONVIF et échouer néanmoins RTSP pour les raisons suivantes :

RTSP est désactivé dans les paramètres de la caméra.
Le compte ONVIF ne dispose pas de l'autorisation RTSP.
L’URI du flux renvoyé est incomplet ou interne uniquement.
Le port RTSP est bloqué par un pare-feu.
La caméra nécessite un transport TCP entrelacé mais le client essaie UDP.
Le profil pointe vers H.265 mais le client attend du H.264.
Le chemin du canal NVR est erroné.
La caméra renvoie SDP mais n'envoie aucun paquet RTP.

L'URI du flux ONVIF peut ne pas être directement utilisable

Certaines caméras renvoient un URI RTSP via ONVIF qui semble utilisable mais doit encore être modifié. Par exemple:

rtsp://192.168.1.50/Streaming/Channels/101

The real usable URL may need:

ONVIF profile does not guarantee codec support

The symptom may be:

RTSP Inspector helps by separating the layers:

RTSP transport can fail after ONVIF succeeds

This is common when:

Authentication can differ between ONVIF and RTSP

You may see:

RTSP/1.0 401 Unauthorized
WWW-Authenticate: Digest realm="IP Camera", nonce="..."

même si la découverte ONVIF a fonctionné. Cela signifie que le service RTSP demande des informations d'identification. Si le client envoie des informations d'identification et que la caméra continue de renvoyer « 401 », vérifiez les autorisations du compte, l'authentification Digest, le codage d'URL et les droits de chaîne.

Les NVR rendent cela plus confus car le périphérique ONVIF peut être le NVR, tandis que le chemin du flux RTSP fait référence à un canal de caméra derrière le NVR. Le compte peut être autorisé à interroger le NVR mais pas à diffuser le flux principal du canal 1.

Confusion du flux principal et du sous-flux

De nombreuses caméras exposent plusieurs profils :

Flux principal : haute résolution, débit binaire élevé, souvent H.265.
Sous-flux : résolution inférieure, débit binaire inférieur, souvent H.264.
Flux mobile : petite taille d’image et fréquence d’images inférieure.

ONVIF peut renvoyer l'un de ces profils par défaut. L'URL RTSP copiée à partir d'un forum ou d'un PDF d'un fournisseur peut pointer vers un autre. Si le flux principal est H.265 mais que le client ne prend en charge que H.264, le sous-flux peut fonctionner tandis que le flux principal échoue.

Les recherches telles que « Le flux principal RTSP ne fonctionne pas, le sous-flux fonctionne » appartiennent souvent à cette catégorie. Le problème n'est pas la découverte. Il s'agit de la sélection du profil, de la sélection du codec, du débit binaire ou du comportement de transport.

Comment déboguer ONVIF fonctionne mais RTSP échoue

Utilisez une liste de contrôle à plusieurs niveaux :

Vérifiez que le service RTSP de la caméra est activé.
Confirmez que le port RTSP, généralement 554, est accessible depuis le client.
Obtenez le profil multimédia ONVIF et diffusez l'URI.
Normalisez l'URL RTSP pour le chemin réseau que vous utilisez réellement.
Ajoutez soigneusement les informations d’identification et encodez les caractères spéciaux en URL.
Exécutez RTSP OPTIONS et DESCRIBE.
Inspectez les défis et les réponses d’authentification.
Inspectez SDP pour le codec, le type de charge utile, la fréquence d'horloge et les URL de contrôle de suivi.
Comparez le transport entrelacé UDP et TCP.
Confirmez que les paquets RTP arrivent après « PLAY ».
Vérifiez la continuité de la séquence RTP, les horodatages et le type de charge utile.
Testez le flux principal et le sous-flux séparément.

Cette liste de contrôle évite une erreur courante : considérer le succès de la découverte ONVIF comme une preuve que le streaming multimédia doit fonctionner automatiquement.

Ce que doit montrer la trace RTSP

Un flux RTSP sain ressemble généralement à :

OPTIONS rtsp://camera/stream RTSP/1.0
RTSP/1.0 200 OK

DESCRIBE rtsp://camera/stream RTSP/1.0
RTSP/1.0 200 OK
Content-Type: application/sdp

SETUP rtsp://camera/stream/trackID=1 RTSP/1.0
RTSP/1.0 200 OK
Transport: RTP/AVP/TCP;unicast;interleaved=0-1

PLAY rtsp://camera/stream RTSP/1.0
RTSP/1.0 200 OK

Final diagnosis

Preuve reproductible pour « ONVIF fonctionne mais l'URL RTSP échoue : recherche du véritable chemin du flux de la caméra »

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 « ONVIF fonctionne mais l'URL RTSP échoue : recherche du véritable chemin du flux de la caméra », 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 à « ONVIF fonctionne mais l'URL RTSP échoue : recherche du véritable chemin du flux de la caméra » est la suivante : Pourquoi la découverte ONVIF peut fonctionner lorsque le flux RTSP échoue et comment déboguer les profils de caméra, les URL de médias, l'authentification, le transport et les preuves SDP. 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 : ONVIF fonctionne mais l'URL RTSP échoue : recherche du véritable chemin du flux de la camé

Ne fermez « ONVIF fonctionne mais l'URL RTSP échoue : recherche du véritable chemin du flux de la caméra » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 2 : Pourquoi la découverte ONVIF peut fonctionner lorsque le flux RTSP échoue et comment débog

Pour « Pourquoi la découverte ONVIF peut fonctionner lorsque le flux RTSP échoue et comment déboguer les profils de caméra, les URL de médias, l'authentifica », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Point de contrôle 3 : Ce que prouve ONVIF

Ne fermez « Ce que prouve ONVIF » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 4 : L'URI du flux ONVIF peut ne pas être directement utilisable

Pour « L'URI du flux ONVIF peut ne pas être directement utilisable », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Point de contrôle 5 : ONVIF profile does not guarantee codec support

Ne fermez « ONVIF profile does not guarantee codec support » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 6 : RTSP transport can fail after ONVIF succeeds

Pour « RTSP transport can fail after ONVIF succeeds », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Point de contrôle 7 : Authentication can differ between ONVIF and RTSP

Ne fermez « Authentication can differ between ONVIF and RTSP » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 8 : Confusion du flux principal et du sous-flux

Pour « Confusion du flux principal et du sous-flux », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Point de contrôle 9 : Comment déboguer ONVIF fonctionne mais RTSP échoue

Ne fermez « Comment déboguer ONVIF fonctionne mais RTSP échoue » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 10 : Ce que doit montrer la trace RTSP

Pour « Ce que doit montrer la trace RTSP », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Matrice d’acceptation

Point	Preuve à conserver	Critère de réussite
ONVIF fonctionne mais l'URL RTSP échoue : recherche du véritable chemin du flux de la caméra	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Pourquoi la découverte ONVIF peut fonctionner lorsque le flux RTSP échoue et comment déboguer les profils de caméra, les	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Ce que prouve ONVIF	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
L'URI du flux ONVIF peut ne pas être directement utilisable	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
ONVIF profile does not guarantee codec support	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
RTSP transport can fail after ONVIF succeeds	É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 :