4. Applicazione al Recupero dell'Ordine di Decodifica nei Codec a Strati
I pacchetti nei flussi RTP sono spesso codificati in modo predittivo, e il ricevitore deve disporre i pacchetti in un ordine particolare prima di poter decodificare i dati multimediali. A seconda del formato del payload, l'ordine di decodifica potrebbe essere specificato esplicitamente come campo nell'intestazione del payload RTP, oppure il ricevitore potrebbe decodificare i pacchetti in ordine in base ai loro timestamp RTP. Se viene utilizzata una codifica a strati, in cui i dati multimediali sono suddivisi tra diversi flussi RTP, è spesso necessario sincronizzare esattamente i flussi RTP che compongono i diversi strati prima che strati diversi da quello di base possano essere decodificati. Esempi di tali codifiche a strati sono H.264 SVC in modalità NI-T [AVT-RTP-SVC] e audio multicanale MPEG surround [RFC5691]. Come descritto nella Sezione 2, tale sincronizzazione è possibile in RTP, ma può essere difficile da eseguire rapidamente. Di seguito, descriviamo come le estensioni definite nella Sezione 3.3 possono essere utilizzate per sincronizzare i flussi a strati e fornire un ordine di decodifica comune basato sul timestamp.
4.1. Sincronizzazione In-Band per il Recupero dell'Ordine di Decodifica
Quando viene utilizzato un codec a strati, a descrizioni multiple o multi-view, con i diversi componenti del media trasferiti su flussi RTP separati, il mittente RTP DOVREBBE utilizzare la consegna in-band sincrona periodica dei metadati di sincronizzazione per consentire ai ricevitori di sincronizzare rapidamente e accuratamente i componenti separati del flusso multimediale a strati. Ci sono tre aspetti in questo:
-
Il mittente deve negoziare l'uso delle estensioni dell'intestazione RTP descritte nella Sezione 3.3 e deve inserire periodicamente e in modo sincrono tali estensioni dell'intestazione in tutti i flussi RTP che formano i componenti separati del flusso a strati, a descrizioni multiple o multi-view.
-
L'inserimento sincrono richiede che il mittente inserisca queste estensioni dell'intestazione RTP nei pacchetti corrispondenti esattamente allo stesso istante di campionamento in tutti i flussi. Poiché le estensioni dell'intestazione per ogni flusso sono inserite esattamente nello stesso istante di campionamento, avranno timestamp in formato NTP identici, consentendo quindi ai ricevitori di allineare esattamente i timestamp RTP per i flussi componenti. Ciò potrebbe richiedere l'inserimento di pacchetti di dati extra in alcuni dei flussi RTP componenti, se alcuni flussi componenti contengono pacchetti per istanti di campionamento che non esistono in altri flussi (ad esempio, un codec video a strati, dove gli strati hanno frame rate differenti).
-
La frequenza con cui il mittente inserisce le estensioni dell'intestazione corrisponderà direttamente alla latenza di sincronizzazione, con inserimenti più frequenti che portano a overhead per flusso più elevati, ma latenza di sincronizzazione inferiore. Si RACCOMANDA che il mittente inserisca le estensioni dell'intestazione in modo sincrono in tutti i flussi RTP componenti almeno una volta per punto di accesso casuale del media, ma POSSONO essere inserite più spesso.
Il mittente DEVE continuare a inviare report RTCP periodici inclusi i pacchetti SR, e DEVE garantire che la mappatura del timestamp RTP al timestamp in formato NTP nei pacchetti RTCP SR sia coerente con quella utilizzata nelle estensioni dell'intestazione RTP. I ricevitori dovrebbero utilizzare sia le informazioni contenute nei pacchetti RTCP SR sia la mappatura in-band dei timestamp RTP e in formato NTP come input per il processo di sincronizzazione, ma si RACCOMANDA che i ricevitori controllino la plausibilità delle mappature ricevute e scartino i valori anomali (outlier), per fornire robustezza contro i dati non validi (si potrebbe pensare che sia più probabile che le mappature RTCP SR non siano valide, poiché vengono inviate in tempi irregolari e soggette a sfasamento, ma la presenza di traduttori RTP difettosi potrebbe anche corrompere i timestamp nell'estensione dell'intestazione RTP; i ricevitori devono gestire entrambi i tipi di guasto).
4.2. Recupero dell'Ordine di Decodifica Basato sul Timestamp
Una volta che un ricevitore ha sincronizzato le componenti di un flusso a strati, a descrizioni multiple o multi-view utilizzando le estensioni dell'intestazione RTP come descritto nella Sezione 4.1, può quindi derivare un ordine di decodifica basato sui timestamp sincronizzati come segue (oppure può utilizzare le informazioni nell'intestazione del payload RTP per derivare l'ordine di decodifica, se presenti e desiderate).
Possono esserci dipendenze esplicite tra i flussi componenti di un flusso a strati, a descrizioni multiple o multi-view. Per esempio, è comune che i flussi a strati siano disposti in una gerarchia, dove i flussi dagli strati "superiori" non possono essere decodificati finché i dati corrispondenti nei flussi degli strati "inferiori" non sono stati ricevuti e decodificati. Se esiste una tale gerarchia di decodifica, DEVE essere segnalata fuori banda, per esempio utilizzando [RFC5583] quando viene utilizzata la segnalazione SDP.
Ogni flusso RTP componente DEVE contenere pacchetti corrispondenti a tutti gli istanti di campionamento dei flussi RTP da cui dipende. Se tali pacchetti non sono naturalmente presenti nel flusso RTP, il mittente DEVE generare pacchetti aggiuntivi come necessario per soddisfare questa regola. Il formato di questi pacchetti dipende dal formato del payload utilizzato. Per H.264 SVC, dovrebbe essere utilizzato il pacchetto di unità Empty Network Abstraction Layer (NAL) [AVT-RTP-SVC]. I flussi possono anche includere pacchetti corrispondenti a istanti di campionamento aggiuntivi che non sono presenti nei flussi da cui dipendono.
Il ricevitore dovrebbe decodificare i pacchetti in tutti i flussi RTP componenti come segue:
-
Per ogni pacchetto RTP in ogni flusso, utilizzare la mappatura contenuta nelle estensioni dell'intestazione RTP e nei pacchetti RTCP SR per derivare il timestamp in formato NTP corrispondente al suo timestamp RTP.
-
Raggruppare insieme i pacchetti di dati RTP da tutti i flussi componenti che hanno timestamp in formato NTP calcolati identici.
-
Elaborando i gruppi in ordine di timestamp in formato NTP crescenti, decodificare i pacchetti RTP in ogni gruppo secondo la gerarchia di decodifica del flusso RTP segnalata. Cioè, passare prima al decodificatore i dati del pacchetto RTP dal flusso da cui dipendono tutti gli altri flussi, poi quelli dal flusso dipendente successivo, e così via. L'ordine di decodifica della gerarchia del flusso RTP può essere indicato dai meccanismi definiti in [RFC5583] o con altri mezzi.
Si noti che l'ordine di decodifica non corrisponderà necessariamente all'ordine di trasmissione dei pacchetti. Il ricevitore dovrà bufferizzare i pacchetti per un lasso di tempo dipendente dal codec affinché arrivino tutti i pacchetti necessari per consentire la decodifica.
4.3. Esempio
L'esempio mostrato nella Figura 7 si riferisce a tre flussi RTP A, B e C, contenenti un flusso multimediale a strati, multi-view o a descrizioni multiple. Nell'esempio, la segnalazione di dipendenza come definita in [RFC5583] indica che il flusso A è il flusso RTP di livello più basso. Il flusso B è il flusso RTP di livello immediatamente superiore e dipende da A. Il flusso C è il più alto dei tre flussi RTP e dipende sia da A che da B. Viene utilizzata una struttura di codifica multimediale che si traduce in unità di accesso video (ovvero frame video codificati) presenti nei flussi superiori ma non presenti in tutti i flussi inferiori. Il flusso A ha il frame rate più basso. I flussi B e C hanno lo stesso frame rate, che è superiore a quello del flusso A. La figura mostra le unità di accesso video complete con i corrispondenti timestamp RTP "(x)". Le unità di accesso video sono già riordinate secondo l'ordine del numero di sequenza RTP. La figura indica la parte dell'unità di accesso video ricevuta nell'ordine di decodifica all'interno di ogni flusso RTP, così come i timestamp multimediali NTP associati ("TS[..]"). Come mostrato nella figura, questi timestamp possono essere derivati utilizzando il timestamp in formato NTP fornito nei report del mittente RTCP come indicato dal timestamp in "{x}", oppure derivati direttamente dal timestamp NTP contenuto nelle estensioni dell'intestazione RTP come indicato dal timestamp in "
Il processo di recupero dell'ordine di decodifica avanza prima verso le parti dell'unità di accesso video associate al primo inserimento sincrono disponibile del timestamp NTP nelle estensioni dell'intestazione RTP al timestamp multimediale NTP TS=[8]. Il ricevitore inizia nel flusso RTP C più alto e rimuove/ignora tutte le precedenti parti dell'unità di accesso video (nell'ordine di decodifica) fino alle parti dell'unità di accesso video con TS=[8] in ciascuno dei buffer di de-jittering dei flussi RTP A, B e C. Quindi, partendo dal flusso C, viene selezionato il primo timestamp multimediale disponibile nell'ordine di decodifica (TS=[8]), e le parti dell'unità di accesso video a partire dal flusso RTP A, e dai flussi B e C vengono posizionate nell'ordine della dipendenza del flusso RTP come indicato dai meccanismi definiti in [RFC5583] (nell'esempio per TS[8]: prima il flusso B e poi il flusso C nell'unità di accesso video AU(TS[8]) associata al timestamp multimediale NTP TS=[8]). Quindi viene elaborato il successivo timestamp multimediale TS=[6] (timestamp RTP=(4)) nell'ordine di comparsa nel flusso RTP C più alto, e il processo sopra descritto viene ripetuto. Si noti che potrebbero esserci unità di accesso video senza parti di unità di accesso video presenti, ad esempio, nel flusso RTP A più basso (vedere, ad esempio, TS=[5]). Il processo di recupero dell'ordine di decodifica potrebbe anche essere avviato dopo che è stato ricevuto un report del mittente RTCP contenente la mappatura tra il timestamp RTP e il timestamp in formato NTP (indicato come timestamp "(x){y}"), assumendo che non vi sia sfasamento del clock nella sorgente utilizzata per la generazione del timestamp in formato NTP.
C:-(0)----(2)----(7)<8>--(5)----(4)----(6)-----(11)----(9){10}-
| | | | | | | |
B:-(3)----(5)---(10)<8>--(8)----(7)----(9){7}--(14)----(12)----
| | | |
A:---------------(3)<8>--(1)-------------------(7){12}-(5)-----
---------------------------------------ordine decodifica/trasmiss.->
TS:[1] [3] [8]=<8> [6] [5] [7] [12] [10]
Legenda:
A, B, C - Flussi RTP
Valori interi in "()" - unità di accesso video con il suo timestamp
RTP come indicato nel suo pacchetto RTP.
"|" - indica le parti corrispondenti della stessa
unità di accesso video AU(TS[..]) nei
flussi RTP.
Valori interi in "[]" - timestamp multimediale NTP TS, tempo di
campionamento derivato dal timestamp NTP
associato all'unità di accesso video
AU(TS[..]), composta dalle parti dell'unità
di accesso video nei flussi sopra.
Valori interi in "<>" - timestamp multimediale NTP TS come preso
direttamente dalle estensioni dell'intestazione
RTP NTP.
Valori interi in "{}" - timestamp multimediale NTP TS come fornito
nei report del mittente RTCP.
Figura 7: Esempio di un Flusso RTP a Strati