Résumé
- La RFC 9628 propose deux façons d’exposer les dépendances temporelles de VP9 : le mode flexible attache jusqu’à trois écarts
P_DIFFà l’image prédite ; le mode non flexible réutilise un motif déclaré dans les données de structure d’échelonnabilité. - Un identifiant d’image, une phase de groupe, des indices de couche et des bits de frontière décrivent l’organisation annoncée par l’émetteur. Ils ne prouvent ni l’arrivée de tous les fragments, ni la présence des références, ni la validité de l’état interne du codec.
- La preuve opérationnelle doit conserver le contexte SDP, l’époque de structure, la couverture RTP, la fermeture des références, le résultat du décodeur et la décision d’affichage.
Le relais avait supprimé exactement ce que le format l’autorisait à supprimer. Le graphe restant était cohérent. Les identifiants d’image retombaient sur les bonnes positions du motif. Pourtant, le récepteur rejetait la trame suivante.
La question utile n’était pas : « Le graphe est-il valide ? » Elle était : « Quelle réalité ce graphe décrit-il ? »
La RFC 9628 définit le transport RTP de VP9 et expose assez d’informations pour raisonner sur les couches spatiales et temporelles. Elle permet à un endpoint ou à un relais sélectif de reconstruire une partie du passé dont dépend une image. Mais la description vient de l’émetteur ; elle ne transporte pas avec elle la réception de chaque octet, le contenu des tampons du décodeur ni le choix final de l’application.
Le mode flexible paie chaque référence au comptant
En mode flexible, F=1 et l’identifiant d’image est obligatoire. Une image prédite porte un à trois champs P_DIFF. Chacun indique la distance relative vers un Picture ID antérieur, avec un calcul modulo la largeur active de sept ou quinze bits. La valeur zéro est invalide.
Cette forme est coûteuse en quelques octets, mais elle réduit la dette historique. Un encodeur peut changer sa hiérarchie temporelle, et le paquet courant expose directement les images antérieures qu’il prétend utiliser. Le relais n’a pas besoin de projeter un motif fixe sur chaque Picture ID.
Direct ne veut pourtant pas dire autonome. Il faut connaître la largeur actuelle du PID, la session, le SSRC, le type de charge utile négocié et le point d’observation. Il faut aussi disposer réellement des images référencées. Un P_DIFF correct vers une image perdue reste une description correcte d’une dépendance impossible à satisfaire.
Le mode flexible fournit donc une liste de créances. Il ne prouve pas que le débiteur — le tampon de références du récepteur — possède encore les actifs correspondants.
Le mode non flexible achète de la compacité avec une mémoire commune
En mode non flexible, la structure temporelle se répète. Les données SS déclarent un Picture Group : nombre d’images, identifiant temporel, point de montée et écarts de référence pour chaque position. Le Picture ID de l’image clé correspond à la première position ; les suivants parcourent le groupe modulo N_G.
Cette économie change la nature de l’observation. Une image isolée ne contient plus la totalité de ses références. Son sens dépend d’une déclaration antérieure et de la phase correcte dans le cycle. TL0PICIDX suit en parallèle les images de couche temporelle zéro et indique, pour une couche supérieure, la base dont elle dépend.
Une collecte démarrée trop tard peut voir un flux parfaitement régulier sans avoir l’SS qui le gouverne. Un relais redémarré peut retrouver les paquets mais perdre l’ancre de l’image clé. Deux systèmes peuvent conserver le même groupe tout en divergeant d’une position. Dans ces cas, la syntaxe est présente et l’interprétation ne l’est pas.
La RFC limite volontairement les changements. Le bit F ne peut basculer que sur le premier paquet d’une image clé. Une nouvelle structure doit commencer à la frontière autorisée par la structure précédente. Cette frontière doit devenir une époque explicite dans les journaux : hash du bloc SS, paquet d’introduction, PID d’ancrage, longueur du groupe et phase calculée.
Les identifiants roulent, les preuves ne doivent pas rouler avec eux
Le Picture ID commence de manière aléatoire, s’incrémente par image et revient à zéro à la fin de son espace. Sa largeur peut passer de sept à quinze bits ou revenir à sept. La transition applique des règles d’extension ou de troncature que le récepteur ne peut ignorer.
Toutes les représentations spatiales d’une même image portent le même PID. Une image show_frame=0, destinée à nourrir une référence sans être affichée, obtient néanmoins son propre identifiant. Le PID n’est donc ni un numéro d’écran ni une empreinte du contenu.
Un relais peut supprimer des images conformément à la structure, et le récepteur observe alors des trous licites. À l’inverse, une suite de PID apparemment continue ne prouve pas que tous les paquets d’une trame ont été reçus. La continuité du compteur et la complétude du média répondent à deux questions différentes.
Pour une enquête, le PID doit être joint au timestamp RTP, à la largeur du champ, à l’époque SS, au SSRC, à la couche et à l’endroit où il a été observé. Sans ces coordonnées, le même nombre réapparaît et raconte plusieurs histoires possibles.
Une fin de trame n’atteste pas son contenu
VP9 fragmente une trame entre un paquet B=1 et un paquet E=1. Le bit Marker du RTP signale le dernier paquet de la plus haute couche spatiale présente, donc la fin de l’image complète. Lorsqu’un relais retire les couches supérieures, il doit repositionner ce marqueur sur la dernière couche qu’il transmet.
Ces marques répondent à « où se termine l’unité ? », pas à « tout ce qui la compose est-il arrivé ? ». Un récepteur peut recevoir E=1 après avoir perdu un numéro de séquence intermédiaire. Il peut recevoir le Marker alors qu’une couche inférieure exigée par D=1 est incomplète. La réécriture du Marker peut être conforme et le résultat indécodable.
La preuve de complétude doit couvrir la séquence RTP de B à E, les timestamps, l’ordre croissant des couches spatiales et le marqueur final correspondant à la sélection réellement transmise. La structure de frontières n’est pas un substitut à cette couverture.
Le codec conserve un état que le graphe ne montre pas
VP9 dépend aussi de tables de probabilité utilisées par le codage entropique et les arbres. La RFC exige l’usage approprié de error_resilient_mode lorsqu’une trame qui aurait pu fournir cet état peut être légalement supprimée. Ce mode réinitialise une partie de l’histoire invisible dans les références d’image.
Voilà pourquoi une vérification purement graphique s’arrête trop tôt. Les P_DIFF peuvent se fermer, le groupe peut être respecté et les couches peuvent être correctement étiquetées ; la charge utile peut encore dépendre d’un état de codec absent. À l’inverse, un décodeur tolérant peut produire quelque chose sans confirmer que la description était exacte.
La spécification du bitstream VP9 et l’exécution du décodeur ferment ce second niveau. Le tableau de références et le bitstream sont deux surfaces de preuve liées, non deux noms pour la même chose.
Les bits de couche autorisent des décisions limitées
TID et SID localisent la couche temporelle et spatiale. D indique la dépendance vers la couche spatiale immédiatement inférieure de la même image. U marque un point à partir duquel une montée temporelle peut éviter certaines images anciennes. Z permet de jeter la trame courante lorsqu’aucune couche spatiale supérieure n’en dépend.
Un relais peut employer ces champs pour réduire la charge. Il ne peut pas en déduire l’expérience. U=1 ne prouve pas l’arrivée du point de commutation. Z=1 ne prouve pas que la suppression respecte le choix de qualité de l’utilisateur. SID=2 ne dit pas quelle résolution a effectivement été affichée. D=0 élimine une dépendance intra-image, pas toutes les dépendances temporelles.
La décision doit donc laisser son propre reçu : règle appliquée, paquets gardés, paquets rejetés, marqueur réécrit, objectif de couche et contrainte de congestion. Sans ce reçu, la conformité du champ devient une excuse sans auteur pour le résultat obtenu.
Un retour RPSI ne signe pas l’écran
La RFC 9628 relie VP9 au RPSI. Le récepteur peut y placer le Picture ID d’une golden frame ou altref frame correctement décodée, ou indiquer une référence préférée après une perte. Ce message est une observation du décodeur et non une simple répétition du descripteur émetteur.
Sa portée reste précise. Il ne certifie pas que toutes les couches d’une image ont été produites, que l’application a retenu cette image pour le playout, ni que le rendu est arrivé avant son échéance. FIR demande un renouvellement global ; LRR demande un renouvellement ciblé. Aucun de ces ordres ne devient un résultat parce que les références peuvent ensuite être retracées.
La bonne chaîne sépare demande, émission, transport, fermeture des références, décodage et affichage. L’article consacré à la RFC 9627 possède la frontière de commande ; ici, le sujet est le contrat de description VP9 qui rend la chaîne inspectable sans la conclure.
La négociation précède toute interprétation
Dans SDP, VP9 utilise une horloge de 90 kHz et un type de charge utile dynamique. profile-id doit rester symétrique entre offre et réponse ; son absence signifie Profile 0. max-fr et max-fs déclarent les capacités du récepteur, mais ne mesurent pas la trame réellement envoyée ou décodée.
Même le respect de ces limites est nuancé : un contenu pré-encodé ou un relais sélectif peut ne pas disposer d’une représentation exactement adaptée. L’acceptation de l’offre ne ferme donc pas la boucle d’exécution.
Avant de lire F, P_DIFF ou SS, il faut conserver la version de l’offre/réponse, le mapping du payload type, le profil, les capacités et toute renégociation. Un octet sans son contrat de session peut être syntaxiquement lisible et sémantiquement faux.
Sources
- Heng Lu — Minimum Initial Specification
- Heng Lu — Running-Code Primacy
- IETF Datatracker — historique de la RFC 9628
- Spécification du bitstream et du décodage VP9 v0.6
- IANA — paramètres RTP
- RFC 3264 — offre/réponse
- RFC 3550 — RTP
- RFC 4585 — retours RTP/AVPF
- RFC 5104 — retours de contrôle codec
- RFC 7667 — topologies RTP
- RFC 8866 — SDP
- RFC 9626 — Video Frame Marking
- RFC 9627 — Layer Refresh Request
- RFC 9628 — statut
- RFC 9628 — HTML
- RFC 9628 — texte canonique
- RFC 9628 — XML canonique
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance

