Résumé

  • La RFC 9627 définit une commande RTCP ciblée pour obtenir un point de rafraîchissement dans une vidéo en couches, sans imposer la remise à zéro globale associée à un Full Intra Request.
  • Le numéro de séquence, les SSRC source et cible, le type de charge utile et les couches courante et visée identifient l’intention de commande ; ils n’attestent ni son admission, ni l’image produite, ni son arrivée, ni la montée effective du décodeur.
  • Une preuve exploitable relie négociation, autorisation, validation, arbitrage de congestion, émission propre au codec, réception, état du décodeur et résultat affiché.

Dans la console d’exploitation, la demande était verte. L’encodeur l’avait « reçue ». Pourtant, le participant était toujours servi dans la couche de base.

Le défaut ne se trouve pas forcément dans le protocole. Il peut résider dans le mot « reçue ». La RFC 9627 décrit un message de contrôle, le Layer Refresh Request, qui demande à l’émetteur de créer un point à partir duquel davantage de couches deviennent décodables. Elle ne donne pas au message le pouvoir de témoigner sur les étapes ultérieures.

Cette modestie est une qualité d’architecture. Le problème commence lorsqu’une interface transforme une demande bien formée en résultat accompli.

Rafraîchir une couche n’est pas réinitialiser tout le flux

Dans une structure spatiale, une image de couche supérieure dépend souvent à la fois de la couche inférieure du même instant et de ses propres images antérieures. Au point de rafraîchissement, elle ne doit plus se fonder sur ce passé de sa couche ; l’encodeur promet aussi de ne plus le réintroduire comme référence future.

Les autres couches peuvent conserver leur histoire. C’est ce qui distingue le LRR d’un FIR. Le Full Intra Request, précisé pour les codecs en couches par la RFC 8082, vise un point de rafraîchissement du décodeur pour l’ensemble concerné. Le LRR limite le coût aux sous-flux nécessaires à la progression demandée.

Pour les couches temporelles, le principe devient l’imbrication : la couche rafraîchie ne se réfère plus à son propre passé mais aux couches temporelles inférieures. Certaines structures sont déjà imbriquées en permanence. Dans ce cas, envoyer un LRR temporel ne crée aucune nouvelle possibilité de décodage.

Le point important est donc fonctionnel : le rafraîchissement modifie l’ensemble des références disponibles pour un décodeur donné. Une image intra isolée ou une hausse momentanée du débit n’en constitue pas automatiquement la preuve.

Le message décrit le passage souhaité

LRR est un retour RTCP propre à la charge utile, enregistré avec FMT=10. Une même trame de retour peut contenir plusieurs entrées, chacune visant le SSRC d’un émetteur média. Le SSRC de l’en-tête commun nomme la source de la commande ; le champ commun réservé à la source média vaut zéro, car les cibles sont portées par les entrées.

TTID et TLID indiquent la couche temporelle et la couche spatiale ou de qualité visées. Leur signification dépend du type de charge utile. Conserver le couple numérique sans la négociation qui associait ce type au codec revient à conserver une adresse sans son plan.

Le bit C décide si l’état courant est explicite. Avec C=0, toutes les couches jusqu’à la cible sont demandées. Avec C=1, CTID et CLID indiquent la plus haute couche que le demandeur affirme déjà décoder. La cible ne peut être inférieure sur aucun axe et doit être supérieure sur au moins un. Une requête qui viole cette règle doit être rejetée.

La validation va plus loin : l’émetteur doit vérifier que type de charge utile et indices existent réellement dans le flux qu’il envoie à cet instant. Une commande syntaxiquement correcte n’est donc pas encore une action admise.

Enfin, l’état courant reste une déclaration du récepteur. Il peut être précis, périmé ou contredit par la réalité du tampon de références. Le protocole transporte cette déclaration ; il ne lit pas lui-même le décodeur après l’opération.

Le numéro de séquence sépare nouveauté et répétition

Le compteur tient sur huit bits et appartient à un couple précis : SSRC source de commande et SSRC cible. Toute nouvelle commande l’incrémente modulo 256. La répétition de la même commande conserve la même valeur. Le premier nombre est arbitraire.

Ce choix reprend le modèle de fiabilité du FIR dans la RFC 5104. Le demandeur peut réémettre l’instruction en attente selon les règles temporelles RTCP. Il cesse lorsqu’il reconnaît un point de rafraîchissement complet, ou même une tentative endommagée par une perte. Un besoin ultérieur reçoit un nouveau numéro.

Le compteur répond donc utilement à une question : s’agit-il de la même intention ou d’une nouvelle ? Il ne répond pas : l’encodeur a-t-il accepté, produit et envoyé le bon point ? Aucun accusé de réception, identifiant d’image, horodatage d’exécution ou résultat de décodage n’est encodé dans ces huit bits.

Le retour à zéro après 255 interdit aussi d’archiver la valeur seule. Sans session, paire source-cible, tuple et temps, deux commandes portant le même numéro peuvent n’avoir aucun lien.

La congestion peut différer une obligation valide

Après une requête valide, l’encodeur doit produire un point de rafraîchissement dès que possible. Mais il doit également respecter les limites issues du contrôle de congestion. Or les images de rafraîchissement sont souvent plus volumineuses. La conformité peut donc prendre la forme d’une attente.

Cette tension mérite des états explicites : reçu, rejeté, admis, différé faute de budget, planifié, émis, observé, décodé, affiché. Une organisation peut juger un délai inacceptable tout en reconnaissant que l’arbitrage réseau était légitime. Appeler l’admission « succès » efface ce diagnostic.

Le message ne sert pas non plus à réparer une perte d’image. La RFC 9627 interdit d’envoyer un LRR en réaction à des paquets perdus ou corrompus et recommande le PLI de la RFC 4585. LRR accompagne une décision explicite du récepteur, par exemple commencer à décoder une couche qu’il écartait auparavant. Mélanger perte et montée volontaire rend tout motif de répétition équivoque.

La fermeture de preuve dépend du codec

Avec H.264 SVC, la couche est exprimée par les identifiants temporel, de dépendance et de qualité. Un rafraîchissement spatial peut exiger une indication appropriée sur chaque couche nécessaire, dans l’ordre de décodage. Une indication agrégée dans PACSI ne suffit pas toujours si plusieurs couches y sont mêlées.

VP8 ne propose ici que l’échelle temporelle. Son bit Y permet d’identifier un point de changement, mais il vaut pour toutes les couches. L’exécution peut donc être correcte tout en coûtant davantage que la cible abstraite ne le laisse penser.

H.265 combine drapeaux d’imbrication et types d’unités NAL. La satisfaction peut être immédiate, progressive à travers plusieurs couches temporelles, ou résulter d’une image IRAP. Aucun détecteur universel de « keyframe » ne couvre ces cas proprement.

La RFC 9628 attribue à VP9 ses indices TID/SID et recommande d’exposer indices et références afin que le décodeur ou un relais puisse remonter la chaîne de dépendance. Cette recommandation dit ce que doit établir la preuve : les images émises n’ont plus besoin d’un passé que le récepteur ne possède pas.

La syntaxe de ces indices est volontairement alignée sur la RFC 9626. Les marques de trame peuvent aider à reconnaître le point. Elles ne prouvent ni que le LRR l’a causé, ni que les paquets sont arrivés, ni que le décodeur a changé de couche.

Sources