Résumé

  • Les bits Beginning-of-slice et End-of-slice de la RFC 2038 indiquaient comment la charge RTP rencontrait une frontière de tranche MPEG. Le prochain point de reprise devenait repérable sans analyse préalable de tous les octets de la charge.
  • Chaque paquet vidéo répétait la référence temporelle TR, le type d’image P et, selon ce type, les paramètres des vecteurs de mouvement. Ces champs pouvaient alimenter la reconstruction limitée d’un en-tête GOP ou Picture Header perdu.
  • Un trou de séquence RTP et des champs B/E, TR/P cohérents autorisent une décision locale de reprise. Ils ne prouvent ni la présence des tranches antérieures, ni la véracité des en-têtes, ni la disponibilité des images de référence, ni un décodage correct ou une lecture continue.

Imaginons un récepteur qui conserve encore le paquet 782, puis reçoit directement le 784. Le second paquet ne commence pas au milieu d’une tranche : son bit B est à un. Il annonce aussi la référence temporelle et le type de l’image, avec les paramètres de mouvement nécessaires à ce type. Le récepteur peut cesser de poursuivre des octets devenus dépendants d’un début absent et remettre la tranche suivante au décodeur.

Il n’a pourtant pas retrouvé le paquet 783.

Cette distinction est toute la force de la RFC 2038. En 1996, elle n’a pas ajouté une promesse abstraite de robustesse à MPEG. Elle a placé, à côté des données compressées, assez d’information locale pour circonscrire la perte. Le transport pouvait reconnaître un endroit où recommencer ; l’image, elle, restait soumise à ses dépendances temporelles et spatiales.

Le dommage se propageait par le contexte

Dans une suite vidéo compressée, des octets intacts peuvent devenir inutiles si leur contexte a disparu. Une image prédite dépend d’images de référence. Une portion de tranche peut dépendre d’un code de départ contenu dans un paquet précédent. Un Picture Header perdu retire au décodeur le type de l’image et certains paramètres de mouvement.

La RFC 2038 décrit explicitement ce problème : MPEG avait été conçu pour un environnement relativement peu sujet aux erreurs, avec de nombreuses dépendances internes. Les grandes images devaient toutefois être fragmentées en paquets compatibles avec les MTU des réseaux. La frontière du réseau risquait donc de couper à travers la structure dont le décodeur avait besoin pour se resynchroniser.

Le format imposait d’abord une discipline aux en-têtes MPEG. Un Video Sequence Header devait commencer une charge RTP lorsqu’il était présent. Un GOP Header commençait la charge ou suivait ce premier en-tête. Un Picture Header commençait la charge ou suivait le GOP Header. Chacun devait rester entièrement contenu dans un paquet.

Ces règles protégeaient une frontière syntaxique. Elles ne rendaient pas l’en-tête infaillible et n’empêchaient pas la perte de son paquet.

La tranche devint un événement observable par le transport

MPEG organisait chaque image en une ou plusieurs tranches et destinait la tranche à servir d’unité de récupération après erreur. La RFC 2038 a repris cette unité au lieu d’inventer un point de reprise propre au réseau.

Le début d’une tranche devait être la première donnée de la charge, après les seuls en-têtes MPEG autorisés, ou suivre un nombre entier de tranches déjà complètes dans le même paquet. Une tranche pouvait toujours s’étendre sur plusieurs paquets. Le principe n’était donc pas « un paquet, une tranche », mais « un début de tranche ne se cache pas derrière un fragment arbitraire ».

Le bit B déclarait que la charge commençait sur ce début, éventuellement après les en-têtes Video Sequence, GOP ou Picture. Le bit E déclarait que le dernier octet de la charge terminait une tranche. Avant même de décoder la vidéo, le récepteur connaissait ainsi l’alignement annoncé du paquet.

Les quatre combinaisons avaient un sens : B et E ensemble pouvaient encadrer une matière alignée sur les tranches ; B seul ouvrait une tranche continuée ailleurs ; E seul terminait une tranche commencée auparavant ; aucun des deux signalait un fragment intermédiaire. Cette carte évitait une recherche coûteuse de code de départ après un trou.

Mais une carte n’est pas le territoire. B ne garantit pas que le premier code soit réellement valide. E ne dénombre pas les fragments précédents. Même B=1 et E=1 ne signifie pas que toutes les tranches de l’image sont arrivées.

Un état d’image minimal voyageait avec chaque paquet

Le second choix de la RFC 2038 fut la répétition. Son en-tête vidéo de 32 bits accompagnait chaque paquet, pas seulement le premier de l’image.

TR était une référence temporelle de dix bits, de 0 à 1023, constante dans tous les paquets de la même image au sein du GOP. P identifiait le type I, P, B ou D, lui aussi constant dans l’image. Quatre champs supplémentaires reprenaient depuis le Picture Header le mode full-pel et les f-codes des vecteurs arrière et avant.

La combinaison dépendait du type. Une image I mettait les quatre champs de mouvement à zéro. Une image P conservait la paire avant et annulait la paire arrière. Une image B pouvait utiliser les quatre. Cette régularité donnait à un paquet tardif plus qu’une frontière : elle lui donnait une description compacte de l’image dans laquelle il prétendait se trouver.

Le mot « compacte » est essentiel. Ces champs ne copiaient pas l’intégralité du Picture Header. Ils constituaient les entrées minimales retenues par la stratégie de reprise. Leur présence n’attestait ni la valeur originale perdue, ni la disponibilité des références nécessaires au calcul des blocs prédits.

Un changement inattendu signalait une rupture, pas sa cause

L’annexe 1 proposait de suivre deux compteurs, l’un pour les images de référence I/P et l’autre pour les images dépendantes B. Le récepteur comparait leur progression attendue avec TR et P. Une discordance pouvait signaler la perte d’un GOP Header ou d’un Picture Header.

Ce signal transformait une incohérence en action possible. Un GOP Header pouvait être reconstruit avec un time code nul, le drapeau closed_gop précédent et broken_link à un. Au prochain paquet B=1, un Picture Header pouvait être formé avec P, TR, les champs de mouvement et des valeurs par défaut propres au flux.

Rien dans cette opération ne restitue l’original. Le time code nul est un remplacement. Le drapeau repris vient de l’histoire locale du récepteur. La valeur par défaut est une hypothèse. Et broken_link reconnaît précisément que la continuité prédictive a été rompue.

La RFC qualifiait d’ailleurs ces stratégies de simples recommandations. Un récepteur conforme pouvait choisir une autre méthode ou aucune. Le format exposait des possibilités ; il n’imposait pas un résultat de décodage.

Jeter jusqu’à B limitait l’incertitude

Lorsque la perte d’un paquet était indiquée par un trou dans les numéros de séquence RTP, l’annexe autorisait le récepteur à jeter tous les paquets jusqu’au prochain B=1. À ce point, il disposait d’un état suffisant pour essayer de traiter le flux au début de la tranche suivante, avec reconstruction éventuelle des en-têtes.

Ce comportement peut sembler gaspiller des données intactes. C’est justement son rôle. Les octets entre le trou et la frontière suivante peuvent être physiquement présents, mais dépendre d’un début absent. Les accepter aveuglément transformerait la réception en spéculation. Les abandonner transforme une incertitude non bornée en perte locale et explicite.

Le numéro de séquence n’établit toutefois qu’une discontinuité observée. RTP incrémente ce numéro à chaque paquet émis, mais ne garantit ni livraison, ni ordre, ni délai, ni qualité de service. Réordonnancement, capture incomplète et conditions du chemin restent à examiner. Un trou ne nomme pas sa cause.

La chaîne de preuve comporte plusieurs étages

Une lecture opérationnelle doit séparer au moins sept objets : la continuité de séquence RTP ; les déclarations B/E ; la syntaxe MPEG réellement analysée ; les valeurs TR/P et de mouvement ; l’état des images de référence ; le résultat du décodeur ; enfin la lecture temporelle et l’observation du public.

Chaque étage peut déclencher le suivant. Aucun ne le remplace. Les bits de frontière n’attestent pas le contenu. L’état répété n’atteste pas l’en-tête perdu. Une tranche acceptée n’atteste pas une image complète. Une image produite n’atteste pas une présentation continue. Et un événement du lecteur n’atteste pas, sans mesure supplémentaire, ce qu’un spectateur a effectivement vu.

La RFC 2038 fut publiée comme Proposed Standard en octobre 1996, puis remplacée par la RFC 2250 en janvier 1998. Le registre IANA conserve le type statique 32, MPV, à 90 kHz, avec la RFC 2250 comme référence. Ce sont des faits de normalisation et d’enregistrement, non des preuves de déploiement actuel ou de qualité.

La leçon historique demeure précise : rendre la vraie unité de reprise du codec visible au niveau du paquet réduit le rayon d’une perte. Cela ne transforme pas une possibilité de reprise en preuve que l’image a survécu.

Sources