Erreur RTP dans le correctif du flux principal : diagnostiquer la perte de paquets, le blocage de la caméra et les macroblocs dans RTSP

Lorsqu'un flux de caméra IP se fige, bégaie ou produit des erreurs de décodeur H.264, le symptôme visible est généralement tardif. La cause apparaît souvent plus tôt dans la séquence RTP. Un paquet RTP manquant peut supprimer une tranche de données vidéo dont dépendent les images ultérieures. Au moment où le joueur enregistre une erreur de décodage, la preuve du réseau a peut-être déjà disparu.

C'est pourquoi le dépannage RTP doit commencer par les numéros de séquence, les horodatages, le type de charge utile, le comportement des marqueurs et la structure du codec avant de modifier les paramètres aléatoires de la caméra.

Ce que vous disent les lacunes de séquence RTP

Chaque paquet RTP porte un numéro de séquence. Pour un flux constant, la séquence doit avancer de manière prévisible. Un écart signifie qu'un ou plusieurs paquets ne sont pas arrivés. Un saut en arrière peut indiquer une réorganisation, une livraison en double, un comportement de redémarrage ou des problèmes de limite de capture.

Les questions pratiques sont :

• combien de paquets manquaient ?
• la perte s'est-elle produite une fois ou à plusieurs reprises ?
• est-ce que cela s'est produit à proximité des images clés ?
• les rapports des expéditeurs RTCP ont-ils continué ?
• la session de contrôle RTSP est-elle restée active ?
• la panne du décodeur s'est-elle produite après l'écart ?

Cette preuve peut distinguer la perte de réseau des bogues de charge utile de la caméra. Si les lacunes de séquence correspondent à une corruption visuelle, l’affaire est plus solide. Si la continuité de la séquence est parfaite mais que la charge utile est mal formée, le diagnostic s'oriente vers le comportement de l'encodeur ou de la mise en paquets.

Pourquoi H.264 et H.265 sont sensibles à la perte

La vidéo compressée n'est pas une liste d'images indépendantes. Les inter-images dépendent des référentiels. Une petite perte de paquet peut endommager davantage que le paquet immédiat. Les flux H.264 et H.265 peuvent également s'appuyer sur des ensembles de paramètres tels que SPS et PPS, et H.265 ajoute VPS. Si ceux-ci sont manquants, en retard ou corrompus, les logiciels en aval peuvent rejeter le flux même lorsqu'un spectateur tolérant semble récupérer.

Les symptômes courants comprennent :

• macroblocs ou artefacts en bloc
• se fige suivi d'un rattrapage soudain
• erreurs de décodeur de style "référence manquante"
• le flux démarre mais aucune image n'est prête à être décodée
• corruption répétée après des scènes riches en mouvements

Ces symptômes ne suffisent pas à eux seuls. Les preuves RTP et codec les rendent exploitables.

Ne confondez pas gigue et perte

La gigue signifie que les paquets arrivent avec un timing inégal. La perte signifie que les paquets n’arrivent pas. Les deux peuvent provoquer un bégaiement visible par l’utilisateur, mais ils nécessitent des correctifs différents.

Pour la gigue, inspectez la progression de l’horodatage et le moment d’arrivée. En cas de perte, inspectez les écarts de séquence. Pour les bogues du micrologiciel de la caméra, inspectez la cohérence de la charge utile et la structure NAL. Un rapport de terrain indiquant uniquement « le flux est saccadé » n'indique pas à un ingénieur réseau, à un ingénieur de micrologiciel ou à un fournisseur de VMS ce qu'il doit modifier.

Le meilleur rapport dit :

• Écart de séquence RTP de N à N+M
• saut d'horodatage observé au même point
• La session RTSP est restée établie
• le type de charge utile est resté stable
• La tranche H.264 était incomplète
• la prochaine trame IDR a restauré la préparation du décodeur

C'est un artefact de support beaucoup plus puissant.

UDP et TCP racontent des histoires différentes

RTSP transporte généralement RTP sur UDP ou sur TCP entrelacé. UDP expose directement la perte de paquets. TCP peut faire disparaître les chemins UDP bloqués, mais il peut introduire de la latence et ne prouve pas que le chemin de déploiement prévu est sain.

Pour les diagnostics, comparez les deux modes :

• UDP échoue en raison d'intervalles de séquence : inspectez la perte de réseau, les commutateurs, le Wi-Fi, le pare-feu, le NAT ou le comportement d'envoi de la caméra.
• UDP ne reçoit aucun RTP : inspectez les ports négociés et la politique de pare-feu.
• TCP fonctionne mais UDP échoue : chemin réseau suspect plutôt que codec.
• les deux modes affichent une charge utile mal formée : encodeur de caméra, profil de flux ou micrologiciel suspect.

Le choix du transport est une preuve, pas seulement une case à cocher du joueur.

Comment l'inspecteur RTSP définit le problème

RTSP Inspector se concentre sur les preuves de protocole plutôt que sur la lecture. Il capture les observations RTSP, RTP, RTCP et codecs afin qu'un cas de support puisse être relu et expliqué. Cela est important lorsque le même flux se comporte différemment dans VLC, FFmpeg, un NVR, un service d'ingestion cloud et un pipeline d'analyse.

L’objectif n’est pas de prétendre que chaque flux peut être corrigé localement. Le but est d'identifier le propriétaire de la panne :

• chemin réseau
• configuration de la caméra
• mise en paquet du micrologiciel
• prise en charge du décodeur en aval
• limite de codec non prise en charge
• Incompatibilité attendue du déploiement UDP/TCP

La perte RTP n’est pas seulement un symptôme vidéo. Il s’agit d’un événement protocolaire mesurable. Une fois mesurée, la conversation de dépannage devient beaucoup plus courte.