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

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.