Résumé

  • Le projet draft-ietf-mlcodec-opus-extension-06 réemploie le bourrage Opus afin qu’un ancien décodeur puisse l’écarter tout en lisant la couche de base.
  • Même un décodeur qui prend techniquement une extension en charge peut l’ignorer ; une annonce de capacité ne prouve donc ni admission, ni application, ni amélioration en sortie.
  • Il faut conserver séparément la négociation, l’analyse des limites, l’association aux trames, la décision locale et l’observation du résultat.

Une capacité sans obligation d’effet

Le cas le plus trompeur n’est pas celui où le son disparaît. C’est celui où tout semble fonctionner. Un terminal annonce un identifiant d’extension, reçoit un paquet qui le contient et produit un son Opus parfaitement intelligible. L’exploitation conclut que la fonction optionnelle a été utilisée. Pourtant, le texte autorise le décodeur à ignorer une extension qu’il sait techniquement traiter. La base sonore continue précisément parce que le mécanisme a été conçu pour que l’optionnel ne casse pas l’essentiel.

Cette possibilité remet chaque mot à sa place. « Pris en charge » décrit au mieux une surface disponible dans une version ou une configuration. « Négocié » décrit un accord déclaratif. « Analysé » indique que les octets respectent une grammaire. « Appliqué » suppose une décision et une modification d’état. « Entendu » ou « mesuré » concerne enfin la sortie. Aucune de ces étapes ne peut être déduite de la précédente.

Le bourrage devient un conteneur

RFC 6716 exige que l’encodeur mette les octets de bourrage à zéro, tandis que le décodeur doit accepter n’importe quelle valeur. Le projet exploite cette asymétrie : un bourrage non nul signale des extensions. Un décodeur ancien jette ces octets et poursuit le décodage de la partie Opus historique. Un décodeur étendu doit se comporter comme l’ancien en l’absence d’extension.

Le contrat de compatibilité est donc fort mais étroit. La couche de base doit rester utile. L’encodeur ne doit pas dégrader sensiblement la partie non étendue pour un ancien décodeur. Rien de cela ne garantit que la couche optionnelle sera comprise ou produira un effet. Une bonne qualité de base établit que le plancher a tenu, pas que le plafond annoncé a été atteint.

Chaque instance porte un identifiant sur sept bits et un indicateur L. Les identifiants courts peuvent avoir zéro ou un octet de données ; les identifiants longs peuvent en avoir davantage. Pour une extension longue, L=0 consomme normalement le reste du bourrage et ne peut apparaître ainsi qu’une fois dans le paquet. L=1 introduit une longueur explicite, extensible par la valeur 255 tant que la frontière du paquet n’est pas franchie.

Si la longueur sort du paquet, si son propre codage est incomplet ou si les données nécessaires à une répétition manquent, le décodeur doit ignorer l’instance fautive. Le son de base peut néanmoins sortir. Une alerte globale « décodage réussi » écrase donc une information essentielle : l’option a peut-être été rejetée sans interruption perceptible.

La bonne extension, mais pour la mauvaise trame

Les extensions ne sont pas attachées abstraitement au paquet. Elles sont associées à ses trames Opus. L’identifiant structurel 1 sépare les groupes : sans donnée, il avance d’une trame ; avec une donnée, il peut avancer davantage. Un index égal ou supérieur au nombre de trames est hors limites, et toutes les instances associées à cet index doivent être ignorées.

L’identifiant 2, Repeat These Extensions, réduit le coût d’une séquence reproduite sur les trames suivantes. Il réutilise les identifiants et transporte de nouvelles charges utiles. La collection complète d’une trame peut alors ne pas être contiguë dans le paquet. L’ordre est significatif à l’intérieur d’une trame ; une définition particulière peut aussi limiter le nombre d’occurrences. Seul le réordonnancement prévu par RTE reçoit l’équivalence définie par le texte.

Une liste d’identifiants trouvés ne suffit donc pas. Il faut reconstruire la chronologie, vérifier les bornes, connaître la définition applicable et prouver que chaque instance a rejoint la trame visée. Un analyseur peut accepter toute la structure extérieure tout en abandonnant la seule instance qui devait produire l’amélioration.

La négociation ne fait pas tourner le code

Le projet ajoute au type audio/opus deux paramètres : extensions pour les identifiants pris en charge côté réception et sprop-extensions côté émission. Les paramètres propres à une extension utilisent les formes extN-* et sprop-extN-*. Les identifiants structurels 0, 1 et 2 sont obligatoires pour tout récepteur qui reconnaît le mécanisme, sans devoir être annoncés dans les listes.

Le texte interdit de recopier aveuglément les paramètres SDP depuis une autre offre ou réponse. Ils doivent être explicitement spécifiés. Et même si la négociation échoue, le récepteur doit rester capable de décoder les paquets qui contiennent des extensions inconnues ou non négociées : il les ignore et protège la base.

Cette résilience crée une ambiguïté opérationnelle. La session qui reste debout ne prouve pas que les deux parties se sont accordées sur l’option. Pour le démontrer, il faut lier l’offre, la réponse, les paramètres retenus, la version du binaire, sa configuration et les instances réellement reçues. Il faut ensuite une trace d’admission et une observation de sortie.

Un numéro public n’est pas un comportement

Le projet propose un registre « Opus Extension IDs » sur sept bits. Les valeurs 0, 1 et 2 structurent le format. Les valeurs 3 à 119 attendent une action de normalisation. Les valeurs 120 à 126 servent aux expériences ; un préfixe expérience/version est recommandé, ainsi que l’évitement des collisions. La valeur 127 réserve une future extension du mécanisme dont la longueur restera au moins franchissable par les anciens lecteurs.

Le registre attribue un espace de signification. Il ne montre pas quel sens un programme en cours d’exécution a appliqué. Deux expériences peuvent choisir le même numéro, deux versions peuvent diverger, ou une implémentation peut garder un module désactivé. Le reçu utile associe le numéro à la définition, à la version expérimentale, au binaire et à la décision locale.

Le projet Opus HD voisin illustre un consommateur possible : il décrit une couche de qualité extensible, davantage de résolution et du contenu au-dessus de 20 kHz. Il mentionne aussi du code et une option de compilation. Ces éléments ne prouvent aucune activation sur un terminal, aucune négociation dans une session, aucune sortie à 96 kHz ni aucun gain perçu. Le présent article n’évalue pas cette qualité ; il montre pourquoi le conteneur général exige des preuves distinctes.

Portée et incertitude

La révision 06 est un Internet-Draft actif du groupe mlcodec, daté du 23 juillet 2026, mis à jour dans le Datatracker le 27 août, en dernier appel de groupe et destiné au statut Proposed Standard. Elle expire le 24 janvier 2027. Ce n’est pas un RFC. Le texte peut changer ou ne jamais être publié.

Aucun encodeur, décodeur, navigateur, terminal, opérateur ou appel réel n’a été testé. Les sources ne documentent ni incident de paquet malveillant, ni panne, ni collision observée, ni mesure de processeur, mémoire, débit, spectre ou écoute. Les scènes décrites sont analytiques. Elles fixent la limite de la preuve.

La conclusion demeure volontairement précise : si la base est décodée, la compatibilité de base a été observée. Pour affirmer que l’extension a servi, il faut montrer toutes les décisions qui suivent.

Sources