Résumé

  • Le champ MHF de RFC 5371 indique si un paquet ne contient aucun en-tête principal, un fragment intermédiaire, le dernier fragment ou un en-tête entier. Recevoir la dernière pièce ne prouve pas que les pièces précédentes existent encore.
  • Dans le contrat de base, l’émetteur devrait mettre mh_id à zéro et le récepteur devrait l’ignorer. La compensation d’en-tête et la sémantique de cet identifiant relèvent de l’extension RFC 5372, pas d’une lecture implicite des bits.
  • Un contrôle sérieux relie l’offre SDP, les intervalles d’octets reçus, les drapeaux de validité, les sessions RTP attendues, l’admission du décodeur et l’image affichée. Aucun de ces reçus ne remplace les autres.

Une fin n’est pas une totalité

Dans une capture, MHF=2 paraît rassurant. La valeur signifie « dernière partie d’un en-tête principal fragmenté ». Elle permet de reconnaître une frontière. Elle ne signifie ni « en-tête complet reçu » ni « image désormais décodable ».

Supposons trois paquets. Le premier transporte le début de l’en-tête, le deuxième sa partie centrale et le troisième sa fin. Si le deuxième disparaît, le troisième reste bien la dernière partie. Son drapeau demeure vrai. Le problème vient de l’inférence ajoutée après coup : la fin observée ne témoigne pas de la continuité qui la précède.

RFC 5371 réserve quatre états à MHF. Zéro exclut l’en-tête principal du payload. Un indique une partie non finale d’un en-tête fragmenté. Deux indique sa partie finale. Trois indique qu’un en-tête principal entier se trouve dans le payload. Ces valeurs décrivent le contenu courant ; elles ne tiennent pas le registre des paquets perdus.

Cette modestie est une force. Un protocole utile n’a pas besoin de prétendre connaître l’état du récepteur. Il doit rendre les observations interprétables. Le devoir d’une chaîne de preuve est ensuite d’associer la valeur à la séquence RTP, à l’offset absolu, aux intervalles reçus et au résultat de parsing.

Sans en-tête principal, les octets suivants perdent leur grammaire

Le texte de RFC 5371 établit une dépendance dure : si l’en-tête principal est perdu, l’image ne peut pas être décodée. Les données des tiles peuvent être intactes, authentifiées et correctement positionnées ; elles n’ont plus le contexte commun nécessaire à leur interprétation.

Cela inverse une intuition fréquente. Dans un flux volumineux, on peut traiter l’en-tête comme une petite surcharge et le corps comme la valeur. Ici, la petite partie porte l’autorité syntaxique. Son absence peut rendre inutiles beaucoup plus d’octets qu’elle n’en contenait.

Le registre opérationnel doit donc distinguer au moins trois événements : les fragments qui affirment transporter l’en-tête, la continuité réelle des octets de cet en-tête et l’acceptation de l’ensemble par le décodeur. Un compteur de paquets ne suffit pas. Un taux d’octets reçus ne suffit pas non plus.

L’annexe informative recommande de séparer les en-têtes du reste du codestream afin de faciliter la récupération. C’est une recommandation d’agencement, non la preuve que l’émetteur l’a suivie. Même séparé, un paquet d’en-tête peut être perdu. La topologie de capture et le mécanisme de reprise doivent être observés.

mh_id n’était pas encore un passeport

À côté de MHF, les trois bits mh_id semblent offrir exactement ce qu’un système de reprise désire : un identifiant d’en-tête principal. Pourtant, RFC 5371 dit aux implémentations limitées à son seul contrat de mettre cette valeur à zéro côté émetteur et de l’ignorer côté récepteur.

Ce choix empêche une sémantique incomplète de devenir une dépendance d’interopérabilité. Le champ réserve un emplacement, mais le contrat de base ne lui délègue pas la décision de compensation.

RFC 5372 définit l’extension. Il relie mh_id à la stabilité des paramètres d’encodage, précise quand l’incrémenter, comment gérer le retour après sept et dans quelles conditions un récepteur peut conserver un en-tête pour compenser sa perte.

Une plateforme qui lit mh_id=0 dans un flux RFC 5371 et annonce « en-tête version zéro récupéré » invente un état. Une autre qui applique les règles RFC 5372 sans avoir négocié l’extension mélange deux contrats. Dans les deux cas, la donnée est réelle et l’interprétation est fausse.

La provenance doit inclure le régime sémantique. Il faut savoir non seulement quelle valeur occupait les bits, mais aussi quel RFC, quel paramètre SDP et quelle capacité du récepteur autorisaient son emploi.

Le numéro de tile avait lui aussi un droit de silence

RFC 5371 place un numéro de tile sur seize bits dans l’en-tête du payload. Mais le drapeau T commande sa validité. T=0 rend le numéro exploitable ; T=1 ordonne au récepteur de l’ignorer.

Deux cas imposent l’invalidation. Un payload qui ne transporte que l’en-tête principal ne contient aucune tile-part à numéroter. Un payload qui réunit plusieurs tile-parts ne peut pas être décrit par un seul numéro.

Le champ physique peut alors contenir des bits. Ces bits n’ont pas d’autorité de classement. Les conserver est utile pour reproduire le paquet ; les agréger comme numéro de tile est une faute de modèle.

Cette distinction intéresse la gouvernance des données bien au-delà du codec. Les pipelines analytiques aiment les colonnes indépendantes. Or la valeur d’une colonne dépend souvent d’un masque, d’un drapeau ou d’une capacité négociée. Supprimer le contexte ne simplifie pas la preuve : cela crée une précision sans validité.

Une alerte correcte dit « numéro de tile non applicable, T=1 ». Une alerte trompeuse dit « tile 0 affectée » parce que les seize bits étaient nuls. La première conserve l’incertitude légitime ; la seconde fabrique un objet qui n’existait pas.

L’offset absolu localisait la pièce, pas l’en-tête manquant

Le fragment offset sur vingt-quatre bits mesure la position du payload depuis le premier octet du codestream JPEG 2000. Grâce à lui, le récepteur peut placer un fragment et constater qu’un intervalle précédent manque.

Dans une livraison scalable répartie sur plusieurs sessions RTP, le premier paquet vu dans une session peut avoir un offset non nul. La coordonnée reste relative au début commun de l’image, non au commencement local de la session.

Cette règle est essentielle pour réunir des couches. Elle est aussi une limite. Un offset précis ne fournit pas les octets absents. Il n’indique pas pourquoi ils manquent, ni s’ils appartenaient à l’en-tête principal, à un en-tête de tile-part ou à des données codées.

La bonne représentation est une carte d’intervalles par frame, session et couche. Elle montre les zones reçues, les trous, les chevauchements et les conflits. Elle associe chaque zone à une séquence RTP et à ses drapeaux. Elle ne réduit pas la reconstruction à la valeur du plus grand offset.

Un « dernier octet élevé » ne prouve pas une couverture continue. De même, un stockage qui garde les payloads sans l’identité de frame peut conserver tous les octets et perdre leur système de coordonnées.

Le marqueur terminait chaque session séparément

Le bit marqueur RTP est mis à un sur le dernier paquet de la frame. En présence de plusieurs sessions RTP, il est mis à un sur le dernier paquet de cette frame dans chacune d’elles.

Une image scalable peut donc produire plusieurs fins de session. Le premier marqueur n’atteste pas l’arrivée des autres couches. Le dernier marqueur observé n’atteste pas qu’aucun paquet intérieur n’a été perdu. Et l’absence d’une session attendue ne peut pas être détectée si le système a jeté le manifeste des couches.

Le mot « fin » change de portée selon le sujet : fin de la contribution d’une session, fin des émissions de l’émetteur, fin des octets attendus, fin du décodage ou fin de l’affichage. Les confondre permet à une seule balise de signer cinq événements qu’elle n’observe pas.

Pour accepter une frame, il faut définir le résultat attendu. Une couche de base seule peut être admise comme dégradation dans un service et refusée dans un autre. Cette décision appartient au récepteur ou au produit ; le bit marqueur ne la prend pas.

Le système de preuve doit donc enregistrer la liste des sessions attendues, leur rôle, leur marqueur terminal, les intervalles reçus et la politique de qualité applicable.

L’ordre de codestream protégeait le parseur

RFC 5371 appelle unité de packetisation un en-tête principal, un en-tête de tile-part ou un paquet JPEG 2000. Plusieurs unités peuvent partager un paquet RTP si l’ordre du codestream est conservé.

Si une unité dépasse la MTU avec les en-têtes, elle peut être fragmentée. Un payload contenant un fragment ne doit pas y ajouter l’unité suivante. La frontière reste ainsi lisible.

L’ordre imposé à l’émetteur n’annule pas les pertes ni le réordonnancement du réseau. Le numéro de séquence RTP observe l’ordre de transport. L’offset observe la place dans le codestream. La règle de packetisation observe la frontière des unités. Le parseur a besoin des trois.

Une implémentation peut recevoir les fragments en désordre, les repositionner puis découvrir un trou. Elle peut aussi recevoir une suite sans trou dont les paramètres dépassent ses ressources. Aucun succès intermédiaire ne garantit le suivant.

Les marqueurs JPEG 2000 de résilience et les recommandations SOP/EPH peuvent faciliter la reprise et le diagnostic. Ils n’attestent ni leur propre réception ni le succès de la récupération. Il faut garder le résultat du décodeur.

La priorité était un emplacement, pas une politique active

RFC 5371 comporte un champ priority de huit bits. Le nom suggère une consigne au réseau. Dans le contrat de base, l’émetteur devrait mettre 255 et le récepteur devrait ignorer le champ.

RFC 5372 définit des modes de priorité pour exploiter la progression et les couches JPEG 2000. L’extension peut classer des données selon leur importance. Même alors, la valeur exprime un ordre dans ce contrat ; elle ne prouve pas qu’un ordonnanceur réseau a accordé un traitement particulier.

Le risque est commercial autant que technique. Une entreprise peut facturer un « trafic prioritaire » en montrant la valeur d’un octet. Sans preuve de négociation RFC 5372, de politique de file, d’action effective et de livraison mesurée, l’octet n’est pas un reçu de service.

Le contrat minimum doit donc lier priorité à l’extension active, au mode choisi, à la décision de l’émetteur, à l’action du transport et au résultat. Dans le flux de base, la valeur doit rester hors des conclusions.

Ce principe évite aussi de relire l’histoire. La présence du champ dans RFC 5371 ne signifie pas que toutes les implémentations de 2008 appliquaient la sémantique détaillée publiée dans RFC 5372.

SDP négociait une enveloppe de lecture

Le type video/jpeg2000 exige un taux d’horloge RTP et un échantillonnage de couleur. Les implémentations doivent prendre en charge 90 kHz et peuvent accepter d’autres taux. L’offre d’un taux différent devrait aussi proposer 90 kHz sous un autre type de payload dynamique.

La largeur et la hauteur sont des maxima optionnels qui doivent apparaître ensemble. Leur domaine syntaxique va jusqu’à 4 294 967 295. Ce plafond n’est pas une réservation de mémoire ni la preuve qu’un décodeur acceptera une frame donnée.

L’absence du paramètre interlace impose le progressif et tp=0. Sa présence rend possible l’identification des champs impair et pair. Chaque champ n’a que la moitié de la hauteur affichée. Il faut encore recevoir la paire et l’entrelacer correctement.

L’offre/réponse réduit l’ambiguïté avant le transport. Elle ne mesure pas l’état réel du décodeur, sa charge, sa mémoire, son implémentation des extensions ni la qualité affichée.

Un journal qui note seulement « SDP accepté » connaît un accord déclaratif. Pour parler de résultat, il doit relier l’accord aux paquets conformes, aux ressources accordées, au parsing et à la sortie.

L’authenticité de source ne validait pas l’image

RFC 5371 sépare confidentialité, intégrité et authentification de la source. Un mécanisme approprié peut déterminer si un paquet vient d’un membre de la session RTP. Il peut empêcher ou révéler certaines modifications.

Un membre authentifié peut cependant envoyer un offset faux, un codestream incomplet, un en-tête excessif ou des paramètres que le décodeur refuse. Une signature protège une assertion ; elle ne rend pas l’assertion techniquement correcte.

Un paquet perdu reste perdu même si tous les autres sont intègres. Un MHF=2 authentifié reste seulement la dernière partie. La cryptographie peut protéger la balise et les octets présents, pas produire les fragments absents.

Les références historiques à SRTP, IPsec ou TLS pour RTP sur TCP situent les options de 2008. Elles ne prouvent pas le profil employé aujourd’hui et ne remplacent pas une analyse actuelle.

Le reçu de sécurité doit donc s’arrêter à son objet : identité de membre, intégrité et confidentialité dans un contexte défini. Le reçu du codec commence ensuite : cohérence, limites de ressources, décodage et affichage.

La perte devait être mesurée, même sous QoS

La section congestion refuse un autre raccourci. Un récepteur utilisant un service QoS amélioré doit surveiller la perte pour vérifier que le service demandé est effectivement fourni. Sinon, il doit se comporter comme en best effort.

En best effort, l’application doit surveiller la perte et adapter le débit, le nombre de couches ou quitter la session si la situation devient inacceptable. Le contrat de transport est donc un comportement mesuré, non un label.

Un trou dans la carte d’octets peut résulter d’une perte, d’un retrait volontaire de couche, d’un changement d’abonnement ou d’un point de capture incomplet. L’offset situe le trou ; le journal d’adaptation aide à l’attribuer.

Sans cette provenance, un mécanisme de congestion responsable peut être accusé de corruption, tandis qu’une perte incontrôlée peut être présentée comme réduction de qualité volontaire.

L’observation doit conserver la décision, sa cause et son effet. Les champs du payload ne racontent pas à eux seuls l’histoire du réseau.

RFC 9828 pose une autre question

RFC 9828 définit un payload plus récent pour réduire la latence de sous-codestream. Il distingue Main Packet et Body Packet, ajoute des signaux de resynchronisation, de temps, de qualité et de résolution, et permet l’envoi avant la fin de l’encodage sous des progressions précises.

L’Article BTW déjà publié sur RFC 9828 analyse le chemin entre départ anticipé et affichage. Le présent Article ne réécrit pas cette thèse. Il demande ce que vaut une coordonnée absolue lorsque l’en-tête qui donne sens aux octets peut manquer.

RFC 5372 pose encore une troisième question : comment donner une sémantique de compensation et de priorité aux emplacements préparés par RFC 5371. Les trois documents se touchent, mais leurs preuves ne sont pas interchangeables.

Une évolution ultérieure n’efface pas le contrat historique. Elle peut ajouter des mécanismes sans prouver leur déploiement, leur négociation ou leur succès dans une trace particulière.

Cette discipline empêche une revue d’assembler les meilleurs champs de trois RFC et de les attribuer à un système qui n’en a négocié qu’un.

La spécification minimale est une relation

La Minimum Initial Specification de Lu Heng sert ici de grille déclarée. Le minimum commun n’est pas une solution de décodage universelle. C’est un ensemble de reçus qui laisse au récepteur ses choix locaux sans détruire la possibilité de comprendre la décision plus tard.

Ce minimum relie l’accord SDP, l’identité de frame, la session et la couche, la séquence RTP, le timestamp, le marqueur, MHF, mh_id, T, la priorité, l’offset, la longueur, les intervalles reçus, le contrat d’extension et le verdict du décodeur.

La relation est essentielle. mh_id dépend de RFC 5372. Le numéro de tile dépend de T. Le marqueur dépend de la liste des sessions. L’offset dépend de l’origine de la frame. Détacher les valeurs de leurs conditions produit une base riche et une preuve pauvre.

Les Reality Layers fournissent la règle d’arrêt. Une balise est un symbole. Les octets reçus sont un fait de transport. Un codestream contigu est un objet reconstruit. L’acceptation du décodeur est un résultat logiciel. L’image affichée est un événement du produit.

RFC 5371 n’a pas certifié l’arrivée d’une image. Il a donné aux fragments une grammaire assez précise pour que nous puissions voir exactement quelle preuve manque.