Résumé

  • RFC 3984 distinguait les unités portant les images H.264 des ensembles de paramètres de séquence et d’image qui indiquaient au décodeur comment les comprendre.
  • Le changement d’état devait être ordonné : un identifiant réutilisé trop tôt, un ensemble tardif ou une mise à jour perdue pouvait rendre inutilisables de nombreux paquets pourtant reçus sans erreur.

À l’instant du changement, l’encodeur produit encore des tranches dépendant de l’ancienne géométrie. Certaines sont déjà dans le réseau, d’autres attendent dans un tampon de gigue. Le nouvel ensemble de paramètres d’image porte le même petit identifiant. Si le récepteur remplace immédiatement l’ancienne définition, il ne sait plus que le paquet retardé appartient au monde précédent. Le paquet n’est pas corrompu ; c’est son contexte qui a changé.

C’est l’un des problèmes les plus instructifs de la RFC 3984, publiée en février 2005 pour transporter la vidéo H.264 sur RTP. Sa fiche de statut, ses errata et son historique Datatracker indiquent qu’elle a ensuite été remplacée par la RFC 6184. Derrière les mécanismes de fragmentation et d’agrégation se trouvait une question de gouvernement de l’état : qui donne un sens aux tranches, à quel moment et pour combien de temps ?

H.264 extrait des tranches les informations qui servent à plusieurs images. L’ensemble de paramètres de séquence, ou SPS, décrit un contexte de séquence vidéo codée. L’ensemble de paramètres d’image, ou PPS, précise des choix applicables aux images, par exemple certains modes de codage ou l’organisation en groupes de tranches. L’en-tête d’une tranche ne répète pas tout cela. Il désigne les ensembles par leurs identifiants.

Cette économie transforme une règle en dépendance. Connaître l’identifiant ne livre pas son contenu. Le décodeur doit avoir reçu, conservé et activé la bonne version avant l’unité NAL qui s’y réfère dans l’ordre de décodage. Les images ont donc une chronologie de transport ; les règles ont une chronologie d’installation. Elles peuvent diverger.

La RFC 3550 aide à ne pas confondre ces plans. Le numéro de séquence RTP permet de détecter des pertes et de remettre les paquets dans l’ordre. L’horodatage représente l’instant d’échantillonnage et sert à la synchronisation. Ni la fiche de statut, ni les errata, ni le dossier Datatracker ne donnent à ces champs la fonction de versionner un SPS ou un PPS. Un tableau de bord RTP vert peut donc coexister avec un décodeur mal configuré.

RFC 3984 formulait trois principes de distribution. Le principe A plaçait les ensembles de paramètres dans un canal fiable hors bande avant la session RTP. Le principe B permettait de les mettre à jour hors bande pendant la session. Le principe C les envoyait dans la bande média elle-même. Le texte de 2005 préférait la livraison fiable hors bande pour A et B. Dans la bande, il fallait compenser la fragilité par répétition, retransmission ou correction d’erreurs, car la perte d’un seul état pouvait contaminer de nombreuses unités ultérieures.

Pour l’état initial, sprop-parameter-sets transportait dans la description de média des unités NAL codées en base64. Elles devaient précéder, dans l’ordre de décodage, les unités qui les invoquaient. Ce paramètre ne déclarait pas les capacités du récepteur. Il annonçait l’état que l’émetteur voulait employer. Lire cette annonce comme une liste de capacités aurait fait conclure, à tort, que le récepteur acceptait tout ce qui y figurait.

Le canal hors bande passait fréquemment par SDP. La RFC 4566, sa fiche, ses errata et son historique définissent un format de description de session, non une preuve universelle d’installation interne. La RFC 3264 organise l’offre et la réponse, avec une seule offre en attente ; sa fiche, ses errata et son dossier éclairent cette sérialisation.

Cette sérialisation était utile pour une bascule. RFC 3984 recommandait d’attendre l’accusé de réception de la signalisation d’une mise à jour fiable avant d’émettre les NAL qui en dépendaient. Mais la chaîne réelle comptait plusieurs événements : message reçu, nouvel ensemble analysé, mémoire mise à jour, ensemble rendu actif, puis média dépendant admis. Une application devait préciser lequel de ces événements l’accusé confirmait.

La réutilisation des identifiants imposait ensuite une discipline de durée. Écraser un PPS actif pendant que d’anciennes tranches restaient en vol revenait à changer la définition d’un mot au milieu d’une phrase déjà expédiée. Le document conseillait de choisir un identifiant resté inutilisé assez longtemps, ou d’ajouter un nouvel identifiant. La période de sûreté comprenait le réseau, la réorganisation, les tampons et la durée de conservation du décodeur.

Dans une conférence à plusieurs sources, cette règle devenait un problème d’autorité. Deux encodeurs pouvaient sélectionner localement le même identifiant sans faute apparente. Au point de mélange, pourtant, un seul espace de noms devait rester cohérent. Un contrôleur devait répartir les plages, réécrire les références ou isoler les contextes. Sans propriétaire de l’espace, la validité locale produisait une collision globale.

La combinaison de canaux présentait un autre piège. RFC 3984 refusait de mélanger les mises à jour hors bande du principe B et les mises à jour dans la bande du principe C sans synchronisation suffisante. Un participant tardif pouvait partir de l’état SDP initial mais manquer une modification déjà passée dans le flux. Un récepteur ayant perdu cette modification continuait avec une mémoire périmée, même si tous les paquets d’image suivants arrivaient.

La RFC 6184, accompagnée de sa fiche, de ses errata et de son historique, a révisé ce choix. Elle autorise les deux modes sans maintenir une préférence générale pour le hors bande et ajoute notamment in-band-parameter-sets. La leçon historique n’est donc pas « hors bande pour toujours ». Elle est que le mode, la propriété des identifiants et l’ordre de bascule doivent être explicites.

La RFC 7798, avec son statut, ses errata et son dossier Datatracker, retrouve le problème pour HEVC. Cette comparaison montre que l’état du décodeur reste une préoccupation des formats de charge vidéo. Elle ne démontre ni une adoption uniforme, ni un comportement identique de tous les produits.

L’asymétrie explique aussi la sécurité. Une tranche endommagée peut limiter ses effets à une région. Un ensemble de paramètres faux ou injecté peut modifier l’interprétation d’une longue suite d’unités NAL. L’intégrité et l’authentification de l’origine protègent alors non seulement un paquet, mais la grammaire temporaire de nombreux paquets futurs.

Après un incident, il faut conserver davantage que le flux RTP : les offres et réponses, les accusés, chaque version SPS/PPS, l’auteur de chaque identifiant, les changements de type de charge et l’horizon des tampons. Une capture qui ne sait pas quelle définition occupait un identifiant au moment du décodage n’est pas une preuve complète.

RFC 3984 révèle ainsi une propriété plus générale des systèmes distribués. Les données et les règles qui les rendent intelligibles peuvent être parfaitement valides séparément et incompatibles dans le temps. La continuité ne vient pas de leur simple présence. Elle vient d’une bascule ordonnée, d’une mémoire versionnée et d’une autorité claire sur les identifiants.

Sources