2026-06-02

Correction de la fragmentation RTP H.264 FU-A : pourquoi votre vidéo RTSP est interrompue (perte de paquets, réassemblage NAL)

Répare la vidéo RTSP cassée à partir de la fragmentation RTP H.264 FU-A. Couvre les fragments manquants, les bogues de bits de début/fin, les échecs de réassemblage NAL, la perte de paquets, la MTU et les erreurs de décodeur avec de vraies commandes de diagnostic.

H.264 sur RTP présente des problèmes qui ressemblent à des bogues de décodeur, mais qui constituent en réalité des problèmes de mise en paquets. La session RTSP fonctionne. DESCRIBE renvoie un SDP valide. La CONFIGURATION réussit. PLAY renvoie 200 OK. Les paquets RTP arrivent avec le type de charge utile correct mappé sur H.264. Pourtant, la vidéo montre une corruption de bloc, des blocages, des images noires ou des erreurs de décodeur.

Les erreurs ressemblent à ceci dans vos journaux :

[h264 @ 0x...] invalid NAL unit size
[h264 @ 0x...] missing picture in access unit
[h264 @ 0x...] non-existing PPS 0 referenced
[h264 @ 0x...] decode_slice_header error
[h264 @ 0x...] no frame!

The fast answer

Why fragmentation exists

The structure of an FU-A packet

Each FU-A RTP packet contains:

Byte 0: FU indicator
  bit 7: F (forbidden_zero_bit) — normally 0
  bits 6-5: NRI (nal_ref_idc) — priority
  bits 4-0: Type = 28 (FU-A)
Byte 1: FU header
  bit 7: S (Start) — 1 for first fragment
  bit 6: E (End) — 1 for last fragment
  bit 5: R (Reserved) — always 0
  bits 4-0: Type — original NAL unit type (1=non-IDR, 5=IDR, 7=SPS, 8=PPS)
Byte 2+: Fragment payload — the actual NAL unit data

Une séquence FU-A complète pour une unité NAL :

Packet 1: FU indicator (type=28) | FU header (S=1, E=0, type=5) | payload[0..N]
Packet 2: FU indicator (type=28) | FU header (S=0, E=0, type=5) | payload[N+1..M]
Packet 3: FU indicator (type=28) | FU header (S=0, E=0, type=5) | payload[M+1..P]
Packet 4: FU indicator (type=28) | FU header (S=0, E=1, type=5) | payload[P+1..END]

The RTP marker bit

Failure modes: what breaks and why

Failure 1: Missing middle fragment

Expected:  1000(S)  1001(M)  1002(M)  1003(E|marker)
Received:  1000(S)  1001(M)  [LOST]   1003(E|marker)

Le réassembleur voit un fragment de début, un fragment du milieu, puis un fragment de fin, mais les octets de charge utile ne se connectent pas. L'unité NAL réassemblée présente un espace.

Symptômes:

Bloquer la corruption dans une bande horizontale du cadre
Le décodeur signale "taille d'unité NAL invalide"
Corruption limitée à une unité d'accès (efface au prochain IDR)

Échec 2 : fragment de démarrage manquant

Expected:  1000(S)  1001(M)  1002(E)
Received:  [LOST]   1001(M)  1002(E)

Failure 3: Missing end fragment

Expected:  1000(S)  1001(M)  1002(E|marker)
Received:  1000(S)  1001(M)  [LOST]

Le réassembleur ne voit jamais le fragment final. La limite de l'unité NAL n'est jamais confirmée. Le décodeur attend davantage de données qui n'arrivent jamais.

Symptômes:

La vidéo se fige
Le décodeur signale "image manquante dans l'unité d'accès"
La lecture s'arrête jusqu'à l'arrivée de la prochaine unité d'accès complète

Échec 4 : fragments dans le désordre

Expected:  1000(S)  1001(M)  1002(E)
Received:  1000(S)  1002(E)  1001(M)

Diagnostic workflow

Step 1: Confirm H.264 payload mapping

m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=4D0029;sprop-parameter-sets=...

packetization-mode=1 signifie le mode non entrelacé (FU-A est pris en charge)
packetization-mode=0 signifie mode d'unité NAL unique (pas de fragmentation — très limité)

Étape 2 : Suivre les numéros de séquence RTP

Dans votre capture, regardez les numéros de séquence RTP de la piste vidéo. Les lacunes indiquent une perte de paquets :

Seq 1000: FU-A Start, NAL type 5 (IDR)
Seq 1001: FU-A middle
Seq 1003: FU-A End, marker=1   ← gap at 1002

Step 3: Inspect FU-A headers

Byte 0 (FU indicator):
  0x7C = NRI=3, Type=28 (FU-A)

Octet 1 (en-tête FU) :
  0x85 = S=1, E=0, R=0, Type=5 (tranche IDR) ← fragment de départ de l'IDR
  0x45 = S=0, E=0, R=0, Type=5 ← fragment central
  0x65 = S=0, E=1, R=0, Type=5 ← fragment final ; marqueur seulement si cette NAL termine l'unité d'accès

Mauvaises valeurs à rechercher :

S=1 sur un paquet non-start → confusion réassembleur
Marqueur activé avant E=1 → fausse limite d'unité d'accès
E=1 sans marqueur peut être valide si une autre unité NAL suit
Modifications du type en cours de séquence → bug de l'encodeur ou corruption du flux

Étape 4 : Vérifiez le remontage complet

Pour chaque unité NAL :

Trouvez le fragment de départ (S=1)
Suivez les numéros de séquence consécutifs jusqu'au fragment final (E = 1)
Comptez les fragments ; vérifier qu'il n'y a aucune lacune dans la séquence
Comparez le marqueur à la limite de l'unité d'accès ; ne l'exigez pas sur chaque fragment final FU-A
Vérifiez que tous les fragments ont le même horodatage et le même type NAL

Étape 5 : Comparez les modes de transport

Exécutez le même flux sur UDP et TCP entrelacés. Si la vidéo est propre sur TCP mais corrompue sur UDP, le problème est une perte de paquets réseau, et non des problèmes d'encodeur ou de décodeur.

Étape 6 : Analyse IDR vs non-IDR

Les trames IDR sont plus grandes et nécessitent plus de fragments FU-A par unité NAL. Plus de fragments = plus d'exposition à la perte de paquets. Si la corruption apparaît principalement lors des changements de scène ou toutes les quelques secondes (à l’intervalle IDR), les images IDR en sont la victime.

Options de correction :

Réduisez la taille de l’image IDR (réduisez la résolution ou le débit pour les images clés)
Augmentez l'intervalle IDR (moins de trames volumineuses, mais récupération plus lente après une perte)
Réduisez le MTU pour FU-A au niveau de l'encodeur (plus de fragments, mais chacun est plus petit et moins susceptible de déclencher une fragmentation IP)

Stratégies de rétablissement

Au réassembleur

Supprimez entièrement les unités d'accès endommagées plutôt que de transmettre des données partielles au décodeur.
Demander une nouvelle trame IDR via RTCP (si pris en charge par la caméra)
Attendez la prochaine trame IDR (le décodeur récupérera automatiquement)

Au niveau de l'encodeur

Réduisez la limite de taille de l’unité NAL pour réduire le nombre de fragments par unité d’accès
Utilisez une actualisation intra périodique au lieu d'images IDR complètes (images clés plus petites)
Activer FEC (forward error correction) si la pile RTP le prend en charge

Au réseau

Passer d'UDP à TCP entrelacé si la perte de paquets est inévitable
Assurez-vous que la découverte du chemin MTU fonctionne (évitez la fragmentation IP)
Prioriser le trafic RTP sur les liens encombrés

Quand ce n'est pas FU-A

Toutes les corruptions H.264 ne sont pas des fragmentations FU-A. Vérifier:

SPS/PPS manquant : Erreurs de décodeur telles que "PPS non existant" — vérifiez les jeux de paramètres sprop SDP
Mauvais profil/niveau : Le décodeur ne peut pas gérer la complexité du flux
Bogue de l'encodeur : L'encodeur produit une syntaxe d'unité NAL non valide
Corruption du flux binaire à la source : L'encodeur de la caméra est cassé, pas le réseau

Si les paquets RTP arrivent avec des numéros de séquence parfaits et des en-têtes FU-A corrects, mais que le décodeur échoue toujours, le problème réside dans le flux binaire H.264 lui-même, et non dans le transport.

Preuve reproductible pour « Correction de la fragmentation RTP H.264 FU-A : pourquoi votre vidéo RTSP est interrompue (perte de paquets, réassemblage NAL) »

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 « Correction de la fragmentation RTP H.264 FU-A : pourquoi votre vidéo RTSP est interrompue (perte de paquets, réassemblage NAL) », 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 à « Correction de la fragmentation RTP H.264 FU-A : pourquoi votre vidéo RTSP est interrompue (perte de paquets, réassemblage NAL) » est la suivante : Répare la vidéo RTSP cassée à partir de la fragmentation RTP H.264 FU-A. Couvre les fragments manquants, les bogues de bits de début/fin, les échecs de réassemblage NAL, la perte de paquets, la MTU et les erreurs de décodeur avec de vraies commandes de diagnostic. 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 : Correction de la fragmentation RTP H.264 FU-A : pourquoi votre vidéo RTSP est interrompue

Vérifiez « Correction de la fragmentation RTP H.264 FU-A : pourquoi votre vidéo RTSP est interrompue (perte de paquets, réassemblage NAL) » 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 : Répare la vidéo RTSP cassée à partir de la fragmentation RTP H.264 FU-A. Couvre les fragme

Si « Répare la vidéo RTSP cassée à partir de la fragmentation RTP H.264 FU-A. Couvre les fragments manquants, les bogues de bits de début/fin, les échecs d » 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 : The fast answer

Vérifiez « The fast answer » 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 : Why fragmentation exists

Si « Why fragmentation exists » 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 : The structure of an FU-A packet

Vérifiez « The structure of an FU-A packet » 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 : The RTP marker bit

Si « The RTP marker bit » 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 : Failure modes: what breaks and why

Vérifiez « Failure modes: what breaks and why » 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 : Failure 1: Missing middle fragment

Si « Failure 1: Missing middle fragment » 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 : Échec 2 : fragment de démarrage manquant

Vérifiez « Échec 2 : fragment de démarrage manquant » 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 : Failure 3: Missing end fragment

Si « Failure 3: Missing end fragment » 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
Correction de la fragmentation RTP H.264 FU-A : pourquoi votre vidéo RTSP est interrompue (perte de paquets, réassemblag	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Répare la vidéo RTSP cassée à partir de la fragmentation RTP H.264 FU-A. Couvre les fragments manquants, les bogues de b	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
The fast answer	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Why fragmentation exists	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
The structure of an FU-A packet	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
The RTP marker bit	É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 :