Résumé

  • RFC 9828 permet d’émettre le premier paquet RTP avant que le codestream JPEG 2000 complet existe, sous un contrat précis de progression à une seule tuile.
  • Les champs de resynchronisation, de séquence étendue, de temps, de qualité et de résolution aident le récepteur ; ils ne constatent ni sa reprise ni l’image affichée.
  • Une réception responsable relie la négociation, la progression d’encodage, le réseau, l’état du décodeur et une mesure capture-écran sur une horloge commune.

RFC 9828, Proposed Standard de l’IETF publié en août 2025, définit un payload RTP pour video/jpeg2000-scl. Une image JPEG 2000 est un codestream autonome composé de segments marqueurs et de données codées. Son main header, entre SOC et le premier SOT, gouverne l’ensemble et reste généralement indispensable au décodage. Le format distingue les Main Packets porteurs de l’Extended Header des Body Packets qui ne doivent pas en contenir.

Cette division rend possible le chevauchement entre encodage et transport. Elle ne l’autorise pas pour toute disposition. ORDH décrit l’ordre de progression et l’annonce des points de reprise ; seules les valeurs 4 (PCRL) et 6 (PRCL) permettent la sub-codestream latency. Un codestream à plusieurs tuiles impose ORDH=0. Le premier paquet n’a donc de sens probant qu’avec le nombre de tuiles, l’ordre réel et l’arrivée des Main Packets nécessaires.

Un Body Packet peut annoncer un resync point par ORDB, en donner l’offset par POS et le precinct par PID. Le récepteur peut alors traiter une partie ultérieure après corruption, perte ou filtrage volontaire de paquets antérieurs. Le mécanisme ne restaure aucun octet perdu. Il est indisponible pour plusieurs tuiles et ne prouve pas que le décodeur possédait le bon header, a repris au bon endroit ou a produit une image acceptable.

La continuité de transport a sa propre portée. Les 16 bits de séquence RTP forment les bits faibles, ESEQ fournit huit bits forts. Le nombre étendu de 24 bits traverse le bouclage court, mais un trou peut venir d’une perte, d’un filtrage par qualité, d’un réordonnancement ou du point de capture. Le numéro n’est pas un accusé de livraison.

Tous les paquets d’une image partagent le timestamp RTP de présentation à 90 kHz. PTSTAMP ajoute un échantillon de 12 bits du temps de transmission. Il peut accélérer la récupération de l’horloge émettrice, à condition d’être exact ; deux paquets consécutifs au même timestamp ne peuvent s’écarter de plus de 4095 ticks, environ 45 ms. RFC 5450 couvre le cas plus général d’un envoi décalé par rapport au temps nominal. Ni l’un ni l’autre ne constate l’alignement capture, jitter buffer, décodage et scan-out.

QUAL et RES rendent un filtrage explicable : on peut abandonner les paquets qui ne contribuent qu’aux couches de qualité ou résolutions supérieures. Une image réduite peut être une dégradation prévue, pas la preuve du service complet. Avec R=1, des informations de main header sont réutilisables ; avec C=1, des code-blocks mis en cache remplacent des blocs vides. Le RFC souligne que l’émetteur ignore l’état exact du cache récepteur, notamment après perte ou arrivée tardive.

Le registre IANA video/jpeg2000-scl prévoit formats pixel/sample, dimensions maximales, structure du signal et capacités définies par l’application. SDP transporte la déclaration ; un paramètre absent reste indéterminé. L’admission réelle dépend du profil du décodeur, de sa mémoire et de ses limites. La syntaxe pouvant annoncer jusqu’à 2^32−1 pixels par dimension, le RFC demande de borner les ressources et d’échouer proprement.

RFC 3550 fournit le cadre RTP et RFC 5371 le contexte JPEG 2000 antérieur. La fiche RFC Editor, le texte, le Datatracker et la recherche d’errata bornent le document, sans établir déploiement ni performance.

La lecture applique Running-Code Primacy comme discipline : le contrat commun coordonne, l’exécution décide du résultat. Minimum Initial Specification sépare le minimum commun des choix locaux du récepteur ; Reality, Not Advocacy interdit de prolonger la conclusion au-delà des traces. Cette application appartient à l’auteur, pas à l’IETF.

La chaîne complète va donc du contrat de session au codestream admissible, puis à l’envoi, au réseau, à l’état header/cache, à la reprise, au résultat décodé et enfin au temps capture-écran. Le premier paquet n’en ferme qu’une étape.