2026-06-03

Débogage en boucle du numéro de séquence RTP : survol de 16 bits, fausse perte de paquets, pics de gigue et flux de caméra longs

Comment déboguer le bouclage du numéro de séquence RTP, le basculement de 16 bits, les fausses alarmes de perte de paquets, les flux de caméra RTSP de longue durée, les pics de gigue et les bogues de suivi de séquence.

Les numéros de séquence RTP sont des valeurs de 16 bits. Ils finissent par passer de « 65535 » à « 0 ». Les utilisateurs recherchent « retour en boucle du numéro de séquence RTP », « fausse perte de paquets RTP », « pic de gigue RTSP après une minute », « retournement de séquence RTP » et « alarme de perte de paquets de flux de caméra incorrecte » lorsqu'un flux de longue durée semble soudainement perdre des milliers de paquets.

RTSP Inspector est utile car il s'agit d'un problème de comptabilité d'en-tête de média. Le flux peut être sain, mais l'analyseur, la passerelle ou la logique de surveillance peuvent traiter le basculement comme une perte.

À quoi ressemble l'enveloppement

La progression normale de la séquence RTP proche du retournement ressemble à :

That is not a gap. It is expected 16-bit rollover.

If a tool calculates 0 - 65535 as a huge negative jump or treats it as missing packets, it will report false loss.

Common symptoms

Wraparound bugs show up as:

Packet loss spikes at regular intervals.
Jitter graph jumps suddenly.
Recording marks a healthy stream as unstable.
RTP replay stops at sequence 65535.
Analyzer reports negative sequence delta.
Gateway resets statistics incorrectly.
Long streams fail while short tests pass.

This case matters because many test streams are too short to expose the bug.

How fast rollover happens

Rollover timing depends on packet rate. A high bitrate video stream with many RTP packets per second can wrap relatively often. Low bitrate audio wraps much later.

Factors:

Frame rate.
Resolution.
Bitrate.
Fragmentation.
MTU.
Codec.
Whether audio and video are analyzed separately.

If an H.264 keyframe is heavily fragmented, sequence numbers advance faster.

Loss vs rollover

A real loss near rollover is possible, so the analyzer must handle both cases.

Compare:

Expected next sequence modulo 65536.
Payload continuity.
RTP timestamp continuity.
Marker bit behavior.
SSRC continuity.
RTCP receiver reports.

If SSRC, timestamp, and payload cadence continue normally, rollover is likely benign.

SSRC changes are different

Do not confuse sequence wraparound with SSRC change. When SSRC changes, a new sequence space may start. When only sequence number wraps, the same stream identity continues.

Evidence:

Same SSRC before and after.
Same payload type.
Same clock rate.
Timestamp continues.
No RTCP BYE.
No RTSP reconnect.

That is sequence rollover, not source replacement.

Replay and archive bugs

Tools that archive RTP events can fail at wraparound if they sort by raw sequence number instead of extended sequence number.

Bad behavior:

Packets after zero are sorted before older packets.
Replay jumps backward.
Loss calculation resets incorrectly.
Exported evidence looks out of order.

RTSP Inspector should preserve raw sequence numbers but calculate continuity with rollover-aware logic.

Debug checklist

Use this process:

Find the sequence boundary near 65535.
Check next packets after zero.
Confirm SSRC stays the same.
Confirm payload type stays the same.
Compare RTP timestamp deltas.
Check marker bit around frame boundary.
Check RTCP loss reports.
Separate rollover from actual missing packets.
Preserve packets before and after rollover.
Test long enough streams, not only short samples.

Final diagnosis

RTP sequence wraparound is normal. False alarms happen when tools treat 16-bit rollover as packet loss or stream reset.

RTSP Inspector helps diagnose long-running camera streams by showing sequence continuity, SSRC continuity, timestamp behavior, and real packet-loss evidence across rollover.

Preuve reproductible pour « Débogage en boucle du numéro de séquence RTP : survol de 16 bits, fausse perte de paquets, pics de gigue et flux de caméra longs »

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 en boucle du numéro de séquence RTP : survol de 16 bits, fausse perte de paquets, pics de gigue et flux de caméra longs », 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 en boucle du numéro de séquence RTP : survol de 16 bits, fausse perte de paquets, pics de gigue et flux de caméra longs » est la suivante : Comment déboguer le bouclage du numéro de séquence RTP, le basculement de 16 bits, les fausses alarmes de perte de paquets, les flux de caméra RTSP de longue durée, les pics de gigue et les bogues de suivi de séquence. 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 en boucle du numéro de séquence RTP : survol de 16 bits, fausse perte de paquets,

Ne fermez « Débogage en boucle du numéro de séquence RTP : survol de 16 bits, fausse perte de paquets, pics de gigue et flux de caméra longs » 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 2 : Comment déboguer le bouclage du numéro de séquence RTP, le basculement de 16 bits, les fau

Pour « Comment déboguer le bouclage du numéro de séquence RTP, le basculement de 16 bits, les fausses alarmes de perte de paquets, les flux de caméra RTSP de », 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 3 : À quoi ressemble l'enveloppement

Ne fermez « À quoi ressemble l'enveloppement » 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 4 : Common symptoms

Pour « Common symptoms », 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 5 : How fast rollover happens

Ne fermez « How fast rollover happens » 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 6 : Loss vs rollover

Pour « Loss vs rollover », 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 7 : SSRC changes are different

Ne fermez « SSRC changes are different » 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 8 : Replay and archive bugs

Pour « Replay and archive bugs », 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 9 : Debug checklist

Ne fermez « Debug checklist » 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 10 : Final diagnosis

Pour « Final diagnosis », 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.

Matrice d’acceptation

Point	Preuve à conserver	Critère de réussite
Débogage en boucle du numéro de séquence RTP : survol de 16 bits, fausse perte de paquets, pics de gigue et flux de camé	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Comment déboguer le bouclage du numéro de séquence RTP, le basculement de 16 bits, les fausses alarmes de perte de paque	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
À quoi ressemble l'enveloppement	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Common symptoms	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
How fast rollover happens	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Loss vs rollover	É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 :