Résumé

  • Chaque charge utile RTP CellB commence par quatre entiers non signés de 16 bits : X et Y localisent la première cellule de 4×4 pixels, puis la largeur et la hauteur décrivent l’image en pixels.
  • La RFC 2029 interdit qu’un code de plusieurs octets soit partagé entre deux paquets. Après une perte, le paquet intact suivant offre donc à la fois une frontière syntaxique et un point de reprise spatial.
  • Ce dispositif circonscrit l’erreur, mais ne recrée aucune donnée. Coordonnées, dimensions, horodatage commun et bit Marker ne prouvent ni la présence des cellules antérieures, ni l’accord des tables de quantification, ni la qualité du décodage ou de l’affichage.

Perdre un paquet vidéo, ce n’est pas seulement perdre ce qu’il transportait. C’est parfois perdre la grammaire nécessaire pour comprendre ce qui vient ensuite. Où commence la prochaine instruction ? À quel endroit de l’image ses données doivent-elles être posées ?

La RFC 2029 a répondu à ces deux questions pour CellB avec une économie remarquable. Publiée en octobre 1996, elle n’ajoutait pas un mécanisme de réparation des pixels manquants. Elle faisait en sorte qu’un paquet survivant transporte assez de contexte local pour ne pas dépendre entièrement de son prédécesseur.

Une adresse répétée dans chaque charge utile

L’en-tête CellB occupe huit octets au début de chaque charge utile RTP. Il contient la position X, la position Y, la largeur de l’image et sa hauteur. Tous les champs sont codés en ordre réseau.

X et Y ne sont pas des coordonnées de pixels. Ils comptent des cellules, chacune couvrant un bloc de 4×4 pixels. La largeur et la hauteur restent, elles, exprimées en pixels. Le paquet annonce donc simultanément son point de départ dans la grille CellB et les limites du canevas.

La taille de l’image ne peut changer qu’entre deux images, mais la RFC exige tout de même sa répétition. Cette redondance évite qu’un paquet ultérieur dépende d’une dimension portée seulement par un paquet perdu. Elle simplifie aussi l’encodage du paquet, selon le texte.

Une adresse n’est toutefois pas un constat d’huissier. Elle ne dit pas quelles cellules précédentes ont effectivement été reçues. Elle n’empêche pas un expéditeur d’annoncer une position incohérente et ne démontre pas que les charges utiles couvriront toute la surface déclarée. Elle indique où poursuivre, pas ce qui a été accompli avant ce point.

La perte ne devait pas couper une instruction en deux

Le flux CellB comprend plusieurs sortes de codes. Le code ordinaire d’une cellule mesure quatre octets. Un code d’un octet demande de sauter jusqu’à 32 cellules. Deux autres instructions annoncent le remplacement des tables de quantification Y/Y ou U/V et sont suivies, chacune, de 512 octets.

Un paquet peut avoir la taille choisie par l’implémenteur, jusqu’à contenir une image complète. Mais les codes de plusieurs octets doivent rester entièrement dans un seul paquet. La frontière réseau ne peut donc passer au milieu d’un code de cellule ou d’une mise à jour de table.

Ce choix est le complément exact des coordonnées. La coordonnée rétablit un contexte spatial ; la règle de confinement rétablit un contexte syntaxique. Après la disparition d’un paquet, le suivant ne se présente pas comme la fin orpheline d’une instruction commencée dans les octets perdus.

Il ne s’agit pourtant pas de récupération au sens de reconstruction. La RFC ne prévoit ni retransmission, ni code correcteur, ni répétition des cellules disparues. Elle réduit l’effet en cascade : le paquet manquant reste absent, mais il n’oblige pas nécessairement à abandonner tout ce qui suit.

La fin déclarée d’une image n’en certifie pas le contenu

Pour CellB, l’horloge RTP tourne à 90 kHz. Tous les paquets d’une même image emploient le même horodatage et le bit Marker en signale le dernier paquet. On obtient ainsi une enveloppe temporelle autour des blocs localisés dans l’espace.

Cette enveloppe n’est pas un inventaire. Un horodatage commun classe les paquets dans une image ; il n’en donne pas le nombre attendu. Le bit Marker signale la fin annoncée par l’émetteur ; il n’atteste pas que tout ce qui devait précéder est arrivé. Les numéros de séquence RTP permettent de repérer un trou et de remettre les paquets dans l’ordre, mais le protocole RTP ne garantit ni livraison, ni ponctualité, ni ordre d’arrivée, ni qualité de service.

On peut donc recevoir le paquet marqué comme final, connaître sa position et sa taille d’image, tout en ayant perdu une zone intermédiaire. Les métadonnées décrivent la place revendiquée par le paquet. Elles ne transforment pas la réception partielle en image complète.

Les tables montrent la dépendance qui subsiste

Un code de cellule CellB ne contient pas toutes les valeurs de couleur de ses seize pixels. Ses champs U/V et Y/Y sont des indices dans des tables de vecteurs de chrominance et de luminance. Le résultat dépend donc de l’état de ces tables chez le décodeur.

La RFC décrit des instructions capables de remplacer chaque table par 512 nouveaux octets. Les exemples de codec fournis avec le document n’utilisaient pas cette fonction, mais le texte la réservait à de futurs codecs. La règle de confinement garantit qu’une mise à jour reçue ne sera pas tronquée par une frontière de paquet.

Elle ne garantit pas la réception du paquet entier. Si la mise à jour disparaît, un paquet ultérieur peut être parfaitement aligné, correctement localisé et rattaché au bon horodatage, tout en étant interprété à l’aide d’une ancienne table. La destination du bloc est connue ; sa couleur peut être fausse.

Cette conclusion n’est pas le récit d’un incident cité par la RFC. C’est la limite logique de son format. L’autonomie spatiale et syntaxique d’un paquet ne supprime pas toutes les dépendances d’état.

Lire séparément les traces disponibles

Une enquête devrait distinguer la séquence de transport, la position annoncée, la validité syntaxique et le résultat visuel. Le numéro de séquence peut révéler une absence. L’en-tête CellB donne une position et un canevas déclarés. Le confinement des codes protège le point de parsing. L’horodatage et Marker regroupent les paquets en images.

Pour affirmer que l’image a été correctement décodée, il faut davantage : les charges utiles capturées, la couverture effective des coordonnées, la version des tables, le résultat du décodeur et le rendu. Pour parler de qualité perçue, il faut encore une mesure au point de lecture.

L’IANA conserve aujourd’hui CelB comme type de charge utile RTP fixe 25, vidéo à 90 000 Hz, avec la RFC 2029 en référence. Cette inscription prouve une attribution de paramètre. Elle ne mesure ni déploiement actuel ni interopérabilité. De même, le statut Proposed Standard de la RFC n’est pas un reçu de fonctionnement.

La contribution historique de la RFC 2029 tient à cette modestie technique. Huit octets donnent au paquet intact suivant un lieu où recommencer ; une règle de découpage lui donne une instruction complète. Le dommage devient localisable. L’image, elle, reste à prouver.

Sources