Résumé

  • RFC 9559 permet de constater un document EBML légal, des pistes décrites et des Blocks structurés. Ce constat s’arrête avant la capacité du codec, la fermeture des références et la présentation synchronisée.
  • Cues peut n’indexer qu’une partie des temps et des pistes ; un direct peut l’omettre légitimement. Atteindre l’index ne prouve pas l’arrivée sur une image visible et décodable de façon autonome.
  • Les drapeaux Default et Forced alimentent la politique du lecteur. Ils ne consignent pas la piste audio, le sous-titre ou le service d’accessibilité réellement fourni.

Un lecteur Matroska accepte l’en-tête EBML puis parcourt une arborescence valide. L’expression « le fichier est lisible » transforme facilement ce succès local en promesse globale. RFC 9559, publiée sur la voie normative de l’IETF en octobre 2024, ne fait pas ce raccourci. Elle normalise un contenant : identification des pistes, stockage des trames encodées, horodatage et indexation.

Sa mise à jour d’EBML illustre déjà la différence entre document et pratique. RFC 8794 avait réservé l’identifiant 0x80, alors que des implémentations Matroska l’employaient pour ChapterDisplay. RFC 9559 rend cet usage légal. Le texte commun a rejoint le code déployé ; il n’a pas certifié rétroactivement tous les fichiers ni tous les lecteurs.

La compatibilité peut être volontairement réduite

L’en-tête distingue DocTypeVersion de DocTypeReadVersion. Le premier couvre l’élément Matroska le plus récent présent. Le second indique la version minimale nécessaire à une lecture éventuellement privée de certaines fonctions. L’exemple normatif conserve une read version 2 malgré CueRelativePosition, élément de version 4 : celui-ci affine la recherche sans être indispensable à la lecture ordinaire.

Un lecteur compatible doit aussi ignorer les éléments inconnus qui respectent les limites de leur parent. Ouvrir le fichier peut donc signifier que l’application a omis une information qu’un autre lecteur exploiterait. Le reçu doit nommer l’implémentation, les versions déclarées et les éléments sautés avant de parler de parité fonctionnelle.

Extraire une trame exige plus qu’une frontière d’élément

Block et SimpleBlock réunissent numéro de piste, horodatage relatif au Cluster, drapeaux, lacing facultatif et une ou plusieurs trames. Les lacings Xiph, EBML et de taille fixe économisent des octets, mais imposent de reconstruire les frontières internes. Trouver la fin du Block ne prouve pas que chaque trame a été séparée correctement.

Il faut ensuite fermer les dépendances. RFC 9559 avertit qu’une trame dépendante prise à tort pour un point d’accès aléatoire peut produire une sortie fausse, voire un plantage. Certaines images intra-only AV1 ou VP9 se décodent seules sans réinitialiser l’état du codec ; les suivantes continuent de dépendre d’un passé perdu lors du saut. La question probante devient : toutes les références nécessaires après ce point sont-elles disponibles ?

CodecID et, si nécessaire, CodecPrivate identifient et initialisent le format encodé. Le mapping commun n’installe aucun décodeur, ne garantit aucun profil ni aucune sortie. Cette capacité possède son propre reçu.

L’entier horodaté n’est pas encore le temps du spectateur

Le temps de présentation combine l’horodatage du Cluster, la valeur signée du Block, TrackTimestampScale, TimestampScale et parfois CodecDelay. Une trame à temps négatif peut devoir être décodée sans être montrée. Un résultat flottant doit être arrondi à la nanoseconde la plus proche.

La norme reconnaît en outre que beaucoup de lecteurs historiques ignorent un TrackTimestampScale différent de 1.0. Deux lecteurs peuvent donc fabriquer des chronologies opérationnelles différentes à partir d’un fichier syntaxiquement valable. Pour les opérations combinant plusieurs pistes, des trames qui se chevauchent peuvent être supprimées ou rendues différemment selon la plateforme.

Il faut conserver les entrées du calcul et comparer les temps produits, la synchronisation audio-vidéo et les empreintes de sortie. Parser un nombre ne prouve pas qu’il a été présenté au bon instant.

Un Cue indique une route, pas l’achèvement du saut

Cues indexe certains Cluster afin d’accélérer l’accès à un temps absolu. Il peut couvrir chaque horodatage ou une sélection. Pour un fichier non live, la présence de Cues et l’indexation des images clés sont recommandées ; les entrées audio peuvent être omises lorsqu’une piste vidéo existe. Sans index, le lecteur peut encore fouiller le fichier.

Un test sérieux vérifie successivement la couverture du temps et de la piste demandés, la position du Cluster, l’éventuelle position relative, la fermeture des références, puis l’écart entre l’image demandée et l’image réellement affichée. Le hit d’index ne ferme que l’étape d’adressage.

Le direct change licitement cette surface. Des Segments continus ne doivent employer ni SeekHead, ni Cues, ni chapitres, ni pièces jointes. Un flux dépourvu des deux index au début doit être tenu pour non seekable. Cette absence peut être conforme tout en rendant impossible une promesse produit de retour arrière.

Les pistes restent une décision locale

FlagDefault rend une piste admissible à la sélection automatique par langue ; le lecteur peut l’écarter, notamment au nom d’une préférence d’accessibilité. FlagForced recommande un sous-titre même lorsque l’audio choisi n’en appellerait normalement aucun. D’autres drapeaux décrivent déficience auditive ou visuelle, audiodescription, langue originale et commentaire.

Ce sont des données de décision, pas le résultat. Le contrôle final relie les drapeaux du conteneur aux préférences, à l’ordre de priorité du lecteur, aux Track UID choisis et à un témoin audible ou visible. Dans la logique de Heng Lu, le RFC coordonne ; le code en fonctionnement, le décodeur, le rendu et la sortie montrent ce qui s’est réellement passé.