6. Formato dei messaggi di feedback RTCP (Format of RTCP Feedback Messages)
Questa sezione definisce il formato dei messaggi di feedback RTCP a bassa latenza. Sono classificati in tre categorie:
- Messaggi FB a livello di trasporto
- Messaggi FB specifici del payload
- Messaggi FB a livello applicazione
I messaggi FB a livello di trasporto veicolano feedback di uso generale, indipendenti dal codec o dall'applicazione. Sono generati ed elaborati a livello trasporto/RTP. Per ora è definito solo un acknowledgment negativo generico (NACK).
I messaggi FB specifici del payload trasportano informazioni proprie di un tipo di payload; sono generati ed elaborati al « livello » codec. Questo documento definisce un'intestazione comune; il dettaglio dei messaggi è demandato alle specifiche dei formati di payload RTP o ad altri documenti di feedback.
I messaggi FB a livello applicazione trasportano in modo trasparente il feedback dall'applicazione ricevente a quella mittente. Il contenuto in genere non è elaborato a livello trasporto/RTP o codec. I dati scambiati sono di solito definiti dal protocollo applicativo e identificabili dall'applicazione senza ulteriori informazioni esterne. Questo documento definisce quindi solo un'intestazione comune; dal punto di vista del protocollo, un FB applicativo è un caso particolare di FB specifico del payload.
Nota: L'elaborazione corretta di alcuni FB lato mittente media può richiedere di sapere a quale tipo di payload si riferisce il FB. Spesso ciò si deduce da un flusso con un solo tipo. Con più codec (audio e DTMF) o cambi di codec, l'informazione sul tipo può dover essere inclusa esplicitamente nel FB. Vale per tutti i FB specifici del payload e applicativi. La specifica del FB deve definire come trasmettere il tipo di payload.
Questo documento definisce due FB a livello di trasporto, tre FB video specifici del payload e un contenitore per FB applicativo. Altri FB MAY essere definiti e MUST essere registrati presso IANA (sezione 9).
Sintassi e semantica generale sono descritte di seguito.
6.1. Formato di pacchetto comune per i messaggi di feedback
Tutti i FB MUST usare il formato comune della figura 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
I campi V, P, SSRC e length sono definiti in [1]:
version (V): 2 bit — Versione RTP (2).
padding (P): 1 bit — Se impostato, byte di padding in coda inclusi in length.
Feedback message type (FMT): 5 bit — Tipo di FB relativo alla categoria (trasporto, payload, applicazione). Valori nelle rispettive sezioni.
Payload type (PT): 8 bit — Tipo RTCP che identifica un messaggio FB. Valori IANA:
| Name | Value | Brief Description |
|---|---|---|
| RTPFB | 205 | Transport layer FB message |
| PSFB | 206 | Payload-specific FB message |
Length: 16 bit — Lunghezza del pacchetto in parole da 32 bit meno uno, intestazione e padding inclusi (come [1]).
SSRC of packet sender: 32 bit — SSRC dell'origine del pacchetto.
SSRC of media source: 32 bit — SSRC della sorgente media interessata.
Feedback Control Information (FCI): lunghezza variabile — Le tre sezioni seguenti definiscono le informazioni aggiuntive possibili per ciascun tipo. Altri contenuti FCI MAY essere specificati in seguito.
Ogni pacchetto di feedback RTCP MUST contenere almeno un FB nel campo FCI. Le sezioni 6.2 e 6.3 definiscono se più FB MAY essere compressi in un unico FCI; in tal caso MUST avere lo stesso tipo (stesso FMT). Per più FMT, MUST generare più messaggi RTCP FB e SHOULD concatenarli nello stesso pacchetto RTCP composto.
6.2. Messaggi di feedback a livello di trasporto
Identificati da PT=RTPFB.
È definito un solo FB generico: Generic NACK, con FMT:
- 0: non assegnato
- 1: Generic NACK
- 2-30: non assegnato
- 31: riservato per estensione
Altri FB generici MAY essere definiti.
6.2.1. Generic NACK
PT=RTPFB, FMT=1. Il FCI MUST contenere almeno un e MAY più Generic NACK.
Indica la perdita di uno o più pacchetti RTP tramite identificatore di pacchetto e maschera di bit.
Generic NACK SHOULD NOT essere usato se il protocollo di trasporto sottostante fornisce già feedback simile (es. DCCP).
Sintassi FCI (figura 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 bit — Numero di sequenza RTP del pacchetto perso.
bitmask of following lost packets (BLP): 16 bit — Come [6]. Il bit i (LSB=1, MSB=16) è 1 se il ricevitore non ha ricevuto il pacchetto RTP (PID+i) mod 2^16 e segnala la perdita; 0 altrimenti. Il mittente MUST NOT dedurre che un pacchetto sia stato ricevuto perché il bit è 0; sa solo che non è stato segnalato perso in quel momento.
La lunghezza del FB MUST essere 2+n, con n = numero di Generic NACK nel FCI.
Il Generic NACK referenzia implicitamente il tipo di payload tramite i numeri di sequenza.
6.3. Messaggi di feedback specifici del payload
PT=PSFB. Valori 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 |
Le sottosezioni seguenti definiscono i formati FCI; la sezione 6.4 definisce il FB applicativo.
6.3.1. Picture Loss Indication (PLI)
PT=PSFB, FMT=1. Nel FCI MUST essere presente esattamente una PLI.
6.3.1.1. Semantica
Il decodificatore segnala la perdita di una quantità indefinita di dati video codificati per una o più immagini. Con schema di predizione inter-immagine, il codificatore che riceve una PLI sa che la catena di predizione può essere rotta. Il mittente MAY rispondere con un'intra-immagine per risincronizzarsi (simile al FIR [6]); MUST considerare il controllo della congestione (sezione 7), che MAY limitare l'invio di intra.
Se RFC 2032 [6] o altro definisce un altro meccanismo, un'applicazione che supporta entrambi MUST usare questo documento per l'invio; per compatibilità SHOULD anche poter ricevere e reagire allo schema del rispettivo formato di payload se richiesto.
6.3.1.2. Formato del messaggio
Nessun parametro: length MUST essere 2, nessuna FCI. Semantica indipendente dal tipo di payload.
6.3.1.3. Regole di temporizzazione
Secondo la sezione 3. Con PLI e altri FB, può essere consigliabile seguire le regole RR regolari per la PLI (meno sensibile al ritardo).
6.3.1.4. Osservazioni
Le PLI spesso innescano intra complete, molto più grandi delle inter, con dimensione indipendente dal momento. Su collegamenti a banda limitata, un'intra implica spesso un ritardo multiplo della durata del frame (es. 10 fps, intra ×10: ~1 s di latenza). Poco vantaggio ad affrettare il FB; attendere lo slot RTCP [2] con Tmin=0 non nuoce.
6.3.2. Slice Loss Indication (SLI)
PT=PSFB, FMT=2. Almeno una SLI nel FCI MUST, MAY più di una.
6.3.2.1. Semantica
Segnala perdita o corruzione di uno o più macroblocchi consecutivi in ordine di scansione. MUST NOT con codec a dimensioni di macroblocco non uniformi e variabili (es. H.263 con annex Q abilitata).
6.3.2.2. Formato
Figura 6. La lunghezza del FB MUST essere 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 bit — Indirizzo del primo macroblocco perso; angolo in alto a sinistra = 1, numerazione raster (ultimo = N).
Number: 13 bit — Numero di macroblocchi persi in ordine di scansione.
PictureID: 6 bit — Sei bit meno significativi dell'identificatore d'immagine del codec (spesso Temporal Reference).
Nessuna informazione esplicita sul tipo di payload; applicabilità limitata.
6.3.2.3. Regole di temporizzazione
L'efficienza degli algoritmi che usano SLI diminuisce molto se l'indicazione non è trasmessa tempestivamente. La compensazione del moto propaga pixel corrotti non segnalati. Si raccomanda fortemente l'algoritmo della sezione 3.
6.3.2.4. Osservazioni
« Slice » qui è nel senso MPEG-1: macroblocchi consecutivi in ordine di scansione. Standard più recenti usano talvolta « slice » in modo diverso. In H.263 (1998) esiste la « rectangular slice »; la perdita di una slice rettangolare può richiedere più di una SLI per identificare la regione di MB persi/danneggiati.
Il primo campo del FCI definisce il primo macroblocco di un'immagine come 1 e non 0, per allineamento a ITU-T Rec. H.245 [24]. Il numero massimo di MB per immagine (2**13 o 8192) corrisponde alle dimensioni massime nella maggior parte dei codec ITU-T e ISO/IEC. Codec futuri con immagini più grandi e/o MB più piccoli richiederanno un FB aggiuntivo. I sei bit meno significativi del Temporal Reference sono ritenuti sufficienti per indicare l'immagine.
La reazione a una SLI non fa parte di questa specifica. Una reazione tipica è intra-refresh sulla regione spaziale interessata.
Esistono algoritmi che tracciano le regioni influenzate dalla compensazione del moto per inviare MB intra in tutte quelle aree indipendentemente dal timing del FB (H.263 (2000) Appendice I [17], [15]). Anche se il timing è meno critico, tali algoritmi correggono ampie zone e devono trasmettere molto più dato con FB ritardati.
6.3.3. Reference Picture Selection Indication (RPSI)
PT=PSFB, FMT=3. Esattamente una RPSI nel FCI MUST.
6.3.3.1. Semantica
Standard video moderni come MPEG-4 visual version 2 [16] o H.263 version 2 [17] consentono riferimenti più vecchi della sola immagine più recente. Tipicamente si mantiene una coda FIFO di immagini di riferimento. Se il codificatore ha appreso una perdita di sincronia codificatore-decodificatore, può usare un'immagine di riferimento nota come corretta; essendo temporalmente più lontana, l'immagine predittiva userà più bit.
MPEG-4 e H.263 definiscono un formato binario per il « payload » di un messaggio RPSI, con informazioni come l'ID temporale dell'immagine danneggiata e la dimensione della regione. La stringa di bit è in genere piccola (qualche decina di bit), a lunghezza variabile e autonoma.
MPEG-4 e H.263 consentono anche RPSI con feedback positivo (immagini o slice decodificati senza errore). Qualsiasi feedback positivo MUST NOT essere usato in sessione multipoint.
6.3.3.2. Formato
Figura 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 bit — Bit inutilizzati per allineare la lunghezza del messaggio RPSI a multipli di 32 bit.
0: 1 bit — MUST essere zero in trasmissione, ignorato in ricezione.
Payload Type: 7 bit — Tipo di payload RTP nel cui contesto MUST essere interpretata la stringa RPSI nativa.
Native RPSI bit string: variabile — Informazione RPSI definita dal codec video.
Padding: #PB bit — Bit a zero fino al confine a 32 bit; PB MUST indicare il numero.
6.3.3.3. Regole di temporizzazione
Ancora più critica della SLI: una RPSI vecchia costa più bit per risincronizzare. Vedi [15]. Inviare il prima possibile (sezione 3).
6.4. Messaggi di feedback a livello applicazione
PT=PSFB, FMT=15. Caso speciale di messaggio specifico del payload. Esattamente un FB applicativo nel FCI MUST, salvo se la struttura del messaggio consente l'impilamento (dimensione fissa o indicatore di lunghezza).
Trasportano dati definiti dall'applicazione dal ricevitore al mittente. I dati non sono identificati dal FB; l'applicazione MUST poter identificare il payload (es. NEWPRED in MPEG-4 [16] in pacchetti RTP RFC 3016 [23], FB in H.263/Annex N,U [17] RFC 2429 [14]). Il messaggio applicativo si mette nel FCI e si imposta length.
Application Message (FCI): variabile — Formato dipendente dall'applicazione. Se i dati non sono allineati a 32 bit, MUST aggiungere padding; l'identificazione del padding è a carico dell'applicazione e non è definita qui.
La specifica del FB applicativo MUST definire se il messaggio va interpretato nel contesto di un codec (tipo di payload RTP); se serve il riferimento al tipo, MUST definire come comunicare il tipo di payload come parte del messaggio FB applicativo stesso.