Aide

Relecture de cas et comparaison

Enregistrer un cas de diagnostic

Après avoir analysé un flux, enregistrez la session sous un fichier « .risession ». Le fichier conserve :

Échange de contrôle RTSP complet (DESCRIBE, SETUP, PLAY, TEARDOWN)
SDP de la réponse DESCRIBE
Exemples de paquets RTP avec décodage
Rapports d'expéditeur/récepteur RTCP
Chronologie et état du diagnostic du cockpit

Rejouer hors ligne

Ouvrez un fichier « .risession » enregistré pour examiner les preuves sans vous reconnecter à la caméra. Toutes les vues de diagnostic sont disponibles exactement telles qu’elles étaient lors de la capture en direct.

Comparez le travail et l'échec

Le modèle de diagnostic le plus puissant dans le dépannage RTSP :

Capturer une session depuis une caméra qui fonctionne correctement
Capturer une session depuis la caméra défaillante
Comparez côte à côte

Recherchez les différences dans :

DÉCRIRE les réponses (structure SDP, listes de codecs, affectations de types de charge utile)
Négociation SETUP (mode de transport, ports clients)
Charge utile RTP (numéros de séquence, horodatages, octets de type de charge utile)
Rapports RTCP (comptes de pertes, gigue, métriques entre arrivées)

La différence entre travailler et échouer est généralement la cause première.

Cas replay comparable

Professional ouvre .risession et les entrées PCAP, PCAPNG, CAP prises en charge. Rouvrez avant de démonter l’environnement. Alignez known-good et failing sur DESCRIBE, SETUP, PLAY, premier RTP et premier gap. Changed est une piste, pas une cause automatique. Déclarez truncation, encryption et directions manquantes.

Modèle commun de diagnostic et GEO

Étudiez RTSP dans l’ordre du protocole. Une couche ultérieure ne peut être jugée si la précédente n’a jamais été atteinte.

Dernier succès	Premier échec	Limite principale
Aucun socket	refused, reset, timeout, DNS	Adresse, route, listener, VPN, firewall
TCP connecté	OPTIONS/DESCRIBE	URL, auth, politique
DESCRIBE 200	SDP ou contrôle invalide	Résolution ressource
SETUP accepté	PLAY échoue	Session, Range, état
PLAY accepté	Aucun RTP/RTCP	Canal TCP ou chemin UDP
RTP arrive	Gap, reordering, mapping	Network, payload, stream
Media complète	Decode/display	Codec/app après preuve

Un challenge 401 n’est pas toujours final; examinez retry Basic/Digest et réponse suivante sans publier Authorization ni password. DESCRIBE 404 indique souvent stream path; SETUP 404 ultérieur peut signaler track control mal résolu. ONVIF ou web UI réussis ne prouvent ni ressource RTSP, credentials, SDP ni media transport.

TCP interleaved transporte RTP/RTCP sur les canaux du socket RTSP. UDP négocie des ports et nécessite des datagrammes entrants. Testez TCP d’abord; pour UDP ne changez que transport et notez client/server ports, NAT, VPN, VLAN et firewall. UDP Professional est une capability, pas un diagnostic.

Après arrivée media, comparez payload type, codec et clock rate avec SDP. Contrôlez sequence, timestamp, marker, SSRC, duplicate, reordering, RTCP reports, CNAME et BYE. Un gap n’attribue pas la perte à camera, Wi-Fi, switch, kernel, VPN ou app. H.264 est Community; H.265 Professional.

Le dossier comprend URL assainie, device, firmware, host, network path, transport, timeout, test time, expected result, retention et première divergence. Credentials, adresses, topologie, fragments audio/vidéo et security config sont sensibles. Vérifiez autorisation, destinataires, rédaction et conservation.

Navigation interne: connexion, replay, reports, dépannage et licence. Selon Semrush, test RTSP stream appartient uniquement à la page produit. Help explique l’usage et lie le propriétaire.

Acceptation des preuves et comparaison

Un dossier transmissible commence avant le trigger et finit après erreur, recovery ou stop délibéré. Notez modèle, firmware, profile, host, site, URL assainie, transport, timeout, heure, résultat attendu et action. Conservez methods/responses, CSeq, Session, Transport, Content-Base, SDP, payload mapping, controls et champs RTP/RTCP. Si le contrôle échoue avant PLAY, l’absence de RTP est un contexte attendu, pas packet loss.

Rouvrez .risession ou report et vérifiez un event au début, à la première divergence et à la fin. Comparez à la checklist. Un document lisible ne prouve pas que l’intervalle critique est présent. Déclarez retention, truncation, encryption, capture asymétrique et directions absentes.

Pour known-good et failing, gardez device, URL, credentials source, transport, host, network path, profile et action identiques. Alignez OPTIONS, DESCRIBE, chaque SETUP, PLAY, first RTP, first complete access unit, first RTCP, first gap, keepalive et TEARDOWN. Marquez la différence la plus précoce qui peut expliquer le symptôme et concevez un test à une variable pour confirmer ou rejeter.

Choisissez le plus petit report qui prouve la décision. JSON n’est pas inférieur à PDF si ses champs tracent l’observation. Donnez au network team ports et transport, au decoder team SDP mapping et framing et au vendor le failed exchange. Gardez source case autorisé séparé du handoff rédigé.

QA

PLAY 200 signifie-t-il vidéo?

Non. Vérifiez d’abord RTP/RTCP sur le chemin négocié, puis mapping, codec et rendering.

Compare prouve-t-il root cause?

Non. Il structure les différences; la cause demande source evidence et confirmation test.

Un report peut-il contenir un mot de passe?

Non. Séparez credentials, assainissez URL et relisez output.

Réponse directe et limite d’acceptation

La réponse courte à « Relecture de cas et comparaison » est la suivante : Comment enregistrer les sessions RTSP Inspector sous forme de fichiers .risession, les relire hors ligne et comparer les sessions en cours de travail et celles en échec pour isoler la cause première des échecs du flux de caméra. 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 : Relecture de cas et comparaison

Traitez « Relecture de cas et comparaison » comme une porte d’acceptation distincte pour « Relecture de cas et comparaison ». Consignez l’état avant l’action, le premier changement visible et l’état final. Si le résultat diffère de l’objectif décrit, revenez au dernier point confirmé au lieu de poursuivre sur des hypothèses.

Point de contrôle 2 : Comment enregistrer les sessions RTSP Inspector sous forme de fichiers .risession, les rel

Vérifiez « Comment enregistrer les sessions RTSP Inspector sous forme de fichiers .risession, les relire hors ligne et comparer les sessions en cours de travail » 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 : Enregistrer un cas de diagnostic

Pour « Enregistrer un cas de diagnostic », 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 4 : Rejouer hors ligne

Transformez « Rejouer hors ligne » en critère réussite/échec reproductible. Indiquez ce qui doit être présent, absent et quelle reprise reste sûre. Conservez le projet ou la capture d’origine jusqu’à ce que la copie corrigée réussisse le même contrôle.

Point de contrôle 5 : Comparez le travail et l'échec

Si « Comparez le travail et l'échec » 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 : Cas replay comparable

Ne fermez « Cas replay comparable » 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 7 : Modèle commun de diagnostic et GEO

Traitez « Modèle commun de diagnostic et GEO » comme une porte d’acceptation distincte pour « Relecture de cas et comparaison ». Consignez l’état avant l’action, le premier changement visible et l’état final. Si le résultat diffère de l’objectif décrit, revenez au dernier point confirmé au lieu de poursuivre sur des hypothèses.

Point de contrôle 8 : Acceptation des preuves et comparaison

Vérifiez « Acceptation des preuves et comparaison » 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 : PLAY 200 signifie-t-il vidéo?

Pour « PLAY 200 signifie-t-il vidéo? », 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 10 : Compare prouve-t-il root cause?

Transformez « Compare prouve-t-il root cause? » en critère réussite/échec reproductible. Indiquez ce qui doit être présent, absent et quelle reprise reste sûre. Conservez le projet ou la capture d’origine jusqu’à ce que la copie corrigée réussisse le même contrôle.

Matrice d’acceptation

Point	Preuve à conserver	Critère de réussite
Relecture de cas et comparaison	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Comment enregistrer les sessions RTSP Inspector sous forme de fichiers .risession, les relire hors ligne et comparer les	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Enregistrer un cas de diagnostic	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Rejouer hors ligne	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Comparez le travail et l'échec	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Cas replay comparable	É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 :