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 :

  1. Capturez le PLAY à vitesse normale.
  2. Capturez le jeu de trucs PLAY.
  3. Comparez les en-têtes « Range », « Scale » et « Speed ​​».
  4. Vérifiez le code d’état de la réponse.
  5. Vérifiez les en-têtes de réponse pour connaître le taux accepté.
  6. Comparez la cadence d'horodatage RTP.
  7. Vérifiez si le son s'arrête intentionnellement.
  8. Recherchez le comportement vidéo des images clés uniquement.
  9. Testez les vitesses discrètes prises en charge.
  10. 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.