2026-06-03

Débogage de l'échelle RTSP et de l'en-tête rapide : avance rapide, ralenti, lecture astucieuse, lecture NVR et fréquence non prise en charge

Comment déboguer les en-têtes RTSP Scale et Speed, l'avance rapide, le ralenti, la lecture NVR, les interactions de plage, la vitesse de lecture non prise en charge et le comportement de la caméra de lecture astucieuse.

La visualisation en direct RTSP est déjà compliquée, mais la lecture enregistrée ajoute une autre couche: "le contrôle de la vitesse. Les utilisateurs recherchent "En-tête d'échelle RTSP", "En-tête de vitesse RTSP", "Avance rapide RTSP ne fonctionne pas", "Lecture astucieuse NVR RTSP", "Vitesse de lecture RTSP non prise en charge" et "Lecture de caméra au ralenti RTSP" lorsque la lecture normale fonctionne mais que l'avance rapide, la lecture arrière ou la lecture lente échoue."

L'inspecteur RTSP est utile car le jeu de trucs est un problème de plan de contrôle. Le client envoie « PLAY » avec « Range », « Scale » ou « Speed », et le serveur peut accepter, bloquer, ignorer ou rejeter la demande.

Mise à l'échelle par rapport à la lecture normale

La lecture normale ressemble souvent à :

PLAY rtsp://nvr/recording RTSP/1.0
Range: npt=0-

Trick play may add:

Scale: 2.0

ou un autre tarif en fonction du support du serveur. Certains serveurs ne prennent en charge que les valeurs sélectionnées. Certains ignorent les valeurs non prises en charge. Certains renvoient un en-tête de réponse avec l’échelle réellement acceptée.

Symptômes courants

Les échecs apparaissent comme :

Le bouton d'avance rapide ne fait rien.
Le flux passe au mauvais moment.
La lecture se fige après la demande de mise à l'échelle.
Le serveur renvoie « Méthode 455 non valide dans cet état ».
Le serveur renvoie « 457 Plage invalide ».
Le serveur renvoie « 501 non implémenté ».
Le serveur accepte PLAY mais garde une vitesse normale.
Le NVR envoie uniquement des images clés pendant l'avance rapide.
L'audio disparaît pendant la lecture de trucs.

Ce ne sont pas les mêmes échecs. Les en-têtes exacts de demande et de réponse sont importants.

Interaction de plage

La lecture RTSP enregistrée combine souvent « Range » avec « Scale ».

Exemples :

Range: npt=120-
Scale: 4.0

or:

Range: clock=20260603T010000Z-
Scale: 0.5

Si le client envoie un format d'heure que le serveur ne prend pas en charge, l'échec peut ressembler à un problème de vitesse même si « Range » est le véritable problème.

Le serveur bloque ou réécrit la vitesse

Certains NVR n'acceptent que des valeurs discrètes :

'0,5'
« 1,0 »
'2.0'
'4.0'
« 8,0 »
modes d'images clés uniquement

Si le client demande « 3.0 », le serveur peut choisir « 2.0 » ou « 4.0 ». Une bonne trace compare le débit demandé avec les en-têtes de réponse acceptés et le timing RTP réel.

Comportement audio pendant la lecture de trucs

De nombreux serveurs abandonnent l'audio pendant la lecture en avance ou en retour rapide. On peut s’y attendre car l’audio ne peut pas être décodé de manière significative à grande vitesse.

Preuve:

La configuration vidéo reste active.
L'audio RTP s'arrête après une lecture en avance rapide.
Le serveur envoie RTCP BYE pour l'audio.
La piste audio reprend lorsque Scale revient à « 1.0 ».
SDP annonce toujours l'audio, mais le mode de lecture le supprime.

Ne diagnostiquez pas cela comme une perte de paquets tant que l’état du contrôle RTSP n’est pas vérifié.

Avance rapide par image clé uniquement

Les NVR envoient souvent uniquement des images clés pendant la lecture à grande vitesse. Cela réduit la bande passante et les coûts de décodage mais modifie la cadence RTP.

Symptômes:

La vidéo semble nerveuse.
Le débit binaire RTP diminue.
Les cadres sont clairsemés.
Modifications de la cadence des bits du marqueur.
Les horodatages sautent à de grands intervalles.

Il peut s'agir d'un comportement de jeu trompeur correct, et non d'une corruption de flux.

Lecture inversée non prise en charge

La lecture inversée n’est pas universellement prise en charge. Certains serveurs rejettent les valeurs d'échelle négatives. D'autres émulent la lecture inversée en sautant entre les images clés.

Termes de recherche :

"Lecture inversée RTSP non prise en charge"
"Échelle négative RTSP"
"RTSP de rembobinage NVR"
"Le truc RTSP ne lit que les images clés"

La question de diagnostic est de savoir si le serveur a explicitement rejeté le débit demandé ou s'il a modifié silencieusement son comportement.

Liste de contrôle de débogage

Utilisez ce processus :

Capturez le PLAY à vitesse normale.
Capturez le jeu de trucs PLAY.
Comparez les en-têtes « Range », « Scale » et « Speed ».
Vérifiez le code d’état de la réponse.
Vérifiez les en-têtes de réponse pour connaître le taux accepté.
Comparez la cadence d'horodatage RTP.
Vérifiez si le son s'arrête intentionnellement.
Recherchez le comportement vidéo des images clés uniquement.
Testez les vitesses discrètes prises en charge.
Conservez les en-têtes de demande et de réponse pour le support du fournisseur NVR.

Diagnostic final

Les échecs d'avance rapide RTSP, de ralenti et de lecture astucieuse doivent être diagnostiqués ensemble à partir des en-têtes de contrôle et du timing multimédia. Le serveur peut rejeter, bloquer, ignorer ou prendre en charge partiellement « Scale » et « Speed ».

RTSP Inspector aide à prouver si le problème est dû à une vitesse de lecture non prise en charge, au format de plage, à la politique de lecture frauduleuse du NVR, à la suppression audio ou à l'interprétation du client.

Preuve reproductible pour « Débogage de l'échelle RTSP et de l'en-tête rapide : avance rapide, ralenti, lecture astucieuse, lecture NVR et fréquence non prise en charge »

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 « Débogage de l'échelle RTSP et de l'en-tête rapide : avance rapide, ralenti, lecture astucieuse, lecture NVR et fréquence non prise en charge », 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 à « Débogage de l'échelle RTSP et de l'en-tête rapide : avance rapide, ralenti, lecture astucieuse, lecture NVR et fréquence non prise en charge » est la suivante : Comment déboguer les en-têtes RTSP Scale et Speed, l'avance rapide, le ralenti, la lecture NVR, les interactions de plage, la vitesse de lecture non prise en charge et le comportement de la caméra de lecture astucieuse. 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 : Débogage de l'échelle RTSP et de l'en-tête rapide : avance rapide, ralenti, lecture astuci

Si « Débogage de l'échelle RTSP et de l'en-tête rapide : avance rapide, ralenti, lecture astucieuse, lecture NVR et fréquence non prise en charge » 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 déboguer les en-têtes RTSP Scale et Speed, l'avance rapide, le ralenti, la lecture

Vérifiez « Comment déboguer les en-têtes RTSP Scale et Speed, l'avance rapide, le ralenti, la lecture NVR, les interactions de plage, la vitesse de lecture non p » 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 : Mise à l'échelle par rapport à la lecture normale

Si « Mise à l'échelle par rapport à la lecture normale » 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 : Symptômes courants

Vérifiez « Symptômes courants » 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 : Interaction de plage

Si « Interaction de plage » 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 : Le serveur bloque ou réécrit la vitesse

Vérifiez « Le serveur bloque ou réécrit la vitesse » 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 : Comportement audio pendant la lecture de trucs

Si « Comportement audio pendant la lecture de trucs » 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 : Avance rapide par image clé uniquement

Vérifiez « Avance rapide par image clé uniquement » 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 : Lecture inversée non prise en charge

Si « Lecture inversée non prise en charge » 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 : Liste de contrôle de débogage

Vérifiez « Liste de contrôle de débogage » 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
Débogage de l'échelle RTSP et de l'en-tête rapide : avance rapide, ralenti, lecture astucieuse, lecture NVR et fréquence	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Comment déboguer les en-têtes RTSP Scale et Speed, l'avance rapide, le ralenti, la lecture NVR, les interactions de plag	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Mise à l'échelle par rapport à la lecture normale	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Symptômes courants	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Interaction de plage	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Le serveur bloque ou réécrit la vitesse	É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 :