2026-06-02

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

Correction d'une erreur RTP dans le flux principal provoquant le gel de la caméra, des bégaiements, des macroblocs et des pannes de décodeur. Diagnostiquez la perte de paquets RTP à l'aide des numéros de séquence, des rapports RTCP et des preuves de codec dans les flux 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.

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

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 « Erreur RTP dans le correctif du flux principal : diagnostiquer la perte de paquets, le blocage de la caméra et les macroblocs dans RTSP », 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 à « Erreur RTP dans le correctif du flux principal : diagnostiquer la perte de paquets, le blocage de la caméra et les macroblocs dans RTSP » est la suivante : Correction d'une erreur RTP dans le flux principal provoquant le gel de la caméra, des bégaiements, des macroblocs et des pannes de décodeur. Diagnostiquez la perte de paquets RTP à l'aide des numéros de séquence, des rapports RTCP et des preuves de codec dans les flux RTSP. 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 : Erreur RTP dans le correctif du flux principal : diagnostiquer la perte de paquets, le blo

Si « Erreur RTP dans le correctif du flux principal : diagnostiquer la perte de paquets, le blocage de la caméra et les macroblocs dans RTSP » est ambigu, comparez un cas nominal et un cas défaillant dans des conditions identiques. Marquez la première différence utile au lieu de lister tous les symptômes suivants. Cette limite produit généralement une demande d’assistance plus claire.

Point de contrôle 2 : Correction d'une erreur RTP dans le flux principal provoquant le gel de la caméra, des bég

Vérifiez « Correction d'une erreur RTP dans le flux principal provoquant le gel de la caméra, des bégaiements, des macroblocs et des pannes de décodeur. Diagnost » avec la plus petite entrée représentative. Gardez les réglages indépendants inchangés, répétez la même action et contrôlez le résultat après réouverture ou reconnexion. Une image seule est moins forte qu’un relevé comprenant entrée, réglage, action, sortie et heure.

Point de contrôle 3 : Ce que vous disent les lacunes de séquence RTP

Si « Ce que vous disent les lacunes de séquence RTP » est ambigu, comparez un cas nominal et un cas défaillant dans des conditions identiques. Marquez la première différence utile au lieu de lister tous les symptômes suivants. Cette limite produit généralement une demande d’assistance plus claire.

Point de contrôle 4 : Pourquoi H.264 et H.265 sont sensibles à la perte

Vérifiez « Pourquoi H.264 et H.265 sont sensibles à la perte » avec la plus petite entrée représentative. Gardez les réglages indépendants inchangés, répétez la même action et contrôlez le résultat après réouverture ou reconnexion. Une image seule est moins forte qu’un relevé comprenant entrée, réglage, action, sortie et heure.

Point de contrôle 5 : Ne confondez pas gigue et perte

Si « Ne confondez pas gigue et perte » est ambigu, comparez un cas nominal et un cas défaillant dans des conditions identiques. Marquez la première différence utile au lieu de lister tous les symptômes suivants. Cette limite produit généralement une demande d’assistance plus claire.

Point de contrôle 6 : UDP et TCP racontent des histoires différentes

Vérifiez « UDP et TCP racontent des histoires différentes » avec la plus petite entrée représentative. Gardez les réglages indépendants inchangés, répétez la même action et contrôlez le résultat après réouverture ou reconnexion. Une image seule est moins forte qu’un relevé comprenant entrée, réglage, action, sortie et heure.

Point de contrôle 7 : Comment l'inspecteur RTSP définit le problème

Si « Comment l'inspecteur RTSP définit le problème » est ambigu, comparez un cas nominal et un cas défaillant dans des conditions identiques. Marquez la première différence utile au lieu de lister tous les symptômes suivants. Cette limite produit généralement une demande d’assistance plus claire.

Point de contrôle 8 : Preuve reproductible pour « Erreur RTP dans le correctif du flux principal : diagnostiquer

Vérifiez « Preuve reproductible pour « Erreur RTP dans le correctif du flux principal : diagnostiquer la perte de paquets, le blocage de la caméra et les macrobl » avec la plus petite entrée représentative. Gardez les réglages indépendants inchangés, répétez la même action et contrôlez le résultat après réouverture ou reconnexion. Une image seule est moins forte qu’un relevé comprenant entrée, réglage, action, sortie et heure.

Point de contrôle 9 : Comment rédiger une réponse directement réutilisable ?

Si « Comment rédiger une réponse directement réutilisable ? » est ambigu, comparez un cas nominal et un cas défaillant dans des conditions identiques. Marquez la première différence utile au lieu de lister tous les symptômes suivants. Cette limite produit généralement une demande d’assistance plus claire.

Point de contrôle 10 : Quelles données rendent le cas reproductible ?

Vérifiez « Quelles données rendent le cas reproductible ? » avec la plus petite entrée représentative. Gardez les réglages indépendants inchangés, répétez la même action et contrôlez le résultat après réouverture ou reconnexion. Une image seule est moins forte qu’un relevé comprenant entrée, réglage, action, sortie et heure.

Matrice d’acceptation

Point	Preuve à conserver	Critère de réussite
Erreur RTP dans le correctif du flux principal : diagnostiquer la perte de paquets, le blocage de la caméra et les macro	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Correction d'une erreur RTP dans le flux principal provoquant le gel de la caméra, des bégaiements, des macroblocs et de	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Ce que vous disent les lacunes de séquence RTP	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Pourquoi H.264 et H.265 sont sensibles à la perte	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Ne confondez pas gigue et perte	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
UDP et TCP racontent des histoires différentes	É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 :