Résumé

  • mhc=1 dans l’échange SDP établit que la compensation d’en-tête principal peut être utilisée. Il ne prouve ni la réception d’un en-tête complet ni l’identité des octets gardés par le récepteur.
  • mh_id ne possède que sept valeurs actives. Après six mises à jour successives perdues, une valeur peut rejoindre celle d’un ancien cache ; l’égalité autorise alors une tentative, pas un verdict de fraîcheur.
  • La négociation, la réception de l’en-tête, sa provenance, la décision de compensation, l’admission par le décodeur et l’image affichée sont autant de reçus différents. La priorité décrit l’importance du codestream, pas une garantie de transport.

Une capacité commune, deux états privés

Le protocole de description de session peut établir une chose précise : l’émetteur propose la compensation d’en-tête principal et le récepteur l’accepte. La RFC 5372 ajoute pour cela le paramètre optionnel mhc au type video/jpeg2000. Une valeur de un indique l’usage de la technique. Les exemples montrent aussi une réponse à zéro, dans laquelle le correspondant refuse la compensation tout en acceptant d’autres caractéristiques du média.

Ce choix est un contrat de méthode. Il ne synchronise pas magiquement les mémoires.

Après l’échange, le récepteur doit encore obtenir un en-tête principal complet. Il doit l’associer au numéro de séquence RTP et à mh_id. Il doit remplacer cet état lorsqu’un nouvel en-tête complet accompagne un changement d’identifiant. Il doit s’abstenir lorsque la valeur est zéro. Il doit enfin décider, en cas de perte ultérieure, si l’en-tête conservé peut être présenté au décodeur.

Chacune de ces opérations survient après la négociation et possède son propre échec possible. Une session peut avoir accepté mhc=1 sans jamais recevoir d’en-tête complet. Elle peut en avoir reçu un, puis perdre les transitions qui l’auraient rendu obsolète. Elle peut comparer deux identifiants égaux alors que l’espace de sept valeurs a effectué un tour complet. Elle peut tenter un décodage que le décodeur rejettera ensuite.

Rapporter « compensation négociée » comme « récupération réussie » efface tout cet intervalle d’autorité.

L’identifiant n’était pas l’empreinte de l’en-tête

Le nom mh_id invite à imaginer une identité durable. Le texte de la RFC 5372 enlève précisément cette ambiguïté : l’identifiant et les paramètres d’encodage ne sont pas associés un pour un. La valeur sert à indiquer si les paramètres du cadre précédent restent applicables lorsque l’en-tête courant manque.

Le champ occupe trois bits. La session commence à un. Tant que les paramètres gouvernés restent identiques, l’émetteur conserve la même valeur. Lorsqu’ils changent et qu’un nouvel en-tête principal est envoyé, la valeur avance. Après sept, elle revient à un.

Le signal porte donc sur une transition dans un espace borné. Il n’est ni une empreinte cryptographique, ni un numéro de version sans rebouclage, ni un engagement sur les octets exacts du cache distant.

Les paramètres concernés ne sont pas une notion vague de « même image ». La RFC cite le segment SIZ et les segments fonctionnels COD, COC, RGN, QCD, QCC et POC. Le récepteur n’apprend pas leur contenu par le seul identifiant. Il apprend que l’émetteur affirme leur continuité ou leur changement selon les règles de la spécification.

Pour conserver la preuve, il faut donc enregistrer l’objet et son origine : session, source de synchronisation, numéro de séquence du dernier en-tête complet, identifiant reçu, empreinte locale de l’en-tête, instant de stockage et historique des transitions observées. Un chiffre isolé n’explique pas quel en-tête il désigne, ni depuis combien de temps cette désignation est plausible.

Le cache n’existait qu’après une réception complète

La RFC 5372 demande au récepteur de sauvegarder le numéro de séquence RTP, mh_id et l’en-tête principal quand celui-ci a été reçu complètement. Elle recommande de ne conserver que le dernier en-tête complet.

Le mot « complet » est la frontière essentielle. Une valeur mh_id visible dans un paquet ne remplit pas le cache. Un fragment final d’en-tête ne prouve pas que les fragments précédents sont arrivés. Un paquet authentifié ne restaure pas les octets absents. Une session SDP acceptée ne fournit pas le contenu.

Une implémentation qui crée un état de cache dès qu’elle voit l’identifiant transforme un index en objet. Elle devrait au contraire distinguer :

  • aucun en-tête complet n’a encore été observé ;
  • un en-tête complet a été sauvegardé avec sa provenance ;
  • un changement d’identifiant a été vu mais son nouvel en-tête complet manque ;
  • un cache a été remplacé après réception complète ;
  • un cache a été invalidé après incohérence du décodeur ;
  • la valeur zéro interdit le stockage et la compensation.

Ces états produisent parfois la même absence d’image. Ils n’ont ni la même cause ni la même action de reprise.

Six mises à jour perdues ont fabriqué une égalité

La section de sécurité décrit le cas critique sans détour. L’espace actif peut identifier sept en-têtes. Si une perte sévère, aléatoire ou provoquée, masque six mises à jour successives, le décodeur peut tenter de décompresser le flux avec un ancien en-tête devenu incorrect.

Le point important n’est pas seulement le nombre six. C’est la disparition d’une histoire.

Le récepteur avait enregistré la valeur un. L’émetteur a ensuite annoncé des changements avec de nouveaux en-têtes. Les paquets qui auraient invalidé le cache n’ont pas été reçus. Lorsque le compteur revient à un, la comparaison locale est exacte : la valeur courante égale la valeur sauvegardée. Mais cette exactitude numérique ne représente plus la continuité des paramètres.

Un indicateur moyen de pertes ne suffit pas à caractériser le risque. Six pertes dispersées dans des données ordinaires n’ont pas le même pouvoir que six transitions d’en-tête consécutives. Ce qui manque ici n’est pas seulement du volume ; ce sont les événements qui auraient modifié l’autorité du cache.

Une attaque n’a pas besoin de forger le champ pour exploiter cette limite. Une suppression sélective des en-têtes de changement peut suffire. La protection d’intégrité confirme que les paquets reçus n’ont pas été modifiés. Elle ne témoigne pas des mises à jour qui ne sont jamais arrivées.

Le décodeur pouvait découvrir l’erreur trop tard

La RFC indique qu’un décodeur JPEG 2000 standard pourrait détecter une incohérence entre l’en-tête sauvegardé et le codestream. Elle recommande alors d’effacer mh_id et l’en-tête mis en cache.

Ce contrôle est nécessaire, mais il intervient après la sélection de l’état. Le décodeur a déjà reçu la combinaison. Il a pu réserver de la mémoire, consommer du temps, rejeter le cadre ou produire une erreur générique. La détection ne prouve pas que l’en-tête correct sera récupéré ensuite.

L’effacement accomplit une action négative : il empêche une nouvelle réutilisation du même état suspect. Il ne recrée ni les mises à jour perdues ni le dernier en-tête valide. La reprise exige une nouvelle réception complète ou une autre politique explicite.

Les journaux devraient séparer quatre résultats : décision de compenser, admission de l’entrée par le décodeur, fin du décodage sans incohérence signalée et production effective d’un cadre. Si l’application a besoin de prouver l’affichage, un cinquième reçu doit provenir de la sortie ou du dispositif de rendu.

Un succès à une étape n’hérite pas de l’autorité des suivantes.

Zéro suspendait volontairement la mémoire

Lorsque mh_id vaut zéro, le récepteur ne doit ni sauvegarder l’en-tête ni compenser un en-tête perdu. Ce n’est pas une identité ordinaire, ni une valeur manquante à remplacer par la précédente.

Cette sémantique négative mérite sa propre observation. Un système qui convertit zéro en null, puis applique une valeur par défaut, peut réactiver exactement le mécanisme que l’émetteur a désactivé. Un tableau de bord qui mélange zéro, absence de support et absence d’en-tête complet ne permet pas de savoir pourquoi la compensation n’a pas eu lieu.

Il faut distinguer la non-participation d’un récepteur RFC 5371, le refus négocié avec mhc=0, l’usage actif de zéro, l’absence de cache malgré une valeur non nulle et l’échec d’une tentative avec correspondance. Ces situations peuvent partager un compteur d’erreurs, mais pas une conclusion.

La priorité organisait le codestream, pas le réseau

La seconde extension de la RFC 5372 donne un sens au champ de priorité. Zéro est réservé aux charges qui contiennent un en-tête principal ou un en-tête de tile-part. De un à 255, les valeurs croissantes représentent une importance décroissante. La méthode par numéro de paquet est obligatoire ; les méthodes par progression, couche, résolution ou composante restent optionnelles.

Le paramètre SDP pt annonce les tables proposées et sélectionne celle qui sera utilisée. Sans cette table, une valeur brute perd une partie de son contexte. Le même nombre peut provenir d’une logique de couche ou de résolution différente.

Surtout, la priorité ne crée aucune réservation de transport. Elle permet de choisir ou d’ordonner des parties d’un codestream scalable. Elle ne garantit ni la place dans une file, ni la livraison, ni l’admission par le décodeur, ni la qualité visible.

Le scénario des six en-têtes perdus en fournit la preuve conceptuelle. Ces paquets peuvent porter la priorité zéro et rester les plus importants selon le format. Ils peuvent néanmoins disparaître. Le champ a correctement décrit leur importance ; il n’a jamais délivré le reçu de transport.

Un groupe multicast pouvait partager les paquets, pas leur interprétation

La RFC 5372 reste une extension optionnelle. Un récepteur limité à la RFC 5371 ignore sans danger mh_id et la priorité. En multicast, l’émetteur peut utiliser les mécanismes même si un membre du groupe ne les comprend pas.

Deux clients peuvent ainsi recevoir le même paquet et construire des états différents. Le premier a négocié ou implémenté la compensation, garde un en-tête et interprète la priorité. Le second ignore les champs. Une capture réseau commune ne prouve donc pas un comportement commun.

Les rapports doivent être rattachés au récepteur. Dire que « le groupe a compensé » à partir du seul comportement de l’émetteur confond émission d’un indice et usage effectif. La conformité de base garantit l’interopérabilité ; elle ne garantit pas l’uniformité des observations.

Construire une preuve de cache

Le bon modèle ne transforme pas sept emplacements en sept identités permanentes. Il traite chaque correspondance comme une hypothèse bornée par une provenance.

Avant toute compensation, l’implémentation devrait vérifier que mhc appartient au contexte média actif, que la valeur n’est pas zéro, qu’un en-tête complet de la même session a été sauvegardé, qu’aucune rupture de source ou renégociation n’a traversé le cache et qu’aucune incohérence antérieure ne l’a marqué comme suspect.

Elle devrait ensuite enregistrer la tentative avec l’empreinte de l’en-tête retenu, sa séquence d’origine, l’identifiant courant et les pertes observées depuis la sauvegarde. Le résultat du décodeur et l’action d’effacement doivent être liés au même événement.

Une politique locale peut être plus prudente que le minimum : expiration temporelle, invalidation après une longue lacune de séquence, exigence d’un nouvel en-tête complet après un rebouclage inexpliqué, ou suspension après plusieurs incohérences. Ces choix doivent être nommés comme des contrôles locaux, non comme des obligations inventées de la RFC.

La valeur de la compensation tient à la réutilisation. La valeur de l’audit tient à la capacité de dire exactement ce qui a été réutilisé.