Résumé

  • RFC 2032 imposait qu’un paquet RTP commence et finisse à une frontière de macrobloc H.261 ; aucun macrobloc ne pouvait être partagé entre deux paquets.
  • L’en-tête répétait GOBN, MBAP, QUANT, HMVD/VMVD et les indicateurs I/V afin de recréer l’état de départ. Il rendait le paquet suivant interprétable, sans recréer la zone d’image perdue.
  • Les messages optionnels FIR et NACK formulaient une demande de trame INTRA ou désignaient des numéros de séquence manquants. Ils décrivaient une intention de réparation, pas son accomplissement.

Dans une vidéo compressée, retrouver la grammaire ne signifie pas retrouver l’image. RFC 2032 avait précisément organisé cette différence.

Publié en octobre 1996 comme Proposed Standard, le texte décrivait le transport direct d’un flux H.261 dans RTP. H.261 venait du monde RNIS à débit fixe, où des trames H.221 de 512 bits pouvaient réunir vidéo, son, données et correction d’erreurs. Le format Internet ne transportait pas ces trames. Il prenait le flux vidéo codé en Huffman et construisait autour de lui des frontières capables de survivre à la perte d’un datagramme.

Une coupure choisie pour limiter la panne

Une image H.261 se compose de groupes de blocs, chacun comprenant 33 macroblocs. Un macrobloc représente une zone de 16 par 16 pixels. RFC 2032 en fait l’unité de fragmentation : début et fin de paquet doivent coïncider avec une frontière de macrobloc, et la coupure entre un en-tête GOB et son premier macrobloc est interdite.

Le choix répond à une contrainte du code à longueur variable. Après une perte survenue au milieu d’une suite Huffman, le récepteur risque de ne plus savoir où commence le prochain champ. Une frontière déclarée, assortie de son contexte, fournit au paquet reçu ensuite un nouveau point d’entrée.

Ce redémarrage reste syntaxique. H.261 utilise la prédiction inter-image et des différences. Un macrobloc parfaitement analysé peut dépendre d’une image de référence dont la même zone a été perdue. Le RFC indique que la corruption peut persister jusqu’à ce que les macroblocs concernés soient à nouveau codés en mode INTRA. La frontière empêche l’incertitude de dévorer tout le flux ; elle ne répare pas le passé.

L’en-tête emportait la mémoire minimale

Les 32 bits de l’en-tête de charge utile décrivent l’état au point de reprise. SBIT et EBIT indiquent les bits étrangers à la vidéo au début et à la fin des octets extrêmes. Ils permettent d’insérer une grammaire orientée bits dans des paquets alignés sur les octets.

GOBN identifie le groupe où commence le paquet ; zéro signifie qu’un en-tête d’image ouvre la charge utile. MBAP contient le prédicteur d’adresse du macrobloc, relatif au début du GOB. QUANT conserve la valeur de quantification applicable au prochain macrobloc. HMVD et VMVD restituent les références horizontale et verticale nécessaires aux différences de vecteurs de mouvement.

Ce sont des données de contexte, pas des attestations de contenu. MBAP ne localise pas une zone réparée à l’écran : il rend une différence d’adresse décodable. HMVD et VMVD rendent le calcul du vecteur possible, mais ne valident pas l’image de référence vers laquelle il pointe.

Les bits I et V sont eux aussi des indications prudentes. I annonce un flux exclusivement INTRA ; V signale la possibilité de vecteurs de mouvement. Le RFC précise qu’ils peuvent être déduits du flux et autorise une mise en œuvre à employer les valeurs conservatrices V=1 et I=0. Ils orientent un décodeur ; ils ne contrôlent pas chaque macrobloc et ne mesurent pas la qualité.

La fin de trame n’était pas un certificat d’intégrité

Tous les paquets d’une même image partagent un horodatage RTP à 90 kHz. Le bit marker vaut un dans le dernier paquet d’une trame, de sorte que le récepteur puisse lancer l’affichage sans attendre le prochain code de début d’image. Si un paquet contient plusieurs images, l’horodatage RTP ne vaut que pour la première ; les suivantes dépendent des en-têtes H.261.

Ces signaux situent une image dans le temps et indiquent sa clôture déclarée. Un marker ne dit pas que tous les numéros de séquence antérieurs ont été reçus. RTP permet de constater un trou ; UDP n’informe pas spontanément l’émetteur du succès d’une livraison. « Le dernier paquet est arrivé » et « la trame est complète » restent deux faits distincts.

Circonscrire une erreur ne la corrigeait pas

RFC 2032 décrit trois voies de réduction des dommages : envoyer périodiquement une image entièrement INTRA, adapter le rythme de rafraîchissement aux pertes, ou accepter une demande de rafraîchissement après détection d’une perte. Chacune ouvre une boucle de contrôle possible. Aucune ne fournit seule la preuve que cette boucle s’est fermée.

Grâce aux frontières et au contexte répété, le décodeur peut reprendre après le paquet manquant. Mais les données absentes restent absentes ; une mauvaise référence peut contaminer les prédictions ; une correction arrivée après l’échéance d’affichage n’améliore pas l’image déjà montrée. Le format assure la continuité de l’interprétation, pas celle de l’expérience.

FIR et NACK donnaient des coordonnées au retour

Deux messages RTCP propres à H.261 étaient proposés. Full INTRA-frame Request, avec le Payload Type 192, demandait que la prochaine image soit entièrement codée en INTRA ; le SSRC désignait le récepteur demandeur. Negative Acknowledgement, avec le type 193, utilisait FSN pour le premier numéro de séquence réputé perdu et un masque de 16 bits pour les seize numéros suivants.

FIR demande de remplacer la base de prédiction. NACK décrit un petit ensemble de positions absentes dans l’espace des séquences. Cette concision est utile pour diagnostiquer et adresser une action.

Le mécanisme demeurait optionnel. Le texte avertissait que les acquittements négatifs pouvaient devenir nocifs dans les sites comptant beaucoup de participants. L’envoi direct du décodeur vers le codeur supposait aussi l’absence de mixer ou de translator. L’exemple IVS n’activait le retour que pour un petit nombre de récepteurs. Topologie, échelle et support logiciel faisaient donc partie des conditions de vérité.

Observer un FIR prouve qu’une demande a été émise, non qu’elle a franchi le chemin retour ou déclenché une image INTRA. Observer un NACK prouve quels paquets le récepteur juge manquants, non qu’une retransmission existe ou arrive avant l’affichage. Sans observation de l’autre extrémité puis du décodeur, la coordonnée de réparation reste une promesse en transit.

Le standard s’arrêtait avant le résultat

Le principe de spécification initiale minimale de Lu Heng éclaire ce partage. RFC 2032 fixe ce que deux implémentations doivent partager : points de coupure, contexte de reprise, temps, fin de trame et syntaxe de retour. Le tampon, le rythme de rafraîchissement, le coût d’une trame INTRA et la tolérance au retard restent des décisions locales.

La primauté du code en fonctionnement impose alors une chaîne de preuves. Le dessin d’un champ publié, le champ correctement produit, le paquet livré, la demande exécutée et l’image affichée à temps sont des réalités différentes. Le vocabulaire de la première ne peut servir de preuve à la dernière.

RFC Editor marque aujourd’hui RFC 2032 comme remplacé par RFC 4587. Sans ouvrir l’histoire du successeur, la leçon reste nette : le texte avait réduit l’étendue de l’inintelligible et fourni une adresse à l’intention de réparer. Il n’avait jamais déclaré l’image réparée.

Sources