Aller au contenu principal

4. Extensions des rapports de réception RTCP

Le présent mémoire spécifie six nouveaux messages de Feedback. Le Full Intra Request (FIR), le Temporal-Spatial Trade-off Request (TSTR), le Temporal-Spatial Trade-off Notification (TSTN) et le Video Back Channel Message (VBCM) sont des « Payload Specific Feedback Messages » tels que définis à la section 6.3 d'AVPF [RFC4585]. Le Temporary Maximum Media Stream Bit Rate Request (TMMBR) et le Temporary Maximum Media Stream Bit Rate Notification (TMMBN) sont des « Transport Layer Feedback Messages » tels que définis à la section 6.2 d'AVPF.

Les nouveaux messages de Feedback sont définis dans les sous-sections suivantes, selon une structure analogue à celle des sections 6.2 et 6.3 de la spécification AVPF [RFC4585].

4.1. Principes de conception du mécanisme d'extension​

RTCP a été introduit à l'origine comme canal pour transmettre la présence, des statistiques de qualité de réception et des indications sur le codage média souhaité. Un ensemble limité de mécanismes de contrôle média a été introduit dans les premiers formats de charge utile RTP pour la vidéo, par exemple dans la RFC 2032 [RFC2032] (rendue obsolète par la RFC 4587 [RFC4587]). Toutefois, la présente spécification suggère pour la première fois une poignée de main bidirectionnelle pour certains de ses messages. Il existe un risque que cette introduction soit mal comprise comme un précédent pour l'utilisation de RTCP comme protocole de contrôle de session RTP. Pour éviter une telle méprise, la présente sous-section tente de clarifier la portée des extensions spécifiées dans ce mémoire, et elle suggère fortement que les extensions futures suivent la logique exposée ici, ou expliquent de manière convaincante pourquoi elles s'en écartent.

Dans ce mémoire, et dans AVPF [RFC4585], seuls les messages suivants ont été inclus :

a) qui ont des contraintes temps réel relativement strictes, qui empêchent l'utilisation de mécanismes tels qu'une re-invitation SIP dans la plupart des scénarios applicatifs (les contraintes temps réel sont expliquées séparément pour chaque message lorsque nécessaire) ;

b) qui sont sûrs pour le multicast en ce sens que la réaction à des messages de Feedback potentiellement contradictoires est spécifiée, comme nécessaire pour chaque message ; et

c) qui sont directement liés aux activités d'un codec média donné, d'une classe de codecs médias (par ex. codecs vidéo) ou d'un flux de paquets RTP donné.

Dans ce mémoire, une poignée de main bidirectionnelle n'est introduite que pour les messages pour lesquels :

a) une notification ou un accusé de réception est requis en raison de leur nature. Une analyse pour déterminer si cette exigence existe a été effectuée séparément pour chaque message.

b) la notification ou l'accusé de réception ne peut pas être facilement déduit du flux de bits média.

Tous les messages dans AVPF [RFC4585] et dans ce mémoire présentent leur contenu dans un format binaire fixe et simple. Cela convient aux récepteurs médias qui n'ont pas implémenté des fonctionnalités de protocole de contrôle de plus haut niveau (SDP, analyseurs XML, etc.) sur leur chemin média.

Les messages qui ne respectent pas les principes de conception qui viennent d'être décrits ne constituent pas un usage approprié de RTCP ni du Codec Control Framework défini dans ce document.

4.2. Messages de Feedback de la couche transport​

Comme spécifié à la section 6.1 de la RFC 4585 [RFC4585], les messages de Feedback de la couche transport sont identifiés par la valeur de type de paquet RTCP RTPFB (205).

Dans AVPF, un message de cette catégorie avait été défini. Ce mémoire en spécifie deux autres. Ils sont identifiés au moyen du paramètre de type de message de Feedback (FMT) comme suit :

Attribué dans AVPF [RFC4585] :

  • 1 : Generic NACK
  • 31 : réservé pour l'extension future de l'espace des numéros d'identifiant

Attribué dans ce mémoire :

  • 2 : réservé (voir la note ci-dessous)

  • 3 : Temporary Maximum Media Stream Bit Rate Request (TMMBR)

  • 4 : Temporary Maximum Media Stream Bit Rate Notification (TMMBN)

    Note : les premières versions d'AVPF [RFC4585] réservaient FMT=2 pour un point de code ultérieurement retiré. Il a été signalé qu'il peut exister sur le terrain des implémentations utilisant cette valeur conformément au document expiré. Comme l'espace de numérotation est suffisant, nous marquons FMT=2 comme réservé afin d'éviter d'éventuels problèmes d'interopérabilité avec de telles implémentations précoces.

Disponible pour attribution :

  • 0 : non attribué
  • 5-30 : non attribué

La sous-section suivante définit les formats des entrées d'informations de contrôle du Feedback (FCI) pour les messages TMMBR et TMMBN respectivement, et spécifie le comportement associé chez l'émetteur et le récepteur média.

4.2.1. Temporary Maximum Media Stream Bit Rate Request (TMMBR)​

Le Temporary Maximum Media Stream Bit Rate Request est identifié par la valeur de type de paquet RTCP PT=RTPFB et FMT=3.

Le champ FCI d'un message Temporary Maximum Media Stream Bit Rate Request (TMMBR) DOIT contenir une ou plusieurs entrées FCI.

4.2.1.1. Format du message​

Les informations de contrôle du Feedback (FCI) se composent d'une ou plusieurs entrées FCI TMMBR avec la syntaxe suivante :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp |  MxTBR Mantissa                 |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2 - Syntaxe d'une entrée FCI dans le message TMMBR

  • SSRC (32 bits) : La valeur SSRC de l'émetteur média auquel on demande de respecter le nouveau débit maximal.

  • MxTBR Exp (6 bits) : L'échelle exponentielle de la mantisse pour la valeur du débit média total maximal. La valeur est un entier non signé [0..63].

  • MxTBR Mantissa (17 bits) : La mantisse de la valeur du débit média total maximal comme entier non signé.

  • Measured Overhead (9 bits) : La valeur moyenne mesurée de la surcharge de paquet en octets. La mesure DOIT être effectuée conformément à la description à la section 4.2.1.2. La valeur est un entier non signé [0..511].

La valeur du débit média total maximal (MxTBR) en bits par seconde est calculée à partir de l'exposant MxTBR (exp) et de la mantisse de la manière suivante :

MxTBR = mantissa * 2^exp

Cela permet une résolution de 17 bits dans la plage 0 à 1310722^63 (environ 1,210^24).

La longueur du message de Feedback TMMBR DOIT être fixée à 2+2*N où N est le nombre d'entrées FCI TMMBR.

4.2.1.2. Sémantique​

Comportement chez le récepteur média (émetteur du TMMBR)

TMMBR sert à indiquer une limitation liée au transport au niveau de l'entité de rapport agissant comme récepteur média. TMMBR a la forme d'un n-uplet contenant deux composantes. La première valeur est le débit maximal par émetteur d'un flux média, disponible à une couche protocolaire choisie par le récepteur, que le récepteur prend actuellement en charge dans cette session RTP. La deuxième valeur est la surcharge d'en-tête mesurée en octets telle que définie à la section 2.2 et mesurée à la couche protocolaire choisie dans les paquets reçus pour le flux. La mesure de la surcharge est une moyenne glissante mise à jour pour chaque paquet reçu pour cette source média particulière (SSRC), selon la formule suivante :

avg_OH (new) = 15/16*avg_OH (old) + 1/16*pckt_OH,

où avg_OH est la moyenne glissante (lissée exponentiellement) et pckt_OH est la surcharge observée dans le dernier paquet.

Si un débit maximal a été négocié par signalisation, le débit média total maximal que le récepteur rapporte dans un message TMMBR NE DOIT PAS dépasser la valeur négociée convertie sur une base commune (c'est-à-dire avec des surcharges ajustées pour la ramener à la même couche protocolaire de référence).

Dans l'en-tête de paquet commun pour les messages de Feedback (tel que défini à la section 6.1 de [RFC4585]), le champ « SSRC of packet sender » indique la source de la demande, et le « SSRC of media source » n'est pas utilisé et DOIT être fixé à 0. Dans une entrée FCI TMMBR particulière, le « SSRC of media source » dans le champ FCI désigne l'émetteur média auquel le n-uplet s'applique. Cela est utile dans les topologies multicast ou traducteur où l'entité de rapport peut s'adresser à tous les émetteurs médias dans un seul message TMMBR en utilisant plusieurs entrées FCI.

Le récepteur média DOIT enregistrer le contenu du dernier message TMMBN reçu de chaque émetteur média.

Le récepteur média PEUT envoyer une entrée FCI TMMBR à un émetteur média particulier dans les circonstances suivantes :

  • avant qu'aucun message TMMBN n'ait été reçu de cet émetteur média ;

  • lorsque le récepteur média a été identifié comme la source d'un n-uplet bornant dans le dernier message TMMBN reçu de cet émetteur média, et que la valeur du débit média total maximal ou la surcharge relative à cet émetteur média a changé ;

  • lorsque le récepteur média n'a pas été identifié comme la source d'un n-uplet bornant dans le dernier message TMMBN reçu de cet émetteur média, et, après que le récepteur média applique l'algorithme incrémental de la section 3.5.4.2 ou un équivalent plus strict, le n-uplet du récepteur média relatif à cet émetteur média est déterminé comme appartenant à l'ensemble bornant.

Une entrée FCI TMMBR PEUT être répétée dans des messages TMMBR ultérieurs si aucune FCI Temporary Maximum Media Stream Bit Rate Notification (TMMBN) n'a été reçue de l'émetteur média au moment de la transmission du prochain paquet RTCP. La valeur de débit d'une entrée FCI TMMBR PEUT être modifiée d'un message TMMBR au suivant. La mesure de surcharge DOIT être mise à jour à la valeur courante de avg_OH chaque fois que l'entrée est envoyée.

Si la valeur fixée par un message TMMBR est censée être permanente, la partie qui fixe le TMMBR DEVRAIT renégocier les paramètres de session pour le refléter via la signalisation d'établissement de session, par ex. une re-invitation SIP.

Comportement chez l'émetteur média (récepteur du TMMBR)

Lorsqu'il reçoit un message TMMBR contenant une entrée FCI le concernant, l'émetteur média DOIT utiliser un algorithme initial ou incrémental selon le cas pour déterminer l'ensemble bornant de n-uplets à partir des nouvelles informations. L'algorithme utilisé DOIT être au moins aussi strict que l'algorithme correspondant défini à la section 3.5.4.2. L'émetteur média PEUT accumuler des TMMBR sur un petit intervalle (relatif à l'intervalle d'envoi RTCP) avant d'effectuer ce calcul.

Une fois l'ensemble bornant de n-uplets déterminé, l'émetteur média PEUT utiliser toute combinaison de débit de paquets et de débit média net dans la région réalisable que ces n-uplets décrivent pour produire un débit de flux média total inférieur, s'il doit par exemple faire face à une situation de congestion ou à d'autres facteurs limitants. Voir la section 5 (contrôle de congestion) pour plus de discussion.

Si l'émetteur média conclut qu'il peut augmenter la valeur du débit média total maximal, il DOIT attendre avant de le faire réellement, pendant une période suffisamment longue pour permettre à un récepteur média de répondre au TMMBN s'il détermine que son n-uplet appartient à l'ensemble bornant. Cette période de temporisation est estimée par la formule :

2 * RTT + T_Dither_Max,

où RTT est le temps aller-retour le plus long connu de l'émetteur média et T_Dither_Max est défini à la section 3.4 de [RFC4585]. Même en sessions point à point, un émetteur média DOIT respecter la règle susmentionnée, car il n'est pas garanti qu'un participant puisse déterminer correctement si toutes les sources sont colocalisées sur un seul nœud et coordonnées.

Un message TMMBN DOIT être envoyé par l'émetteur média au plus tôt possible, en réponse à tout message TMMBR reçu depuis le dernier envoi de TMMBN. Le message TMMBN indique l'ensemble calculé de n-uplets bornants et les propriétaires de ces n-uplets au moment de la transmission du message.

Un SSRC peut expirer selon les règles par défaut pour les participants à une session RTP, c'est-à-dire que l'émetteur média n'a reçu aucun paquet RTP ou RTCP du propriétaire pendant les cinq derniers intervalles de rapport réguliers. Un SSRC peut aussi quitter explicitement la session, le participant l'indiquant par la transmission d'un paquet RTCP BYE ou via un canal de signalisation externe. Si l'émetteur média détermine que le propriétaire d'un n-uplet dans l'ensemble bornant a quitté la session, l'émetteur média DOIT transmettre un nouveau TMMBN contenant l'ensemble précédemment déterminé de n-uplets bornants mais sans le n-uplet appartenant au propriétaire parti.

Un émetteur média PEUT initier de manière proactive l'équivalent d'un message TMMBR vers lui-même lorsqu'il sait que son chemin de transmission est plus restrictif que les limitations actuelles. Il en résulte l'envoi d'un TMMBN indiquant la source média elle-même comme propriétaire d'un n-uplet, évitant ainsi des messages TMMBR inutiles d'autres participants. Toutefois, comme tout autre participant, lorsque l'émetteur média prend conscience de limitations modifiées, il doit modifier le n-uplet et envoyer un TMMBN correspondant.

Discussion

En raison de la nature non fiable du transport des TMMBR et TMMBN, les règles ci-dessus peuvent conduire à l'envoi de messages TMMBR qui semblent enfreindre ces règles. De plus, en scénarios multicast, il peut arriver que plus d'un participant à la session « non propriétaire » détermine, à tort ou à raison, que son n-uplet appartient à l'ensemble bornant. Ce n'est pas critique pour plusieurs raisons :

a) Si un message TMMBR est perdu en transmission, soit l'émetteur média envoie un nouveau message TMMBN en réponse à un autre récepteur média, soit il n'envoie pas de nouveau message TMMBN du tout. Dans le premier cas, le récepteur média applique l'algorithme incrémental et, s'il détermine que son n-uplet doit faire partie de l'ensemble bornant, envoie un autre TMMBR. Dans le second cas, il répète l'envoi d'un TMMBR sans condition. Dans tous les cas, l'émetteur média finit par obtenir les informations dont il a besoin.

b) De même, si un message TMMBN est perdu, le récepteur média qui a envoyé le TMMBR correspondant ne reçoit pas la notification et doit renvoyer la demande et déclencher la transmission d'un autre TMMBN.

c) Si plusieurs messages TMMBR concurrents sont envoyés par différents participants à la session, l'algorithme peut être appliqué en tenant compte de tous ces messages, et le TMMBN résultant fournit aux participants une vue mise à jour de la comparaison de leurs n-uplets avec l'ensemble borné.

d) Si plus d'un participant à la session envoie des messages TMMBR au même moment et avec les mêmes valeurs de composantes du n-uplet, il importe peu lequel de ces n-uplets est pris dans l'ensemble bornant. Le participant perdant déterminera, après application de l'algorithme, que son n-uplet n'entre pas dans l'ensemble bornant, et cessera donc d'envoyer son TMMBR.

Il est important de considérer les risques de sécurité liés à des TMMBR falsifiés. Voir les considérations de sécurité à la section 6.

Comme déjà indiqué, les messages de Feedback peuvent être utilisés en sessions multicast et unicast dans toutes les topologies spécifiées. Toutefois, pour les sessions avec un grand nombre de participants, utiliser le plus petit commun dénominateur, comme l'exige ce mécanisme, peut ne pas être la voie la plus adaptée. Les grandes sessions peuvent devoir envisager d'autres moyens d'adapter le débit aux capacités des participants, tels que partitionner la session en différents niveaux de qualité ou utiliser une autre méthode pour obtenir l'évolutivité du débit.

4.2.1.3. Règles de temporisation​

La première transmission du message TMMBR PEUT utiliser un Feedback anticipé ou immédiat lorsque la rapidité est souhaitable. Toute répétition d'un message de demande DEVRAIT utiliser le mode RTCP régulier pour sa temporisation d'envoi.

4.2.1.4. Traitement dans les traducteurs et mélangeurs​

Les traducteurs et mélangeurs médias devront recevoir et répondre aux messages TMMBR car ils font partie de la chaîne qui fournit un flux média donné au récepteur. Le mélangeur ou traducteur peut agir localement sur le TMMBR et ainsi générer un TMMBN pour indiquer qu'il l'a fait. Alternativement, dans le cas d'un traducteur média, il peut transmettre la demande, ou dans le cas d'un mélangeur en générer une propre et la faire suivre. Dans ce dernier cas, le mélangeur devra envoyer un TMMBN en retour au demandeur d'origine pour indiquer qu'il traite la demande.

4.2.2. Temporary Maximum Media Stream Bit Rate Notification (TMMBN)​

Le Temporary Maximum Media Stream Bit Rate Notification est identifié par la valeur de type de paquet RTCP PT=RTPFB et FMT=4.

Le champ FCI du message de Feedback TMMBN peut contenir zéro, une ou plusieurs entrées FCI TMMBN.

4.2.2.1. Format du message​

Les informations de contrôle du Feedback (FCI) se composent de zéro, une ou plusieurs entrées FCI TMMBN avec la syntaxe suivante :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp |  MxTBR Mantissa                 |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3 - Syntaxe d'une entrée FCI dans le message TMMBN

  • SSRC (32 bits) : La valeur SSRC du « propriétaire » de ce n-uplet.

  • MxTBR Exp (6 bits) : L'échelle exponentielle de la mantisse pour la valeur du débit média total maximal. La valeur est un entier non signé [0..63].

  • MxTBR Mantissa (17 bits) : La mantisse de la valeur du débit média total maximal comme entier non signé.

  • Measured Overhead (9 bits) : La valeur moyenne mesurée de la surcharge de paquet en octets représentée comme entier non signé [0..511].

Ainsi, le FCI dans le message TMMBN contient des entrées indiquant les n-uplets bornants. Pour chaque n-uplet, l'entrée donne le propriétaire par le SSRC, suivi du débit média total maximal applicable et de la valeur de surcharge.

La longueur du message TMMBN DOIT être fixée à 2+2*N où N est le nombre d'entrées FCI TMMBN.

4.2.2.2. Sémantique​

Ce message de Feedback sert à notifier les émetteurs de tout message TMMBR qu'un ou plusieurs messages TMMBR ont été reçus ou qu'un propriétaire a quitté la session. Il indique à tous les participants l'ensemble courant de n-uplets bornants et les « propriétaires » de ces n-uplets.

Dans l'en-tête de paquet commun pour les messages de Feedback (tel que défini à la section 6.1 de [RFC4585]), le champ « SSRC of packet sender » indique la source de la notification. Le « SSRC of media source » n'est pas utilisé et DOIT être fixé à 0.

Un message TMMBN DOIT être planifié pour transmission après la réception d'un message TMMBR avec une entrée FCI identifiant cet émetteur média. Un seul TMMBN DOIT être envoyé, même si plus d'un message TMMBR est reçu entre la planification de la transmission et la transmission effective du message TMMBN. Le message TMMBN indique les n-uplets bornants et leurs propriétaires au moment de transmettre le message. Les n-uplets bornants inclus DOIVENT être l'ensemble obtenu par application de l'algorithme applicable de la section 3.5.4.2 ou d'un équivalent, appliqué à l'ensemble bornant précédent, le cas échéant, et aux n-uplets reçus dans les messages TMMBR depuis le dernier TMMBN transmis.

La réception d'un message TMMBR DOIT tout de même entraîner la transmission d'un message TMMBN même si, après application de l'algorithme, le nouveau n-uplet TMMBR rapporté n'est pas accepté dans l'ensemble bornant. Dans un tel cas, les n-uplets bornants et leurs propriétaires ne sont pas modifiés, sauf si le TMMBR provenait d'un propriétaire d'un n-uplet dans l'ensemble bornant précédemment calculé. Cette procédure permet aux participants à la session qui n'ont pas vu le dernier message TMMBN d'obtenir une vue correcte de l'état de cet émetteur média.

Comme indiqué à la section 4.2.1.2, lorsqu'un émetteur média détermine qu'un « propriétaire » d'un n-uplet bornant a quitté la session, ce n-uplet est retiré de l'ensemble bornant, et l'émetteur média DOIT envoyer un message TMMBN indiquant les n-uplets bornants restants. S'il ne reste aucun n-uplet bornant, un TMMBN sans aucun FCI DOIT être envoyé pour l'indiquer. Sans n-uplet bornant restant, s'appliquent le débit média maximal et le débit maximal de paquets négociés dans la signalisation de session, le cas échéant.

Note : s'il reste des récepteurs médias dans la session, cette dernière situation sera temporaire. Le TMMBN vide fera que chaque récepteur média restant déterminera que sa limitation appartient à l'ensemble bornant et enverra un TMMBR en conséquence.

En scénarios unicast (c'est-à-dire lorsqu'un seul émetteur parle à un seul récepteur), l'algorithme susmentionné pour déterminer la propriété se réduit au récepteur média devenant le « propriétaire » du seul n-uplet bornant dès qu'il a émis le premier message TMMBR.

4.2.2.3. Règles de temporisation​

L'accusé de réception TMMBN DEVRAIT être envoyé dès que les règles de temporisation appliquées à la session le permettent. Le mode de Feedback immédiat ou anticipé DEVRAIT être utilisé pour ces messages.

4.2.2.4. Traitement par les traducteurs et mélangeurs​

Comme discuté à la section 4.2.1.4, les mélangeurs ou traducteurs peuvent devoir émettre des messages TMMBN en réponse aux messages TMMBR pour les SSRC qu'ils gèrent.

4.3. Messages de Feedback spécifiques à la charge utile​

Comme spécifié par la section 6.1 de la RFC 4585 [RFC4585], les messages Payload-Specific FB sont identifiés par la valeur de type de paquet RTCP PSFB (206). AVPF [RFC4585] définit trois messages de Feedback spécifiques à la charge utile et un message de Feedback de couche application. Ce mémoire spécifie quatre messages de Feedback spécifiques à la charge utile supplémentaires. Tous sont identifiés au moyen du paramètre FMT comme suit :

Attribué dans [RFC4585] :

  • 1 : Picture Loss Indication (PLI)
  • 2 : Slice Lost Indication (SLI)
  • 3 : Reference Picture Selection Indication (RPSI)
  • 15 : message de Feedback de couche application
  • 31 : réservé pour l'extension future de l'espace des numéros

Attribué dans ce mémoire :

  • 4 : commande Full Intra Request (FIR)
  • 5 : Temporal-Spatial Trade-off Request (TSTR)
  • 6 : Temporal-Spatial Trade-off Notification (TSTN)
  • 7 : Video Back Channel Message (VBCM)

Non attribué :

  • 0 : non attribué
  • 8-14 : non attribué
  • 16-30 : non attribué

Les sous-sections suivantes définissent les nouveaux formats FCI pour les messages de Feedback spécifiques à la charge utile.

4.3.1. Full Intra Request (FIR)​

Le message FIR est identifié par la valeur de type de paquet RTCP PT=PSFB et FMT=4.

Le champ FCI DOIT contenir une ou plusieurs entrées FIR. Chaque entrée s'applique à un émetteur média différent, identifié par son SSRC.

4.3.1.1. Format du message​

Les informations de contrôle du Feedback (FCI) pour le Full Intra Request se composent d'une ou plusieurs entrées FCI dont le contenu est représenté à la figure 4. La longueur du message de Feedback FIR DOIT être fixée à 2+2*N, où N est le nombre d'entrées FCI.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr.       |    Reserved                                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4 - Syntaxe d'une entrée FCI dans le message FIR

  • SSRC (32 bits) : La valeur SSRC de l'émetteur média auquel on demande d'envoyer un point de rafraîchissement du décodeur.

  • Seq nr. (8 bits) : Numéro de séquence de commande. L'espace des numéros de séquence est unique pour chaque paire constituée du SSRC de la source de commande et du SSRC de la cible de commande. Le numéro de séquence DOIT être augmenté de 1 modulo 256 pour chaque nouvelle commande. Une répétition NE DOIT PAS augmenter le numéro de séquence. La valeur initiale est arbitraire.

  • Reserved (24 bits) : Tous les bits DOIVENT être fixés à 0 par l'émetteur et DOIVENT être ignorés à la réception.

La sémantique de ce message de Feedback est indépendante du type de charge utile RTP.

4.3.1.2. Sémantique​

Dans l'en-tête de paquet commun pour les messages de Feedback (tel que défini à la section 6.1 de [RFC4585]), le champ « SSRC of packet sender » indique la source de la demande, et le « SSRC of media source » n'est pas utilisé et DOIT être fixé à 0. Les SSRC des émetteurs médias auxquels la commande FIR s'applique figurent dans les entrées FCI correspondantes. Un message FIR PEUT contenir des demandes à plusieurs émetteurs médias, en utilisant une entrée FCI par émetteur média cible.

À la réception d'un FIR, l'encodeur DOIT envoyer un point de rafraîchissement du décodeur (voir section 2.2) dès que possible.

L'émetteur DOIT tenir compte du contrôle de congestion comme exposé à la section 5, ce qui PEUT limiter sa capacité à envoyer rapidement un point de rafraîchissement du décodeur.

FIR NE DOIT PAS être envoyé en réaction à des pertes d'image — il est RECOMMANDÉ d'utiliser plutôt PLI [RFC4585]. FIR DEVRAIT être utilisé uniquement dans les situations où ne pas envoyer un point de rafraîchissement du décodeur rendrait la vidéo inutilisable pour les utilisateurs.

Un exemple typique où l'envoi de FIR est approprié est lorsque, dans une conférence multipoint, un nouvel utilisateur rejoint la session et qu'aucun intervalle régulier de point de rafraîchissement du décodeur n'est établi. Un autre exemple serait un MCU vidéo commutateur qui change de flux. Ici, normalement, le MCU émet un FIR vers le nouvel émetteur pour le forcer à émettre un point de rafraîchissement du décodeur. Le point de rafraîchissement du décodeur inclut normalement un Freeze Picture Release (défini en dehors de cette spécification), qui relance le processus de rendu des récepteurs. Les deux techniques mentionnées sont couramment utilisées dans les conférences multipoint basées sur MCU.

D'autres spécifications de charge utile RTP telles que la RFC 2032 [RFC2032] définissent déjà un mécanisme de Feedback pour certains codecs. Une application prenant en charge les deux schémas DOIT utiliser le mécanisme de Feedback défini dans cette spécification lors de l'envoi de Feedback. Pour des raisons de rétrocompatibilité, une telle application DEVRAIT aussi être capable de recevoir et de réagir au schéma de Feedback défini dans le format de charge utile RTP respectif, si ce format l'exige.

4.3.1.3. Règles de temporisation​

La temporisation suit les règles exposées à la section 3 de [RFC4585]. Les commandes FIR PEUVENT être utilisées avec un Feedback anticipé ou immédiat. Le message de Feedback FIR PEUT être répété. Si le mode de Feedback immédiat est utilisé, la répétition DEVRAIT attendre au moins un RTT avant d'être envoyée. En mode RTCP anticipé ou régulier, la répétition est envoyée dans le prochain paquet RTCP régulier.

4.3.1.4. Traitement du message FIR dans les mélangeurs et traducteurs​

Un traducteur média ou un mélangeur effectuant l'encodage média du contenu pour lequel le participant à la session a émis un FIR est responsable d'y répondre. Un mélangeur agissant sur un FIR NE DEVRAIT PAS transmettre le message inchangé ; il DEVRAIT plutôt émettre un FIR lui-même.

4.3.1.5. Remarques​

Actuellement, la vidéo semble être la seule application utile pour FIR, car elle semble être la seule charge utile RTP largement déployée qui repose fortement sur la prédiction média au-delà des frontières de paquets RTP. Toutefois, l'utilisation de FIR pourrait aussi raisonnablement être envisagée pour d'autres types de médias partageant des propriétés essentielles avec la vidéo compressée, à savoir la prédiction inter-trames (quelle qu'elle soit une trame pour ce type de média). Un exemple possible pourrait être les mises à jour dynamiques des descriptions de scène MPEG-4. Il est suggéré que les formats de charge utile pour de tels types de médias renvoient à FIR et aux autres types de messages définis dans cette spécification et dans AVPF [RFC4585], au lieu de créer des mécanismes similaires dans les spécifications de charge utile. Les spécifications de charge utile peuvent devoir expliquer comment les terminologies spécifiques à la charge utile se mappent à la terminologie centrée vidéo utilisée ici.

En conjonction avec les codecs vidéo, les messages FIR déclenchent typiquement l'envoi d'images intra complètes ou IDR. Toutes deux sont plusieurs fois plus grandes que les images prédites (inter). Leur taille est indépendante du moment où elles sont générées. Dans la plupart des environnements, surtout avec des liaisons à bande passante limitée, l'utilisation d'une image intra implique un délai autorisé qui est un multiple significatif de la durée typique d'une trame. Un exemple : si le débit d'envoi de trames est de 10 ips, et qu'une image intra est supposée 10 fois plus grande qu'une image inter, alors une latence d'une seconde entière doit être acceptée. Dans un tel environnement, il n'est pas nécessaire d'avoir un délai particulièrement court pour l'envoi du message FIR. Par conséquent, attendre le prochain créneau temporel autorisé par les règles de temporisation RTCP selon [RFC4585] ne devrait pas avoir un impact trop négatif sur les performances du système.

Imposer un délai maximal pour achever l'envoi d'un point de rafraîchissement du décodeur serait souhaitable du point de vue applicatif, mais pose problème du point de vue du contrôle de congestion. « Dès que possible » comme mentionné ci-dessus semble un compromis raisonnable.

Dans les environnements où l'émetteur n'a aucun contrôle sur le codec (par ex. lors de la diffusion de contenu préenregistré et préencodé), la réaction à cette commande ne peut être spécifiée. Une réaction appropriée d'un émetteur serait d'avancer dans le flux binaire vidéo jusqu'au prochain point de rafraîchissement du décodeur. Dans d'autres scénarios, il peut être préférable de ne pas réagir à la commande du tout, par ex. lors de la diffusion vers un grand groupe multicast. D'autres réactions sont aussi possibles. En choisissant une stratégie, un émetteur pourrait tenir compte de facteurs tels que la taille du groupe récepteur, l'« importance » de l'émetteur du message FIR (quelle que soit la définition de l'importance dans cette application), la fréquence des points de rafraîchissement du décodeur dans le contenu, etc. Toutefois, on ne s'attend pas qu'une session traitant principalement du contenu préencodé utilise FIR du tout.

La relation entre l'indication de perte d'image (PLI) et FIR est la suivante. Comme discuté à la section 6.3.1 d'AVPF [RFC4585], une Picture Loss Indication informe le décodeur de la perte d'une image et donc de la probabilité de désalignement des images de référence entre l'encodeur et le décodeur. Un tel scénario est normalement lié à des pertes sur une connexion en cours. En point à point, et sans outils avancés de résilience aux erreurs, une option possible pour l'encodeur consiste à envoyer un point de rafraîchissement du décodeur. Toutefois, il existe d'autres options. Un exemple est que l'émetteur média ignore le PLI, car la redondance intégrée au flux est susceptible de corriger l'image reproduite dans un délai raisonnable. Le FIR, en revanche, ne laisse à un encodeur (temps réel) d'autre choix que d'envoyer un point de rafraîchissement du décodeur. Il ne permet pas à l'encodeur de tenir compte de considérations telles que celles mentionnées ci-dessus.

4.3.2. Temporal-Spatial Trade-off Request (TSTR)​

Le message de Feedback TSTR est identifié par la valeur de type de paquet RTCP PT=PSFB et FMT=5.

Le champ FCI DOIT contenir une ou plusieurs entrées FCI TSTR.

4.3.2.1. Format du message​

Le contenu de l'entrée FCI pour le Temporal-Spatial Trade-off Request est représenté à la figure 5. La longueur du message de Feedback DOIT être fixée à 2+2*N, où N est le nombre d'entrées FCI incluses.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Seq nr.      |  Reserved                           | Index   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5 - Syntaxe d'une entrée FCI dans le message TSTR

  • SSRC (32 bits) : Le SSRC de l'émetteur média auquel on demande d'appliquer la valeur de compromis donnée dans Index.

  • Seq nr. (8 bits) : Numéro de séquence de demande. L'espace des numéros de séquence est unique pour la paire constituée du SSRC de la source de demande et du SSRC de la cible de demande. Le numéro de séquence DOIT être augmenté de 1 modulo 256 pour chaque nouvelle commande. Une répétition NE DOIT PAS augmenter le numéro de séquence. La valeur initiale est arbitraire.

  • Reserved (19 bits) : Tous les bits DOIVENT être fixés à 0 par l'émetteur et DOIVENT être ignorés à la réception.

  • Index (5 bits) : Une valeur entière entre 0 et 31 indiquant le compromis relatif demandé. Une valeur d'index 0 indique la qualité spatiale la plus élevée possible, tandis que 31 indique la résolution temporelle la plus élevée possible.

4.3.2.2. Sémantique​

Un décodeur peut suggérer un niveau de compromis temporel-spatial en envoyant un message TSTR à un encodeur. Si l'encodeur est capable d'ajuster son compromis temporel-spatial, il DEVRAIT tenir compte du message TSTR reçu pour le codage futur des images. Une valeur 0 suggère une haute qualité spatiale et une valeur 31 suggère un débit de trames élevé. La progression des valeurs de 0 à 31 indique de manière monotone un souhait de débit de trames plus élevé. Les valeurs d'index ne correspondent pas à des valeurs précises de qualité spatiale ou de débit de trames.

La réaction à la réception de plus d'un message TSTR par un émetteur média provenant de différents récepteurs médias est laissée à l'implémentation. Le compromis choisi DOIT être communiqué aux récepteurs médias au moyen du message TSTN.

Dans l'en-tête de paquet commun pour les messages de Feedback (tel que défini à la section 6.1 de [RFC4585]), le champ « SSRC of packet sender » indique la source de la demande, et le « SSRC of media source » n'est pas utilisé et DOIT être fixé à 0. Les SSRC des émetteurs médias auxquels le TSTR s'applique figurent dans les entrées FCI correspondantes.

Un message TSTR PEUT contenir des demandes à plusieurs émetteurs médias, en utilisant une entrée FCI par émetteur média cible.

4.3.2.3. Règles de temporisation​

La temporisation suit les règles exposées à la section 3 de [RFC4585]. Ce message de demande n'est pas critique dans le temps et DEVRAIT être envoyé en utilisant la temporisation RTCP régulière. Seulement s'il est connu que l'interface utilisateur exige un Feedback rapide, le message PEUT être envoyé avec une temporisation de Feedback anticipée ou immédiate.

4.3.2.4. Traitement du message dans les mélangeurs et traducteurs​

Un mélangeur ou traducteur média qui encode le contenu envoyé au participant à la session ayant émis le TSTR DOIT examiner la demande pour déterminer s'il peut la satisfaire en modifiant ses propres paramètres d'encodage. Un traducteur média incapable de satisfaire la demande PEUT transmettre la demande inchangée vers l'émetteur média. Un mélangeur encodant pour plusieurs participants à la session devra examiner les besoins conjoints de ces participants avant de générer un TSTR en son propre nom vers l'émetteur média. Voir aussi la discussion à la section 3.5.2.

4.3.2.5. Remarques​

Le terme « qualité spatiale » ne renvoie pas nécessairement à la résolution mesurée par le nombre de pixels utilisés par la vidéo reconstruite. En fait, dans la plupart des scénarios, la résolution vidéo reste constante pendant la durée de vie d'une session. Toutefois, toutes les normes de compression vidéo offrent des moyens d'ajuster la qualité spatiale à une résolution donnée, souvent influencée par le paramètre quantificateur ou QP. Un QP numériquement faible donne une bonne qualité d'image reconstruite, tandis qu'un QP numériquement élevé produit une image grossière. La réaction typique d'un encodeur à cette demande est de modifier ses paramètres de contrôle de débit pour utiliser un débit de trames plus faible et un QP numériquement plus faible (en moyenne), ou l'inverse. Le mappage précis de la valeur Index au débit de trames et au QP est intentionnellement laissé ouvert ici, car il dépend de facteurs tels que la norme de compression employée, la résolution spatiale, le contenu, le débit, etc.

4.3.3. Temporal-Spatial Trade-off Notification (TSTN)​

Le message TSTN est identifié par la valeur de type de paquet RTCP PT=PSFB et FMT=6.

Le champ FCI DOIT contenir une ou plusieurs entrées FCI TSTN.

4.3.3.1. Format du message​

Le contenu d'une entrée FCI pour le Temporal-Spatial Trade-off Notification est représenté à la figure 6. La longueur du message TSTN DOIT être fixée à 2+2*N, où N est le nombre d'entrées FCI.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Seq nr.      |  Reserved                           | Index   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6 - Syntaxe du TSTN

  • SSRC (32 bits) : Le SSRC de la source du TSTR qui a entraîné cette Notification.

  • Seq nr. (8 bits) : La valeur du numéro de séquence du TSTR qui est accusé réception.

  • Reserved (19 bits) : Tous les bits DOIVENT être fixés à 0 par l'émetteur et DOIVENT être ignorés à la réception.

  • Index (5 bits) : La valeur de compromis que l'émetteur média utilise désormais.

Note informative : La valeur de compromis renvoyée (Index) peut différer de celle demandée, par exemple lorsqu'un encodeur média ne peut pas ajuster son compromis, ou lorsque du contenu préenregistré est utilisé.

4.3.3.2. Sémantique​

Ce message de Feedback sert à accuser réception de la réception d'un TSTR. Pour chaque TSTR reçu ciblant le participant à la session, une entrée FCI TSTN DOIT être envoyée dans un message de Feedback TSTN. Un seul message TSTN PEUT accuser réception de plusieurs demandes en utilisant plusieurs entrées FCI. La valeur d'index incluse DOIT être la même dans toutes les entrées FCI du message TSTN. Inclure une FCI pour chaque demandeur permet à chaque entité demandeuse de déterminer que l'émetteur média a reçu la demande. La Notification DOIT aussi être envoyée en réponse aux répétitions de TSTR reçues. Si le récepteur de la demande a reçu des TSTR avec plusieurs numéros de séquence différents d'un seul demandeur, il DOIT uniquement répondre à la demande avec le numéro de séquence le plus élevé (modulo 256). Noter que le numéro de séquence le plus élevé peut être une valeur entière plus petite en raison du retour à zéro du champ. L'annexe A.1 de [RFC3550] présente un algorithme pour suivre le numéro de séquence le plus élevé reçu pour les paquets RTP ; il pourrait être adapté à cet usage.

Le TSTN DOIT inclure l'index de compromis temporel-spatial qui sera utilisé suite à la demande. Ce n'est pas nécessairement le même index que celui demandé, car l'émetteur média peut devoir agréger des demandes de plusieurs participants demandeurs. Il peut aussi avoir d'autres politiques ou règles qui limitent le choix.

Dans l'en-tête de paquet commun pour les messages de Feedback (tel que défini à la section 6.1 de [RFC4585]), le champ « SSRC of packet sender » indique la source de la Notification, et le « SSRC of media source » n'est pas utilisé et DOIT être fixé à 0. Les SSRC des entités demandeuses auxquelles la Notification s'applique figurent dans les entrées FCI correspondantes.

4.3.3.3. Règles de temporisation​

La temporisation suit les règles exposées à la section 3 de [RFC4585]. Ce message d'accusé de réception n'est pas extrêmement critique dans le temps et DEVRAIT être envoyé en utilisant la temporisation RTCP régulière.

4.3.3.4. Traitement du TSTN dans les mélangeurs et traducteurs​

Un mélangeur ou traducteur qui agit sur un TSTR DOIT aussi envoyer le TSTN correspondant. Dans les cas où il doit transmettre un TSTR lui-même, le message de notification PEUT devoir être retardé jusqu'à ce que le TSTR ait reçu une réponse.

4.3.3.5. Remarques​

Aucune.

4.3.4. H.271 Video Back Channel Message (VBCM)​

Le VBCM est identifié par la valeur de type de paquet RTCP PT=PSFB et FMT=7.

Le champ FCI DOIT contenir une ou plusieurs entrées FCI VBCM.

4.3.4.1. Format du message​

La syntaxe d'une entrée FCI dans l'indication VBCM est représentée à la figure 7.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr.       |0| Payload Type| Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    VBCM Octet String....      |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7 - Syntaxe d'une entrée FCI dans le VBCM

  • SSRC (32 bits) : La valeur SSRC de l'émetteur média auquel on demande d'instruire son encodeur pour réagir au VBCM.

  • Seq nr. (8 bits) : Numéro de séquence de commande. L'espace des numéros de séquence est unique pour la paire constituée du SSRC de la source de commande et du SSRC de la cible de commande. Le numéro de séquence DOIT être augmenté de 1 modulo 256 pour chaque nouvelle commande. Une répétition NE DOIT PAS augmenter le numéro de séquence. La valeur initiale est arbitraire.

  • 0 : Doit être fixé à 0 par l'émetteur et ne doit pas être pris en compte par le récepteur du message.

  • Payload Type (7 bits) : Le type de charge utile RTP pour lequel le flux binaire VBCM doit être interprété.

  • Length (16 bits) : La longueur de la chaîne d'octets VBCM en octets, hors tout octet de remplissage.

  • VBCM Octet String (longueur variable) : Il s'agit de la chaîne d'octets générée par le décodeur portant un sous-message de Feedback spécifique.

  • Padding (longueur variable) : Bits fixés à 0 pour compléter une frontière de 32 bits.

4.3.4.2. Sémantique​

La « charge utile » de l'indication VBCM porte différents types d'informations de Feedback spécifiques au codec. Le type d'informations de Feedback peut être classé comme « rapport d'état » (tel qu'une indication que le flux binaire a été reçu sans erreurs, ou qu'une image ou un bloc partiel ou complet a été perdu) ou « demandes de mise à jour » (tel qu'un rafraîchissement complet du flux binaire).

Note : Il existe des chevauchements possibles entre les sous-messages VBCM et les messages de Feedback CCM/AVPF, tels que FIR. Voir la section 3.5.3 pour une discussion plus approfondie.

Les différents types de sous-messages de Feedback transportés dans le VBCM sont indiqués par le « payloadType » tel que défini dans [H.271]. Ces types de sous-messages sont reproduits ci-dessous pour commodité. « payloadType », dans la terminologie de la Rec. H.271 de l'UIT-T, renvoie au sous-type du message H.271 et ne doit pas être confondu avec un type de charge utile RTP.

Tableau 2 : types de messages H.271 (« payloadTypes »)

Payload TypeContenu du message
0Une ou plusieurs images sans discordance d'erreur de flux binaire détectée
1Une ou plusieurs images entièrement ou partiellement perdues
2Un ensemble de blocs d'une image entièrement ou partiellement perdue
3CRC pour un jeu de paramètres
4CRC pour tous les jeux de paramètres d'un certain type
5Une demande de « reset » indiquant que l'émetteur doit rafraîchir complètement le flux binaire vidéo comme si aucune donnée de flux binaire antérieure n'avait été reçue
> 5Réservé pour usage futur par l'UIT-T

La chaîne binaire ou la « charge utile » d'un VBCM est de longueur variable, autonome et codée dans un format binaire à longueur variable. L'émetteur média doit nécessairement être capable d'analyser ce format binaire optimisé pour utiliser les VBCM.

Chacun des différents types de sous-messages (indiqués par payloadType) peut avoir des sémantiques différentes selon le codec utilisé.

Dans l'en-tête de paquet commun pour les messages de Feedback (tel que défini à la section 6.1 de [RFC4585]), le champ « SSRC of packet sender » indique la source de la demande, et le « SSRC of media source » n'est pas utilisé et DOIT être fixé à 0. Les SSRC des émetteurs médias auxquels le VBCM s'applique figurent dans les entrées FCI correspondantes. L'émetteur du VBCM PEUT envoyer des messages H.271 à plusieurs émetteurs médias et PEUT envoyer plus d'un message H.271 au même émetteur média dans le même VBCM.

4.3.4.3. Règles de temporisation​

La temporisation suit les règles exposées à la section 3 de [RFC4585]. Les différents types de sous-messages peuvent avoir des propriétés différentes quant à la temporisation des messages à utiliser. Si plusieurs types différents sont inclus dans le même paquet de Feedback, les exigences du type de sous-message aux exigences les plus strictes DOIVENT être suivies.

4.3.4.4. Traitement du message dans les mélangeurs ou traducteurs​

Le traitement d'un VBCM dans un mélangeur ou traducteur dépend du type de sous-message.

4.3.4.5. Remarques​

Voir la section 3.5.3 pour une discussion de l'utilisation des messages H.271 et des messages définis dans AVPF [RFC4585] et ce mémoire ayant des fonctionnalités similaires.

Note : Il y a eu des discussions sur la nécessité du champ type de charge utile RTP dans ce message. Il sera nécessaire s'il peut y avoir plus d'un type de charge utile RTP compatible VBCM dans la même session, et si la sémantique d'un VBCM donné change entre types de charge utile. Par exemple, le mécanisme d'identification d'image dans les messages de type H.271 0 est fondamentalement différent entre H.263 et H.264 (bien que les deux utilisent la même syntaxe). Par conséquent, le champ charge utile est justifié ici. Un commentaire supplémentaire indiquait que pour TSTR et FIR un tel besoin n'existe pas, car les sémantiques de TSTR et FIR sont soit suffisamment lâches, soit suffisamment génériques pour s'appliquer à toutes les charges utiles vidéo actuellement existantes ou envisagées.

Dernière mise à jour le