Rapports de l'expéditeur RTCP, gigue et perte de paquets : lecture de l'état du flux sans regarder la vidéo

Lorsque les ingénieurs recherchent « gigue RTSP », « perte de paquets RTP » ou « rapport d'expéditeur RTCP », ils tentent généralement de répondre à une question pratique: "le flux est-il mauvais ou le lecteur a-t-il simplement des difficultés ? La lecture vidéo est un symptôme tardif. Les preuves RTP et RTCP apparaissent plus tôt et sont plus faciles à défendre dans un dossier de support." RTCP est le compagnon de contrôle de RTP. Il peut transporter des rapports d'expéditeur, des rapports de destinataire, le nombre de paquets, des informations de synchronisation et des commentaires sur la qualité. Toutes les caméras n'exposent pas un comportement RTCP riche, et tous les déploiements ne le transmettent pas correctement, mais lorsque RTCP est présent, il fournit un contexte important que la lecture brute ne fournit pas.

Pourquoi RTCP est important dans le diagnostic des caméras

RTP transporte des paquets multimédias. RTCP aide à décrire l’état de santé de la session multimédia. Pour un flux de caméra RTSP, les preuves RTCP peuvent aider à répondre :

• l'expéditeur est-il vivant après « PLAY » ?
• combien de paquets RTP l’expéditeur a-t-il signalé ?
• les horodatages RTP sont-ils alignés sur le timing de l'horloge murale ?
• la livraison des paquets est-elle régulière ou en rafale ?
• y a-t-il une gigue visible ?
• Le RTP a-t-il continué pendant que le décodage vidéo échouait ?
• le chemin médiatique incluait-il RTCP ?

Si le contrôle RTSP réussit et que RTP arrive, mais que la vidéo se bloque, RTCP peut aider à séparer la synchronisation du réseau de la préparation du codec.

Les rapports de l'expéditeur sont une preuve de timing

Un rapport d'expéditeur RTCP peut associer un horodatage RTP à une valeur temporelle absolue de style NTP. Cette relation aide les récepteurs à synchroniser les flux et à raisonner sur le comportement de l'horloge. En matière de diagnostic, les calculs exacts peuvent être moins importants que l'existence et la cohérence des rapports.

Observations utiles :

• le rapport de l'expéditeur apparaît après le démarrage du média
• le nombre de paquets et d'octets augmente
• Le mappage d'horodatage RTP est cohérent
• l'intervalle de rapport est plausible
• les rapports s'arrêtent lorsque RTP s'arrête
• les rapports continuent même lorsque le décodeur tombe en panne

Si RTCP s'arrête avec RTP, l'expéditeur ou le chemin multimédia peut être interrompu. Si RTCP continue mais que le décodage vidéo échoue, inspectez les preuves de charge utile et de codec.

La gigue n'est pas la même chose que la perte de paquets

La gigue signifie que les paquets arrivent avec un timing variable. La perte de paquets signifie que des paquets sont manquants. Les deux peuvent provoquer un bégaiement visible, mais ils conduisent à des solutions différentes.

Les numéros de séquence RTP indiquent les paquets manquants. Les horodatages RTP et les heures d'arrivée affichent des variations temporelles. Les rapports RTCP peuvent ajouter des commentaires au niveau de la session. Un bon rapport ne devrait pas mentionner uniquement « mauvais réseau ». Il doit indiquer si le problème est une perte, une gigue, une livraison en rafale, un RTCP bloqué ou une limite de décodage du codec.

Pour les caméras, la gigue peut provenir de :

• Variation de la liaison montante Wi-Fi
• encodeur de caméra surchargé
• Délai de transfert du NVR
• chemin de commutation encombré
• Chemin VPN ou WAN
• comportement de mise en mémoire tampon côté client

La perte de paquets peut provenir de :

• UDP abandonne
• comportement du pare-feu/NAT
• réseau surchargé
• la caméra envoie une pression tampon
• limitations des points de capture

Les correctifs sont différents.

RTCP manquant est également une preuve

Certains déploiements bloquent RTCP même lorsque RTP circule. Certaines caméras n'envoient pas de RTCP utile. Certains clients ne le demandent ni ne le reçoivent jamais clairement. L'absence de RTCP ne signifie pas automatiquement que le flux est interrompu, mais il doit être enregistré.

Si RTP sur UDP est négocié, inspectez les médias et contrôlez le trafic compagnon. Si RTSP sur TCP entrelacé est utilisé, inspectez les métadonnées du canal entrelacé. Un rapport indiquant « RTP visible, RTCP absent » est plus utile qu'un champ vide.

Où s’adapte l’inspecteur RTSP

RTSP Inspector est conçu pour la preuve de protocole, et non pour la visualisation passive. RTCP appartient à la même histoire que les méthodes RTSP, SDP, la continuité de séquence RTP, le type de charge utile, les métadonnées de codec et l'exportation de rapports.

Pour les recherches nécessitant beaucoup de RTCP, RTSP Inspector devrait vous aider à répondre :

• le RTP est-il arrivé après « PLAY » ?
• les rapports des expéditeurs RTCP sont-ils apparus ?
• le nombre de paquets a-t-il augmenté ?
• la gigue ou les écarts de séquence correspondent-ils à des échecs visibles ?
• la préparation du codec a-t-elle échoué malgré la livraison des médias ?
• le mode de transport a-t-il modifié le profil de santé ?

Cela donne à un fournisseur de caméras, un ingénieur réseau ou un développeur VMS un point de départ concret. "Le flux bégaie" est un symptôme. "Les écarts de séquence RTP et la gigue ont augmenté après PLAY tandis que le contrôle RTSP restait en vie" en est la preuve.