2026-06-02

Modification RTP SSRC à mi-flux : débogage des redémarrages de la caméra, modifications de la source de flux, réinitialisations de séquence et problèmes de décodeur

Comment diagnostiquer les modifications RTP SSRC dans les flux de caméra RTSP, les réinitialisations des numéros de séquence, les discontinuités d'horodatage, les redémarrages de l'encodeur de caméra, les flux de basculement et les problèmes de décodeur.

RTP SSRC identifie la source de synchronisation d'un flux RTP. Lorsqu'il change au milieu d'une session RTSP, les utilisateurs peuvent voir des blocages, des images noires, une désynchronisation audio/vidéo, une vidéo corrompue, des alarmes de perte de paquets ou une réinitialisation soudaine du décodeur. Les expressions de recherche incluent « RTP SSRC modifié », « le flux RTSP se fige après le redémarrage de la caméra », « réinitialisation du numéro de séquence RTP », « discontinuité de l'horodatage RTP » et « source du flux de la caméra modifiée en cours de flux ».

L'inspecteur RTSP est utile car ce n'est pas une question normale du joueur. Les principales preuves résident dans les en-têtes de paquets RTP, les rapports des expéditeurs RTCP, les métadonnées de suivi SDP, les numéros de séquence et les horodatages.

Ce que signifie SSRC

En RTP, chaque source multimédia a une valeur SSRC. Une piste vidéo et une piste audio ont généralement des valeurs SSRC différentes. Le récepteur utilise SSRC avec le type de charge utile, le numéro de séquence, l'horodatage et les rapports RTCP pour maintenir la continuité du flux.

Si le SSRC change, un destinataire doit décider s'il s'agit :

Une nouvelle source de synchronisation légitime.
Un redémarrage de l'encodeur de la caméra.
Un basculement vers un autre encodeur.
Un bug du firmware.
Un problème de réécriture NAT/proxy.
Un nouveau flux mal mélangé dans la même session.

Traiter toutes les modifications SSRC comme une perte de paquets est trompeur.

Symptômes courants

Un changement de SSRC peut produire plusieurs symptômes visibles :

La vidéo se fige pendant quelques secondes.
Le décodeur affiche « unité NAL invalide » ou « cadre de référence manquant ».
La lecture continue mais la latence augmente.
L’audio et la vidéo s’éloignent.
Le client enregistre une perte soudaine de paquets.
Pics de gigue RTCP.
Les numéros de séquence redémarrent à partir d'une petite valeur.
L'horodatage RTP saute en arrière ou en avant.

La question importante est de savoir si l’identité médiatique a changé en même temps que la continuité de la séquence et de l’horodatage.

Redémarrage de la caméra ou redémarrage de l'encodeur

De nombreuses caméras IP redémarrent leur pipeline d'encodeur sans fermer la connexion RTSP TCP. La session de contrôle peut toujours sembler vivante, mais le RTP change en dessous.

Preuve:

Le même ID de session RTSP continue.
Modifications du RTP SSRC.
Le numéro de séquence RTP redémarre.
L'horodatage RTP redémarre ou saute.
Le rapport de l’expéditeur RTCP modifie le mappage.
L'image clé apparaît peu de temps après le redémarrage, ou le décodeur attend la prochaine image IDR.

Si le flux est récupéré après l'image clé suivante, le problème peut être dû au redémarrage de l'encodeur plutôt qu'à la perte de paquets réseau.

Sources multimédias de basculement et d’équilibrage de charge

Certains systèmes relaient les flux RTSP via une passerelle. Si la passerelle commute les caméras en amont, les pipelines d'enregistrement ou les travailleurs du transcodeur, le récepteur peut voir un nouveau SSRC.

Cela peut arriver avec :

Retransmission NVR.
Ponts de caméra cloud.
Basculement du proxy RTSP.
Firmware de la caméra multi-encodeur.
Serveurs de flux redondants.
Des équilibreurs de charge qui ne préservent pas l’affinité multimédia.

Si les modifications SSRC sont en corrélation avec le basculement du backend, le correctif peut appartenir à la couche relais.

Réinitialisation du numéro de séquence

Les numéros de séquence RTP sont de 16 bits et augmentent normalement de un pour chaque paquet du même flux. Une réinitialisation au même moment que le changement de SSRC peut être attendue. Une réinitialisation sans changement de SSRC est plus suspecte.

Comparaisons utiles :

Ancienne plage de séquences SSRC.
Nouveau premier numéro de séquence SSRC.
Type de charge utile avant et après.
Horodatage avant et après.
Comportement du bit marqueur près de la limite.
Si une image clé apparaît après la réinitialisation.

Cette distinction est importante pour le référencement car de nombreuses personnes recherchent « réinitialisation du numéro de séquence RTP » et supposent une perte de paquets, alors que la véritable cause est le remplacement de la source.

Discontinuité de l'horodatage

Les horodatages RTP suivent l’horloge multimédia. Pour la vidéo, c'est souvent 90 kHz. Si l'horodatage recule, un récepteur peut supprimer des images ou les réorganiser de manière incorrecte. S'il avance très loin, le comportement du tampon de gigue peut changer.

Lorsque SSRC change, la discontinuité de l'horodatage peut être acceptable si le récepteur le traite comme une nouvelle source. Lorsque SSRC ne change pas, la discontinuité de l’horodatage indique souvent une horloge d’expéditeur cassée.

L'inspecteur RTSP doit afficher clairement la limite de l'horodatage :

old SSRC: sequence 43120, timestamp 88210000
new SSRC: sequence 210, timestamp 3000

That kind of evidence is more useful than a player screenshot.

RTCP sender report changes

RTCP sender reports map RTP timestamps to wall-clock time. If SSRC changes, the receiver should watch for new RTCP sender reports.

Questions to answer:

Does the new SSRC send RTCP SR?
Does the old SSRC send RTCP BYE?
Does the camera announce source shutdown?
Is jitter calculated per SSRC or across the boundary?
Does packet loss accounting reset correctly?

If a tool merges statistics across SSRC changes, it may show false loss, false jitter, or false bitrate dips.

Decoder behavior

Even when RTP is valid, decoders need a clean frame boundary. For H.264 and H.265, recovery may require SPS/PPS/VPS and an IDR frame.

After an SSRC change, check:

Does the next access unit include a keyframe?
Are SPS and PPS repeated?
Does the SDP still match the actual stream?
Does payload type stay the same?
Does fragmentation restart in the middle of a frame?

If the new source starts with P-frames only, the receiver may show black video until the next keyframe.

Debug checklist

Use this workflow:

Identify all SSRC values per RTP track.
Locate the exact packet where SSRC changes.
Compare sequence numbers before and after.
Compare RTP timestamps before and after.
Check RTCP BYE and sender reports.
Check whether RTSP session ID changed.
Check whether payload type changed.
Look for keyframe or codec config after the boundary.
Separate source restart from network loss.
Export the boundary packets for firmware or gateway debugging.

Final diagnosis

An RTP SSRC change is not automatically a network problem. It can reveal camera encoder restart, RTSP relay failover, timestamp reset, media source replacement, or decoder recovery delay.

RTSP Inspector helps by showing the media evidence that players hide: SSRC, sequence number, timestamp, RTCP behavior, keyframe recovery, and the exact packet where the stream identity changed.

Preuve reproductible pour « Modification RTP SSRC à mi-flux : débogage des redémarrages de la caméra, modifications de la source de flux, réinitialisations de séquence et problèmes de décodeur »

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 « Modification RTP SSRC à mi-flux : débogage des redémarrages de la caméra, modifications de la source de flux, réinitialisations de séquence et problèmes de décodeur », 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.