2026-06-02

Les flux de caméras RTCP BYE et RTSP se terminent de manière inattendue : pourquoi la vidéo s'arrête sans erreur claire

Comment déboguer RTCP BYE, la fin du flux RTP, le démontage de la caméra, l'expiration de la session, la perte de paquets et les arrêts inattendus du flux RTSP avec preuve de protocole.

Certains flux de caméras RTSP n'échouent pas avec une erreur propre. Ils démarrent, jouent un moment, puis la vidéo s'arrête. Le joueur peut se figer sur la dernière image. L'enregistreur peut fermer le fichier. Le client peut se reconnecter automatiquement. Les journaux peuvent indiquer « fin du flux », « délai d'attente RTP », « RTCP BYE », « connexion fermée du serveur » ou rien d'utile du tout.

Les recherches telles que « flux de caméra RTCP BYE », « le flux RTSP se termine de manière inattendue », « la caméra envoie RTCP BYE », « le flux RTP ne s'arrête pas d'erreur » et « la vidéo RTSP se fige après quelques minutes » proviennent généralement d'équipes qui ont déjà prouvé que l'URL fonctionne. Ils doivent savoir pourquoi le flux s’est terminé.

RTCP BYE est une réponse possible. Il s'agit d'un message de contrôle qui indique qu'un participant quitte la session RTP. Dans un flux de caméra, cela peut signifier que la caméra a intentionnellement terminé une piste multimédia, redémarré son encodeur, expiré une session ou fermé la diffusion multimédia alors que le canal de contrôle RTSP se comportait différemment.

RTSP Inspector est utile car un joueur peut masquer ce détail. Un outil de diagnostic de protocole peut conserver ensemble les événements RTSP, RTP et RTCP.

Que signifie RTCP BYE

RTCP est le protocole de contrôle associé à RTP. RTP transporte des paquets multimédias. RTCP transporte des rapports et des informations de contrôle. Un paquet RTCP BYE signale qu'une source quitte la session RTP.

Dans un cas simple :

RTP video packets arrive
RTCP Sender Reports arrive
RTCP BYE arrives
RTP video packets stop

RTCP BYE vs RTP timeout

Common reasons include:

RTSP TEARDOWN vs RTCP BYE

RTSP TEARDOWN and RTCP BYE are different.

TEARDOWN rtsp://camera/stream RTSP/1.0
Session: 12345678

RTCP BYE est un paquet de contrôle de session multimédia. Un flux peut se terminer par un, les deux ou aucun des deux, selon le comportement de la caméra et le point de capture.

Cas :

Le client envoie RTSP TEARDOWN : arrêt prévu.
La caméra ferme la connexion TCP : fin brutale côté serveur.
La caméra envoie RTCP BYE : la source multimédia est terminée.
RTP s'arrête sans RTCP BYE : délai d'attente ou chemin multimédia perdu.
RTSP reste ouvert mais RTP se termine : la couche média est terminée tandis que le contrôle reste actif.

Cette distinction permet d’éviter de blâmer la mauvaise couche.

Le flux se termine après une heure prévisible

Si le flux se termine après 30, 60, 120 ou 300 secondes, suspectez un maintien en vie ou un délai d'expiration de la session. Vérifiez l'en-tête RTSP Session :

Session: abcdef;timeout=60

Stream ends during camera reconfiguration

Many cameras restart encoders when settings change:

NVR and channel behavior

Evidence to collect:

Packet loss before BYE

Checklist for RTCP BYE investigations

Use this process:

What a useful report includes

For a vendor or network team, include:

Final diagnosis

Preuve reproductible pour « Les flux de caméras RTCP BYE et RTSP se terminent de manière inattendue : pourquoi la vidéo s'arrête sans erreur claire »

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 « Les flux de caméras RTCP BYE et RTSP se terminent de manière inattendue : pourquoi la vidéo s'arrête sans erreur claire », 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 à « Les flux de caméras RTCP BYE et RTSP se terminent de manière inattendue : pourquoi la vidéo s'arrête sans erreur claire » est la suivante : Comment déboguer RTCP BYE, la fin du flux RTP, le démontage de la caméra, l'expiration de la session, la perte de paquets et les arrêts inattendus du flux RTSP avec preuve de protocole. 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 : Les flux de caméras RTCP BYE et RTSP se terminent de manière inattendue : pourquoi la vidé

Vérifiez « Les flux de caméras RTCP BYE et RTSP se terminent de manière inattendue : pourquoi la vidéo s'arrête sans erreur claire » 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 2 : Comment déboguer RTCP BYE, la fin du flux RTP, le démontage de la caméra, l'expiration de

Si « Comment déboguer RTCP BYE, la fin du flux RTP, le démontage de la caméra, l'expiration de la session, la perte de paquets et les arrêts inattendus du » 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 3 : Que signifie RTCP BYE

Vérifiez « Que signifie RTCP BYE » 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 4 : RTCP BYE vs RTP timeout

Si « RTCP BYE vs RTP timeout » 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 5 : RTSP TEARDOWN vs RTCP BYE

Vérifiez « RTSP TEARDOWN vs RTCP BYE » 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 6 : Le flux se termine après une heure prévisible

Si « Le flux se termine après une heure prévisible » 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 7 : Stream ends during camera reconfiguration

Vérifiez « Stream ends during camera reconfiguration » 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 8 : NVR and channel behavior

Si « NVR and channel behavior » 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 9 : Packet loss before BYE

Vérifiez « Packet loss before BYE » 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 10 : Checklist for RTCP BYE investigations

Si « Checklist for RTCP BYE investigations » 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.

Matrice d’acceptation

Point	Preuve à conserver	Critère de réussite
Les flux de caméras RTCP BYE et RTSP se terminent de manière inattendue : pourquoi la vidéo s'arrête sans erreur claire	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Comment déboguer RTCP BYE, la fin du flux RTP, le démontage de la caméra, l'expiration de la session, la perte de paquet	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Que signifie RTCP BYE	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
RTCP BYE vs RTP timeout	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
RTSP TEARDOWN vs RTCP BYE	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Le flux se termine après une heure prévisible	É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 :