2026-06-02

Le flux principal RTSP ne fonctionne pas mais le sous-flux fonctionne : quelle est la différence ?

Un guide de diagnostic pour les cas de caméras IP dans lesquels le sous-flux RTSP fonctionne mais le flux principal échoue, se fige, renvoie 404 ou ne peut pas être décodé.

Une requête de recherche de caméra IP très courante est « Le flux principal RTSP ne fonctionne pas mais le flux secondaire fonctionne ». Le symptôme est suffisamment spécifique pour être utile. Si le sous-flux fonctionne, la caméra est accessible, les informations d'identification sont probablement correctes, le service RTSP est activé et au moins un profil vidéo est accessible. Le problème n'est plus "RTSP est cassé". Le problème est la différence entre les profils de flux.

Le flux principal et le sous-flux diffèrent généralement par la résolution, le débit binaire, le codec, l'intervalle GOP, la taille de la charge utile et parfois même le chemin de l'URL. Un sous-flux peut être H.264 à basse résolution tandis que le flux principal est H.265, 4K, à débit binaire élevé ou limité à moins de sessions simultanées. Un NVR peut exposer différents chemins depuis la caméra elle-même. ONVIF peut renvoyer une URL en direct de mauvaise qualité tandis que l'URL d'enregistrement ou le profil principal nécessite un chemin distinct.

La question de diagnostic utile est la suivante : que prouve le sous-flux de travail et qu'est-ce qu'il ne prouve pas ?

Ce que prouve un sous-flux fonctionnel

Si le sous-flux peut être ouvert via RTSP, vous pouvez généralement dire :

l'adresse IP de la caméra est accessible
le port RTSP est ouvert
l'authentification fonctionne pour au moins un flux
le client peut analyser les réponses RTSP de base
DESCRIBE, SETUP et PLAY peuvent réussir pour au moins un profil
La livraison RTP est possible pour au moins une piste média

C'est une preuve précieuse. Cela restreint la recherche. Vous ne devez pas continuer à déboguer l’accessibilité de base du réseau après ce stade, à moins que le flux principal n’utilise un hôte, un port, un mode de transport ou un chemin NVR différent.

Ce qu'un sous-flux fonctionnel ne prouve pas

Un sous-flux fonctionnel ne prouve pas :

le chemin de l'URL du flux principal est correct
le flux principal est activé
le codec du flux principal est pris en charge
le débit binaire du flux principal peut traverser le réseau
le flux principal est disponible pour plusieurs clients
le flux principal envoie des preuves SPS/PPS ou VPS/SPS/PPS prêtes à être décodées
le NVR expose le flux principal de la caméra par le même chemin

C'est pourquoi « VLC peut ouvrir le flux secondaire » n'est pas suffisant pour un VMS, un système d'analyse ou un pipeline de rediffusion qui a besoin du flux principal.

Vérifier le chemin de l'URL avant le codec

De nombreuses familles de caméras utilisent différents modèles de chemin pour les flux principaux et secondaires. Certains utilisent « profile1 » et « profile2 ». Certains utilisent /Streaming/Channels/101 et /Streaming/Channels/102. Certains utilisent des noms d'accès « principal », « sous », « vidéo1 », « vidéo2 » ou des noms d'accès spécifiques au fournisseur. Certains NVR exposent les canaux différemment des URL directes des caméras.

Si le flux principal renvoie « 404 Not Found », inspectez :

URI exact de la requête envoyée dans DESCRIBE
si le chemin de l'URL correspond au modèle du fournisseur
numéro de chaîne
numéro de flux
jeton de profil découvert par ONVIF
si le flux est activé dans l'interface utilisateur Web de la caméra
si l'URL cible l'IP de la caméra ou l'IP du NVR

Ne traitez pas un 404 comme une perte de paquets. RTP n'a pas encore démarré.

Vérifiez le codec et le débit une fois que le chemin est valide

Si le flux principal renvoie SDP et démarre RTP mais n'affiche toujours pas de vidéo, passez aux codecs et aux preuves multimédias.

Les échecs du flux principal proviennent souvent de :

H.265 sélectionné alors que le consommateur attend H.264
preuves manquantes H.264 SPS/PPS ou H.265 VPS/SPS/PPS
intervalle d'images clés très long
perte de débit élevée via Wi-Fi ou liaison montante faible
fragmentation et perte de paquets en mouvement
profil ou niveau du décodeur non pris en charge par le système en aval

À ce stade, le rapport doit inclure le SDP, le type de charge utile, la continuité de la séquence RTP, la preuve de l'unité NAL du codec et si la première limite de décodage a été atteinte.

Limites de concurrence et comportement du NVR

Certains DVR, NVR ou micrologiciels de caméra à petit budget limitent l'accès au flux principal. Le sous-flux peut rester disponible alors que le flux principal est déjà consommé par l'affichage local, l'enregistrement, l'application du fournisseur ou un autre client. Cela peut ressembler à un problème d'URL même lorsque le chemin est correct.

Vérifications utiles :

déconnecter les autres spectateurs
tester l'IP de la caméra directe par rapport à l'IP du NVR
comparer le flux principal de l'interface utilisateur Web de la caméra
débit binaire ou résolution du flux principal inférieur
changer le codec de flux principal de H.265 à H.264
tester RTSP sur TCP entrelacé et UDP séparément

Si la réduction du débit binaire résout le problème, l'échec initial peut être lié à la capacité de transport plutôt qu'à la syntaxe de l'URL.

Comment l’inspecteur RTSP devrait cadrer cette affaire

L'inspecteur RTSP est plus puissant lorsqu'il explique la limite :

le chemin de contrôle du sous-flux réussit
le chemin de contrôle du flux principal échoue avec le code d'état
le flux principal renvoie SDP mais pas de RTP
Le RTP du flux principal arrive avec une perte de paquets
Les métadonnées du codec du flux principal sont manquantes ou non prises en charge
le flux principal est H.265 tandis que le consommateur a besoin de H.264

C'est la différence entre un « flux principal cassé » et un rapport de support utile. L'action suivante correcte peut être la recherche d'URL du fournisseur, la configuration du profil de flux, la modification du codec, la réduction du débit binaire, la mise à jour du micrologiciel ou la réparation du chemin réseau.

Si votre recherche exacte est « Le sous-flux RTSP fonctionne mais pas le flux principal », commencez par comparer les méthodes RTSP, SDP, le codec, le transport et la concurrence. Le sous-flux de travail ne constitue pas la fin du diagnostic. C'est l'échantillon témoin.

Preuve reproductible pour « Le flux principal RTSP ne fonctionne pas mais le sous-flux fonctionne : quelle est la différence ? »

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 « Le flux principal RTSP ne fonctionne pas mais le sous-flux fonctionne : quelle est la différence ? », 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 à « Le flux principal RTSP ne fonctionne pas mais le sous-flux fonctionne : quelle est la différence ? » est la suivante : Un guide de diagnostic pour les cas de caméras IP dans lesquels le sous-flux RTSP fonctionne mais le flux principal échoue, se fige, renvoie 404 ou ne peut pas être décodé. 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 : Le flux principal RTSP ne fonctionne pas mais le sous-flux fonctionne : quelle est la diff

Si « Le flux principal RTSP ne fonctionne pas mais le sous-flux fonctionne : quelle est la différence ? » 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 : Un guide de diagnostic pour les cas de caméras IP dans lesquels le sous-flux RTSP fonction

Vérifiez « Un guide de diagnostic pour les cas de caméras IP dans lesquels le sous-flux RTSP fonctionne mais le flux principal échoue, se fige, renvoie 404 ou ne » 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 : Ce que prouve un sous-flux fonctionnel

Si « Ce que prouve un sous-flux fonctionnel » 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 : Ce qu'un sous-flux fonctionnel ne prouve pas

Vérifiez « Ce qu'un sous-flux fonctionnel ne prouve 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 5 : Vérifier le chemin de l'URL avant le codec

Si « Vérifier le chemin de l'URL avant le codec » 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 : Vérifiez le codec et le débit une fois que le chemin est valide

Vérifiez « Vérifiez le codec et le débit une fois que le chemin est valide » 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 : Limites de concurrence et comportement du NVR

Si « Limites de concurrence et comportement du NVR » 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 : Comment l’inspecteur RTSP devrait cadrer cette affaire

Vérifiez « Comment l’inspecteur RTSP devrait cadrer cette affaire » 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 : Preuve reproductible pour « Le flux principal RTSP ne fonctionne pas mais le sous-flux fon

Si « Preuve reproductible pour « Le flux principal RTSP ne fonctionne pas mais le sous-flux fonctionne : quelle est la différence ? » » 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 : 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.

Matrice d’acceptation

Point	Preuve à conserver	Critère de réussite
Le flux principal RTSP ne fonctionne pas mais le sous-flux fonctionne : quelle est la différence ?	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Un guide de diagnostic pour les cas de caméras IP dans lesquels le sous-flux RTSP fonctionne mais le flux principal écho	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Ce que prouve un sous-flux fonctionnel	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Ce qu'un sous-flux fonctionnel ne prouve pas	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Vérifier le chemin de l'URL avant le codec	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Vérifiez le codec et le débit une fois que le chemin est valide	É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 :