2026-06-02

Correction de la dérive de l'horodatage RTSP : inadéquation de la fréquence d'horloge RTP, synchronisation audio/vidéo et erreurs de synchronisation des images

Correction de la dérive de l'horodatage RTSP provoquant une perte de synchronisation audio/vidéo. Couvre l'inadéquation de la fréquence d'horloge RTP, la gigue, la synchronisation des images, les horodatages non monotones et l'instabilité de la lecture du flux de la caméra.

Un flux de caméra RTSP peut se connecter avec succès, s'authentifier correctement, renvoyer un SDP valide, envoyer des paquets RTP et toujours se comporter mal. La vidéo peut lentement prendre du retard sur le temps réel. L'audio et la vidéo peuvent être désynchronisés. Les images peuvent arriver mais jouer de manière inégale. Un enregistreur peut créer des fichiers d'une durée étrange. Un lecteur peut afficher des avertissements de gigue, de bégaiement, d'« horodatage non monotone », de « DTS invalide », de « saut d'horodatage RTP » ou de « non-concordance de fréquence d'horloge ».

Les utilisateurs recherchent « Dérive d'horodatage RTP », « Synchronisation audio-vidéo de la caméra RTSP », « Fréquence d'horloge RTP incorrecte », « Horodatage de bégaiement du flux RTSP » et « Problème de synchronisation des images du flux de la caméra » lorsque la connexion réseau fonctionne mais pas la chronologie multimédia.

C’est exactement le genre de problème où un test réservé aux joueurs est trop superficiel. Le joueur peut masquer la chronologie des paquets derrière la mise en mémoire tampon et le décodage. RTSP Inspector est utile car la synchronisation RTP est une preuve de protocole : le type de charge utile, l'horodatage RTP, le numéro de séquence, le bit marqueur, la fréquence d'horloge SDP, les rapports de l'expéditeur RTCP, la gigue et le mappage de l'horloge murale sont tous importants.

Les horodatages RTP ne sont pas des horodatages d'horloge murale

Un horodatage RTP est une valeur d'horloge multimédia, pas un horodatage Unix. Pour la vidéo H.264, SDP déclare souvent une horloge de 90 kHz :

a=rtpmap:96 H264/90000

90000 / 30 = 3000

Pour une vidéo à 25 ips, l'incrément est généralement de 3 600 :

90000 / 25 = 3600

SDP clock rate is the first clue

m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
m=audio 0 RTP/AVP 97
a=rtpmap:97 MPEG4-GENERIC/48000/2

Si le SDP indique que H.264 utilise 90 000, le client doit interpréter les horodatages RTP vidéo avec cette horloge. Si le SDP est manquant, mal formé ou incohérent avec le comportement de la charge utile, le client peut mal deviner.

Les problèmes courants de synchronisation SDP incluent :

Il manque a=rtpmap pour le type de charge utile dynamique.
Mauvaise fréquence d’horloge audio.
Type de charge utile réutilisé de manière incohérente.
Le micrologiciel de la caméra déclare 90 000 mais envoie des incréments d'horodatage qui ne correspondent pas à la fréquence d'images.
La configuration AAC ne correspond pas à la fréquence d'échantillonnage réelle.
Plusieurs pistes utilisent des attributs de contrôle confus ou en double.

RTSP Inspector devrait aider à préserver SDP à côté des preuves RTP, car la chronologie RTP ne peut pas être interprétée correctement sans elle.

Numéro de séquence vs horodatage

Les numéros de séquence RTP et les horodatages répondent à différentes questions.

Le numéro de séquence permet de détecter la perte et l’ordre des paquets :

Le paquet 1024 est-il arrivé ?
Le paquet 1025 est-il arrivé ?
Le paquet 1026 est-il arrivé avant 1025 ?
Des paquets manquent-ils ?

L'horodatage RTP permet d'interpréter l'heure du média :

Quels paquets appartiennent à la même image vidéo ?
Combien de temps multimédia s’est écoulé entre les images ?
La caméra a-t-elle sauté en avant ou en arrière ?
L’audio progresse-t-il au rythme attendu ?
L’heure des médias correspond-elle à l’heure de l’horloge murale ?

Un flux peut avoir une continuité de séquence parfaite tout en ayant des horodatages brisés. Il peut également y avoir une certaine perte de paquets alors que les horodatages restent par ailleurs cohérents.

Limites des bits de marqueur et des images vidéo

Pour de nombreuses charges utiles vidéo RTP, le bit marqueur indique une limite de trame. Avec H.264, plusieurs paquets RTP peuvent transporter des fragments d'une même image vidéo. Ils partagent le même horodatage RTP et le bit marqueur apparaît souvent sur le dernier paquet de l'unité d'accès.

Si les horodatages changent trop souvent, pas assez souvent, ou si le comportement des marqueurs est incohérent, la reconstruction de la trame peut devenir instable.

Les symptômes incluent :

Bégaiement vidéo sans perte de paquets visible.
Le décodeur reçoit des trames incomplètes.
L'enregistreur crée une durée d'image incorrecte.
La lecture accélère ou ralentit.
Les horodatages des images ne sont pas monotones.

C'est pourquoi un outil de diagnostic doit afficher les métadonnées RTP au niveau des paquets, et pas seulement les trames décodées.

Dérive de synchronisation audio/vidéo

La synchronisation audio et vidéo dépend du mappage de l'horodatage RTP de chaque piste multimédia sur une base de temps partagée. Les rapports d'expéditeur RTCP sont souvent utilisés à cet effet. Un rapport d'expéditeur peut mapper l'horodatage RTP à l'heure NTP :

RTCP SR:
NTP timestamp: wall-clock reference
RTP timestamp: media timestamp at that reference

Audio/video drift can happen when:

Timestamp jumps

Look for:

Questions to separate them:

Checklist for RTP timestamp drift

Use this workflow:

What to include in a useful report

Final diagnosis

Preuve reproductible pour « Correction de la dérive de l'horodatage RTSP : inadéquation de la fréquence d'horloge RTP, synchronisation audio/vidéo et erreurs de synchronisation des images »

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 « Correction de la dérive de l'horodatage RTSP : inadéquation de la fréquence d'horloge RTP, synchronisation audio/vidéo et erreurs de synchronisation des images », 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.

De l’observation au verdict par couche

Pour « Correction de la dérive de l'horodatage RTSP : inadéquation de la fréquence d'horloge RTP, synchronisation audio/vidéo et erreurs de synchronisation des images », écrivez d’abord l’observation puis son interprétation. Une observation peut être retrouvée dans la capture : statut RTSP lié à CSeq, valeur SDP, réponse Transport, trou de séquence, changement de SSRC ou différence entre RTP timestamp et RTCP sender report. « Le serveur est lent » ou « le codec est incompatible » reste une hypothèse tant qu’un élément précis ne la rend pas plus probable que les autres.

Découpez le parcours en frontières. TCP doit s’ouvrir, puis OPTIONS ou DESCRIBE être accepté. Le SDP doit décrire une piste exploitable, son control URL, payload type et clock rate. SETUP exige une réponse Transport compatible et PLAY une Session valide. Viennent ensuite arrivée RTP, ordre, temps et préparation du décodeur. Arrêtez-vous à la première frontière sans preuve de réussite ; une donnée ultérieure ne doit pas masquer une lacune antérieure.

Gardez source et intervalle constants pendant les comparaisons. UDP et TCP interleaved utilisent le même chemin et les mêmes identifiants. Main stream et sub stream gardent client et transport. Pour VLC face à un VMS, consignez méthodes, en-têtes et URL réels. Une différence de control URL, Authorization, Session ou keepalive explique parfois davantage que le nom de l’application.

Matrice d’exclusion

Commencez par deux hypothèses. Sans média, UDP peut être bloqué ou le serveur peut envoyer vers d’autres ports. TCP interleaved teste la première ; comparer offre et réponse Transport, adresses et ports teste la seconde. Pour une image corrompue, les séquences RTP séparent perte et initialisation incomplète, tandis que SPS/PPS/VPS avant la première image teste les paramètres codec.

Pour chaque hypothèse, notez une preuve favorable et une preuve qui pourrait la réfuter. Une affirmation qu’aucun paquet ne peut contredire est trop large. « Le NAT supprime UDP » est réfuté par RTP au port client. « Les paramètres H.264 manquent » est réfuté par SPS et PPS valides avant IDR. Le rapport reste ainsi ordonné plutôt qu’une liste de possibilités.

Interpréter le temps sans surconclure

RTSP CSeq ordonne les transactions, RTP sequence les paquets, RTP timestamp le temps d’échantillonnage, et l’horloge de capture l’arrivée au point observé. Ne les confondez pas. Une arrivée irrégulière ne prouve pas une dérive ; un saut timestamp ne prouve pas une perte sans séquence. Les RTCP sender reports relient les horloges RTP audio et vidéo à une référence commune.

Dossier de recette

Fermez l’enquête lorsque la correction se répète sur une connexion neuve avec un changement documenté. Le rapport indique entrées, dernière frontière réussie, première preuve en échec, modification, résultat et tests ouverts. Joignez un court extrait de transcription ou des statistiques ciblées. Masquez les secrets, mais gardez CSeq, Session nettoyée, SSRC et plage temporelle.

La procédure de dépannage RTSP reconstruit le parcours ; les rapports RTSP Inspector transmettent la frontière prouvée aux équipes caméra, réseau ou VMS.