Résumé

  • L’IESG a approuvé le 10 septembre 2026 la publication de draft-ietf-avtcore-rtcp-green-metadata-17 comme Proposed Standard. Au 28 septembre, le texte demeure dans la file du RFC Editor et n’est pas encore un RFC.
  • TSRR permet au récepteur de proposer une cadence, une largeur et une hauteur. TSRN accuse réception et indique les valeurs retenues, qui peuvent différer de la demande.
  • Ces messages ne mesurent ni la batterie ni l’énergie économisée. Ils ne prouvent pas non plus le consentement humain ou la qualité effectivement affichée.

Le besoin local devient lisible

Une machine sur batterie peut estimer que le débit de pixels actuel l’empêchera d’achever une visioconférence prévue. Un décodeur logiciel peut aussi manquer de ressources parce qu’il partage le processeur avec d’autres tâches. Le projet AVTCORE prévoit alors une Temporal-Spatial Resolution Request, ou TSRR : le récepteur indique une cadence, une largeur et une hauteur souhaitées.

Le texte a franchi l’IESG et se trouve chez le RFC Editor. Ce statut est précis : le mécanisme est approuvé pour la voie des normes, mais aucun numéro de RFC final ni aucun déploiement ne doit être inventé.

L’essentiel tient dans un verbe. Un encodeur capable de s’ajuster peut tenir compte de la requête. Le récepteur décrit la charge qu’il voudrait recevoir ; il ne commande pas la machine distante. Les valeurs demandées ne peuvent pas dépasser les limites négociées par SDP, et une hausse de qualité reste soumise au débit permis par le contrôle de congestion.

La réponse conserve le désaccord

L’émetteur renvoie une Temporal-Spatial Resolution Notification, ou TSRN. Elle reprend le numéro de séquence de la requête et annonce la cadence ainsi que les dimensions qui seront utilisées. Sa fonction n’est pas de faire croire que la demande a été exécutée à l’identique. Les valeurs peuvent changer si l’encodeur ne sait pas s’adapter, si les plafonds SDP l’interdisent, si le contenu est préenregistré ou si d’autres règles s’appliquent.

Cette différence est le cœur de la preuve. « Requête reçue » décrit un événement. « Paramètres sélectionnés » en décrit un autre. Pour savoir comment la décision a été prise, un opérateur doit conserver les deux. Un tableau de bord qui ne garde qu’un indicateur « mode vert » efface précisément la frontière que le protocole expose.

Le mixeur arbitre entre plusieurs coûts

Dans une session à plusieurs, un mixeur peut encoder pour plusieurs destinataires. Le projet lui demande de considérer leurs besoins conjoints. Le portable presque déchargé peut vouloir une petite image ; l’écran d’une salle réclame les détails d’un plan ; l’enregistrement impose une qualité stable. Une seule requête ne résout pas cette concurrence.

Créer un encodage par participant protège les préférences mais consomme davantage de calcul côté service. Abaisser un flux commun épargne peut-être une machine tout en dégradant toutes les autres. Choisir une couche scalable déplace encore le compromis. Le standard transporte des nombres ; il ne décide pas qui doit payer le coût collectif.

L’augmentation demandée rencontre par ailleurs une contrainte indépendante. Si le débit nécessaire dépasse celui qu’autorise la congestion, le mixeur ou le traducteur doit limiter le flux. Le désir du récepteur ne crée ni capacité réseau ni autorité sur les autres participants.

La résolution n’est pas un compteur électrique

TSRR et TSRN contiennent des images par seconde et des dimensions en échantillons de luminance. On n’y trouve ni watts, ni joules, ni autonomie restante, ni charge du décodeur. Réduire le débit de pixels peut diminuer le travail de décodage, mais l’effet réel varie selon le codec, l’accélération matérielle, l’écran, le logiciel et la charge parallèle.

Un fournisseur peut donc affirmer qu’il prend en charge un retour destiné à des mécanismes de consommation plus efficace. Il ne peut pas en déduire honnêtement un pourcentage universel d’autonomie sans mesures sur des appareils et des conditions identifiés.

La notification n’est pas davantage une preuve de livraison. Elle exprime ce que l’émetteur compte coder après la requête. Elle ne démontre pas que chaque trame est arrivée ainsi ni que le terminal l’a affichée. Ces observations appartiennent à une couche ultérieure.

Le paquet ne contient pas le mandat de l’utilisateur

Une TSRR peut résulter d’un clic, d’une règle du système d’exploitation, d’un profil d’entreprise ou d’un réglage automatique de l’application. Le message ne dit pas lequel de ces acteurs a autorisé la perte de qualité. Assimiler toute requête automatique à un consentement reviendrait à fabriquer un mandat absent du protocole.

La sécurité rend cette prudence concrète. Le projet indique que des retours falsifiés ou malveillants peuvent réduire fortement la résolution ou la cadence. L’authenticité et l’intégrité protègent donc la nouvelle capacité d’expression du récepteur contre sa transformation en outil de dégradation.

La discipline des couches de réalité défendue par Heng Lu donne ici une méthode simple. L’approbation IESG est un fait de procédure. Une attribution IANA sera un fait de registre. TSRR est une demande observée. TSRN est un choix déclaré. La livraison, l’image rendue et l’énergie mesurée sont d’autres faits. Aucun reçu ne devient automatiquement le suivant.

Rendre le pouvoir visible, sans prétendre l’abolir

Le mécanisme ne transfère pas la maîtrise de l’encodeur. Il donne au terminal contraint un vocabulaire commun et contraint l’émetteur à répondre par des paramètres concrets. Le service conserve le choix ; il gagne en contrepartie une décision que l’on peut comparer à la demande.

C’est une avancée plus solide qu’un slogan écologique. Celui qui supporte le coût peut parler. Celui qui contrôle l’image doit répondre. L’écart entre les deux devient une donnée exploitable au lieu de rester une décision invisible.

Sources