Résumé

  • L’IESG a approuvé draft-ietf-avtcore-rtp-jpegxs-3ed-07 comme Proposed Standard le 14 septembre, mais le document n’avait toujours pas de numéro RFC le 21 septembre et le RFC Editor attendait une réponse des auteurs.
  • Le texte maintient la validité des implémentations conformes à RFC 9134 dans le périmètre qu’elles savent traiter ; il ne transforme pas un ancien décodeur en décodeur TDC.
  • Un reçu de compatibilité d’édition doit relier l’état documentaire aux deux versions logicielles, aux paramètres SDP, à un repli sans TDC et à un essai média délimité.

Dans une chaîne vidéo, le mot « approuvé » décrit un document. Il ne dit pas encore si l’image arrive. Entre la décision de l’IESG et le moniteur de destination se trouvent le RFC Editor, IANA, les versions de produits, la description de session, le comportement des tampons et la décision d’activer la fonction en production.

Le 14 septembre 2026, l’IESG a approuvé la révision 07 de RTP Payload Format for ISO/IEC 21122 (JPEG XS) en vue de sa publication comme Proposed Standard. Deux précautions de vocabulaire s’imposent. Un Proposed Standard n’est pas un Internet Standard. Et une Protocol Action n’est pas la publication d’un RFC.

Le relevé public du 21 septembre montre précisément l’entre-deux. Datatracker place le projet dans la file du RFC Editor. La file signale un formulaire initial encore attendu et un besoin de réponse des auteurs. Aucun numéro RFC n’est attribué. L’examen IANA doit être repris après le changement de version. La fiche publique video/jxsv continue de citer RFC 9134. Rien de cela ne constitue un rejet technique ; ce sont des états de production documentaire qu’il serait inexact de masquer sous l’expression « nouveau RFC ».

Une substitution documentaire n’éteint pas les équipements

La révision 07 prévoit que le futur RFC rendra RFC 9134 obsolète. Dans la série RFC, cette relation désigne le texte qui devient la référence. Elle ne désactive pas un appareil, n’annule pas un firmware et ne rend pas illisible un flux non-TDC au jour de la publication.

Les auteurs ont recherché une transition incrémentale. Les implémentations conformes à RFC 9134 restent valides selon la spécification révisée, et les systèmes anciens demeurent opérationnels dans leur ensemble de fonctions pris en charge. La limite est contenue dans cette dernière formule. La continuité de l’ancien périmètre ne vaut pas prise en charge des nouvelles fonctions.

TDC crée une dépendance temporelle

Les deux premières éditions de JPEG XS utilisaient le codage intra. La troisième ajoute le Temporal Differential Coding, ou TDC, qui effectue une décorrélation entre images dans le domaine des ondelettes. Un codestream sans TDC peut être décodé comme une image autonome. Un codestream TDC peut dépendre de coefficients reconstruits conservés depuis le codestream précédent : un tampon pour la vidéo progressive et deux tampons, un par champ, pour l’entrelacé et le PsF.

La révision intègre donc le marqueur SLI des tranches TDC et le paramètre fbblevel, qui décrit le niveau de bande passante du tampon d’image. fbblevel n’est présent que lorsque TDC est utilisé. Comme profile, level et sublevel, sa valeur doit correspondre à celle du segment d’image JPEG XS.

Un ancien récepteur peut ainsi rester parfaitement conforme et utile pour des flux sans TDC, tout en étant incapable de reconstruire un profil TDC. La compatibilité annoncée concerne la conservation d’un chemin valide, pas l’apparition magique d’une nouvelle capacité.

L’offre SDP fixe le périmètre de la séance

Le sous-type demeure video/jxsv. Le flux RTP utilise une horloge de 90 kHz et exige packetmode. SDP place jxsv/90000 dans a=rtpmap et transporte packetmode ainsi que les paramètres optionnels — notamment profile, level, sublevel et fbblevel — dans a=fmtp.

Pour une séance unicast en offre/réponse, la règle est nette : le répondant doit prendre en charge toutes les valeurs proposées, sinon il rejette la séance. S’il accepte, il renvoie les mêmes valeurs. L’offreur doit donc choisir un jeu que l’autre extrémité est censée comprendre.

Cette mécanique empêche une acceptation vague, mais elle ne garantit pas un repli automatique. Après le rejet d’une offre TDC, il faut vérifier que l’orchestrateur émet une nouvelle offre explicitement sans TDC. Et une réponse SDP positive ne prouve toujours pas le décodage du média, l’absence d’alarme de tampon ou la tenue d’un essai long.

Un reçu qui s’arrête à la bonne frontière

Le reçu de compatibilité d’édition proposé ici doit conserver : la révision 07 et son hash ; l’état IESG, RFC Editor et IANA ; le numéro RFC lorsqu’il existera ; le type média, l’horloge, packetmode, le profil, le niveau, le sous-niveau, fbblevel et l’activation de TDC ; les versions exactes de l’émetteur et du récepteur ; l’offre, la réponse ou le rejet ; le résultat du repli sans TDC ; l’identité et la durée des échantillons ; les défauts observés, leur correction, le nouvel essai, le retour arrière et la condition de sortie.

Le périmètre compte autant que le résultat. Une paire d’équipements, un profil et une séquence progressive ne valident pas tous les champs, passerelles et formats. À l’inverse, l’échec d’une séance TDC n’invalide pas le chemin sans TDC de RFC 9134. Le résultat utile est une phrase bornée : ces deux builds ont échangé ce flux, avec ces paramètres, dans ces conditions.

Sources

  1. Page Datatracker du projet JPEG XS RTP
  2. Historique du document
  3. Texte de la révision 07
  4. File du RFC Editor
  5. RFC 9134
  6. Enregistrement IANA de video/jxsv