6. Format des messages de feedback RTCP (Format of RTCP Feedback Messages)
Cette section définit le format des messages de feedback RTCP à faible délai. Ils se classent en trois catégories :
- Messages FB de couche transport
- Messages FB spécifiques à la charge utile
- Messages FB de couche application
Les messages FB de couche transport véhiculent du feedback à usage général, indépendant du codec ou de l'application. Ils sont produits et traités au niveau transport/RTP. Seul un acquittement négatif générique (NACK) est défini pour l'instant.
Les messages FB spécifiques à la charge utile portent des informations propres à un type de charge utile ; ils sont générés et utilisés au « niveau » codec. Ce document définit un en-tête commun à tous ces messages ; le détail des messages est laissé aux spécifications de format RTP ou à d'autres documents de feedback.
Les messages FB de couche application transportent de façon transparente le feedback de l'application réceptrice vers l'application émettrice. Leur contenu n'est en principe pas traité au niveau transport/RTP ni codec. Les données échangées sont en général définies par le protocole d'application et identifiables par l'application, sans information externe supplémentaire. Ce document ne définit donc qu'un en-tête commun ; du point de vue protocole, un FB application est un cas particulier de FB spécifique à la charge utile.
Note : Le traitement correct de certains FB côté émetteur média peut exiger de connaître le type de charge utile visé. Souvent cela se déduit d'un flux à type unique. Avec plusieurs codecs (audio et DTMF) ou changements de codec, l'information de type peut devoir figurer explicitement dans le FB. Cela vaut pour tous les FB spécifiques à la charge utile et application. La spécification du FB doit définir comment transmettre le type de charge utile.
Ce document définit deux FB de couche transport, trois FB vidéo spécifiques à la charge utile et un conteneur pour FB application. D'autres FB MAY être définis et MUST être enregistrés à l'IANA (section 9).
La syntaxe et la sémantique générales sont décrites ci-dessous.
6.1. Format de paquet commun pour les messages de feedback
Tous les FB MUST utiliser le format commun de la figure 3 :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Feedback Control Information (FCI) |
| |
Figure 3: Common Packet Format for Feedback Messages
Les champs V, P, SSRC et length sont définis dans [1] :
version (V) : 2 bits — Version RTP (2).
padding (P) : 1 bit — Si positionné, octets de bourrage en fin de paquet, inclus dans length.
Feedback message type (FMT) : 5 bits — Type du FB, relatif à la catégorie (transport, charge utile, application). Valeurs par section.
Payload type (PT) : 8 bits — Type RTCP identifiant un FB. Valeurs IANA :
| Name | Value | Brief Description |
|---|---|---|
| RTPFB | 205 | Transport layer FB message |
| PSFB | 206 | Payload-specific FB message |
Length : 16 bits — Longueur du paquet en mots de 32 bits moins un, en-tête et bourrage inclus (comme [1]).
SSRC of packet sender : 32 bits — SSRC de l'origine du paquet.
SSRC of media source : 32 bits — SSRC de la source média concernée.
Feedback Control Information (FCI) : longueur variable — Les trois sections suivantes précisent le contenu possible par type de feedback. D'autres contenus FCI MAY être spécifiés plus tard.
Chaque paquet de feedback RTCP MUST contenir au moins un FB dans le FCI. Les sections 6.2 et 6.3 indiquent si plusieurs FB MAY être regroupés dans un seul FCI ; dans ce cas ils MUST être du même type (même FMT). Pour plusieurs FMT, plusieurs messages RTCP FB MUST être générés et SHOULD être concaténés dans le même paquet RTCP composé.
6.2. Messages de feedback de couche transport
Identifiés par PT=RTPFB.
Un seul FB générique est défini ici : Generic NACK, avec FMT :
- 0 : non attribué
- 1 : Generic NACK
- 2-30 : non attribué
- 31 : réservé pour extension
D'autres FB génériques MAY être définis.
6.2.1. Generic NACK
PT=RTPFB, FMT=1. Le FCI MUST contenir au moins un et MAY plusieurs Generic NACK.
Indique la perte d'un ou plusieurs paquets RTP, identifiés par identifiant de paquet et masque de bits.
Generic NACK SHOULD NOT être utilisé si le transport sous-jacent fournit déjà un feedback comparable (ex. DCCP).
Syntaxe FCI (figure 4) :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID | BLP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Syntax for the Generic NACK message
Packet ID (PID) : 16 bits — Numéro de séquence RTP du paquet perdu.
bitmask of following lost packets (BLP) : 16 bits — Comme [6]. Bit i (LSB=1, MSB=16) vaut 1 si le paquet (PID+i) mod 2^16 n'a pas été reçu et est signalé perdu ; 0 sinon. L'émetteur MUST NOT déduire qu'un paquet a été reçu parce que le bit vaut 0 ; il sait seulement qu'il n'a pas été signalé perdu à cet instant.
La longueur du FB MUST être 2+n, n = nombre de Generic NACK dans le FCI.
Le Generic NACK référence implicitement le type de charge utile via les numéros de séquence.
6.3. Messages de feedback spécifiques à la charge utile
PT=PSFB. FMT :
| Value | Meaning |
|---|---|
| 0 | unassigned |
| 1 | Picture Loss Indication (PLI) |
| 2 | Slice Loss Indication (SLI) |
| 3 | Reference Picture Selection Indication (RPSI) |
| 4-14 | unassigned |
| 15 | Application layer FB (AFB) message |
| 16-30 | unassigned |
| 31 | reserved for future expansion of the sequence number space |
Les sous-sections suivantes décrivent les FCI ; la section 6.4 traite le FB application.
6.3.1. Picture Loss Indication (PLI)
PT=PSFB, FMT=1. Exactement une PLI dans le FCI MUST être présente.
6.3.1.1. Sémantique
Le décodeur signale la perte d'une quantité indéterminée de données vidéo codées pour une ou plusieurs images. Avec prédiction inter-image, l'encodeur apprend que la chaîne de prédiction peut être rompue. L'émetteur MAY répondre par une intra-image pour resynchroniser (proche du FIR [6]) ; il MUST respecter la congestion (section 7), ce qui MAY limiter l'envoi d'intra.
Si RFC 2032 [6] ou autre définit un autre mécanisme, une application supportant les deux MUST utiliser ce document pour l'envoi ; pour compatibilité elle SHOULD aussi pouvoir recevoir et réagir à l'ancien schéma si le format l'exige.
6.3.1.2. Format du message
Pas de paramètres : length MUST être 2, pas de FCI. Indépendant du type de charge utile.
6.3.1.3. Règles de temporisation
Selon la section 3. Avec PLI et autres FB, il peut être préférable d'utiliser les règles RR régulières pour la PLI (moins sensible au délai).
6.3.1.4. Remarques
Les PLI déclenchent souvent des intra complètes, beaucoup plus grosses que les inter, taille indépendante du moment. Sur liens limités, une intra implique souvent un délai multiple de la durée d'image (ex. 10 ips, intra ×10 : ~1 s de latence). Peu d'intérêt à hâter le FB ; attendre le créneau RTCP [2] avec Tmin=0 n'est pas nuisible.
6.3.2. Slice Loss Indication (SLI)
PT=PSFB, FMT=2. Au moins une SLI dans le FCI MUST être présente, MAY plusieurs.
6.3.2.1. Sémantique
Signale perte ou corruption d'une ou plusieurs macroblocs consécutifs en ordre de balayage. MUST NOT avec codecs à tailles de macroblocs non uniformes et dynamiques (ex. H.263 annexe Q activée).
6.3.2.2. Format
Figure 6. Length MUST être 2+n.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First | Number | PictureID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Syntax of the Slice Loss Indication (SLI)
First : 13 bits — Adresse du premier macrobloc perdu ; coin supérieur gauche = 1, numérotation raster (dernier = N).
Number : 13 bits — Nombre de macroblocs perdus en ordre de balayage.
PictureID : 6 bits — Six bits de poids faible de l'identifiant d'image du codec (souvent Temporal Reference).
Pas d'information explicite de type de charge utile ; applicabilité limitée.
6.3.2.3. Règles de temporisation
L'efficacité des algorithmes utilisant la Slice Loss Indication diminue fortement si l'indication n'est pas transmise rapidement. La compensation de mouvement propage des pixels corrompus non signalés comme tels. Par conséquent, l'utilisation de l'algorithme décrit en section 3 est fortement recommandée.
6.3.2.4. Remarques
Le terme Slice est défini ici au sens MPEG-1 : un nombre consécutif de macroblocs en ordre de balayage. Des normes plus récentes donnent parfois un autre sens à Slice. En H.263 (1998), par ex., existe la « rectangular slice » : la perte d'une slice rectangulaire peut exiger plus d'une SLI pour identifier précisément la région de MB perdus/endommagés.
Le premier champ du FCI définit le premier macrobloc d'une image comme 1 et non 0, pour s'aligner sur le mécanisme comparable de ITU-T Rec. H.245 [24]. Le nombre maximal de macroblocs par image (2**13 ou 8192) correspond aux tailles d'image maximales de la plupart des codecs ITU-T et ISO/IEC. Si de futurs codecs offrent des images plus grandes et/ou des macroblocs plus petits, un FB supplémentaire devra être défini. Les six bits de poids faible du Temporal Reference suffisent en principe pour indiquer l'image concernée.
La réaction à une SLI ne fait pas partie de cette spécification. Une réaction typique est l'intra-refresh sur la région spatiale affectée.
Des algorithmes suivent les régions affectées par la compensation de mouvement pour envoyer des macroblocs intra dans toutes ces zones, quel que soit le moment du FB (voir H.263 (2000) Annexe I [17] et [15]). Bien que le moment du FB soit moins critique avec ces algorithmes, ils corrigent de larges zones et doivent transmettre beaucoup plus de données en cas de FB retardé.
6.3.3. Reference Picture Selection Indication (RPSI)
PT=PSFB, FMT=3. Exactement une RPSI dans le FCI MUST être présente.
6.3.3.1. Sémantique
Les normes vidéo modernes telles que MPEG-4 visual version 2 [16] ou H.263 version 2 [17] permettent d'utiliser pour la prédiction des images de référence plus anciennes que la plus récente. On maintient typiquement une file FIFO de références. Si l'encodeur sait qu'une perte de synchronisation encodeur-décodeur est survenue, une image de référence connue comme correcte peut être utilisée ; étant temporellement plus éloignée, l'image codée en prédiction consommera plus de bits.
MPEG-4 et H.263 définissent un format binaire pour la « charge utile » d'un message RPSI, incluant par ex. l'identifiant temporel de l'image endommagée et la taille de la région endommagée. Cette chaîne de bits est en général petite (quelques dizaines de bits), de longueur variable et autonome : elle contient tout ce qui est nécessaire à la sélection d'image de référence.
MPEG-4 et H.263 autorisent aussi la RPSI avec feedback positif : on signale des images (ou slices) décodées sans erreur. Toute forme de feedback positif MUST NOT être utilisée en session multipoint (un feedback positif sur des références individuelles aux intervalles RTCP serait de toute façon peu utile).
6.3.3.2. Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB |0| Payload Type| Native RPSI bit string |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| defined per codec ... | Padding (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Syntax of the Reference Picture Selection Indication (RPSI)
PB : 8 bits — Bits inutilisés pour aligner sur 32 bits.
0 : 1 bit — MUST être 0 à l'envoi, ignoré à la réception.
Payload Type : 7 bits — Type RTP pour interpréter la chaîne RPSI native.
Native RPSI bit string : variable — Définition codec.
Padding : #PB bits — Zéros jusqu'à frontière 32 bits ; PB MUST indiquer le nombre.
6.3.3.3. Règles de temporisation
Plus critique que SLI : une RPSI tardive coûte plus de bits pour resynchroniser. Voir [15]. Envoyer dès que possible (section 3).
6.4. Messages de feedback de couche application
PT=PSFB, FMT=15. Cas particulier payload-spécifique. Exactement un FB application dans le FCI MUST être présent, sauf si la structure interne permet l'empilement (taille fixe ou longueur explicite).
Données définies par l'application, non identifiées par le FB : l'application MUST identifier la charge utile (ex. NEWPRED MPEG-4 [16]/RFC 3016 [23], H.263 Annexe N,U [17]/RFC 2429 [14]). Le message est placé dans le FCI ; length ajustée.
Application Message (FCI) : variable — Format propre à l'application. Si non aligné sur 32 bits, bourrage MUST être ajouté ; identification du bourrage : couche application, non spécifiée ici.
La spécification du FB application MUST indiquer si le contexte d'un codec (type de charge utile RTP) est requis ; si oui, elle MUST définir comment transporter le type de charge utile dans le FB lui-même.