1. Introduction (Introduzione)

Questo memo specifica una specifica di payload RTP per lo standard di codifica video noto come raccomandazione H.264 dell'ITU-T [1] e standard internazionale ISO/IEC 14496-10 [2] (entrambi noti anche come Advanced Video Coding (AVC)). In questo memo, il nome H.264 è utilizzato per il codec e lo standard, ma questo memo è ugualmente applicabile alla controparte ISO/IEC dello standard di codifica.

Questo memo rende obsoleto l'RFC 3984. Le modifiche rispetto all'RFC 3984 sono riassunte nella sezione 14. I problemi di compatibilità all'indietro con l'RFC 3984 sono discussi nella sezione 15.

1.1. The H.264 Codec (Il codec H.264)

Il codec video H.264 ha un campo di applicazione molto ampio che copre tutte le forme di video digitale compresso, dalle applicazioni di streaming Internet a basso bitrate alle applicazioni di trasmissione HDTV e Cinema Digitale con codifica quasi senza perdita. Rispetto allo stato attuale della tecnologia, le prestazioni complessive dell'H.264 sono tali da riportare risparmi di bitrate del 50% o più. La qualità della TV satellitare digitale, ad esempio, è stata riportata come raggiungibile a 1,5 Mbit/s, rispetto all'attuale punto operativo del video MPEG 2 di circa 3,5 Mbit/s [10].

La specifica del codec [1] stessa distingue concettualmente tra un Video Coding Layer (VCL) e un Network Abstraction Layer (NAL). Il VCL contiene la funzionalità di elaborazione del segnale del codec; meccanismi come trasformazione, quantizzazione e predizione compensata dal movimento; e un filtro di loop. Segue il concetto generale della maggior parte dei codec video odierni, un codificatore basato su macroblocchi che utilizza la predizione inter-frame con compensazione del movimento e la codifica di trasformazione del segnale residuo. L'encoder VCL produce slice: una stringa di bit che contiene i dati dei macroblocchi di un numero intero di macroblocchi e le informazioni dell'intestazione dello slice (contenente l'indirizzo spaziale del primo macroblocco nello slice, il parametro di quantizzazione iniziale e informazioni simili). I macroblocchi negli slice sono disposti in ordine di scansione a meno che non sia specificata un'allocazione di macroblocchi diversa utilizzando la sintassi dei gruppi di slice. La predizione intra-frame viene utilizzata solo all'interno di uno slice. Maggiori informazioni sono fornite in [10].

L'encoder NAL incapsula l'output dello slice dell'encoder VCL in unità di livello di astrazione di rete (Network Abstraction Layer Units, NALUs), che sono adatte per la trasmissione su reti a pacchetti o per l'uso in ambienti multiplex orientati ai pacchetti. L'Annesso B dell'H.264 definisce un processo di incapsulamento per trasmettere tali NALUs su reti orientate al flusso di byte. Nell'ambito di questo memo, l'Annesso B non è rilevante.

Internamente, il NAL utilizza unità NAL. Un'unità NAL è costituita da un'intestazione di un byte e dalla stringa di byte del payload. L'intestazione indica il tipo di unità NAL, la presenza (potenziale) di errori di bit o violazioni di sintassi nel payload dell'unità NAL e informazioni relative all'importanza relativa dell'unità NAL per il processo di decodifica. Questa specifica di payload RTP è progettata per non essere consapevole della stringa di bit nel payload dell'unità NAL.

Una delle principali proprietà dell'H.264 è il completo disaccoppiamento del tempo di trasmissione, del tempo di decodifica e del tempo di campionamento o presentazione di slice e immagini. Il processo di decodifica specificato nell'H.264 non è consapevole del tempo, e la sintassi H.264 non trasporta informazioni come il numero di frame saltati (come è comune nella forma del riferimento temporale negli standard di compressione video precedenti). Inoltre, esistono unità NAL che influenzano molte immagini e che sono, quindi, intrinsecamente senza tempo. Per questo motivo, la gestione del timestamp RTP richiede alcune considerazioni speciali per le unità NAL per le quali il tempo di campionamento o presentazione non è definito o, al momento della trasmissione, è sconosciuto.

1.2. Parameter Set Concept (Concetto di set di parametri)

Un concetto di progettazione molto fondamentale dell'H.264 è generare pacchetti autonomi, per rendere non necessari meccanismi come la duplicazione dell'intestazione dell'RFC 4629 [11] o il codice di estensione dell'intestazione (Header Extension Code, HEC) di MPEG-4 Visual [12]. Questo è stato ottenuto disaccoppiando le informazioni rilevanti per più di uno slice dal flusso multimediale. Queste meta-informazioni di livello superiore dovrebbero essere inviate in modo affidabile, asincrono e in anticipo dal flusso di pacchetti RTP che contiene i pacchetti di slice. (Sono disponibili anche disposizioni per l'invio di queste informazioni in-band per le applicazioni che non hanno un canale di trasporto out-of-band appropriato allo scopo.) La combinazione dei parametri di livello superiore è chiamata set di parametri. La specifica H.264 include due tipi di set di parametri: set di parametri di sequenza e set di parametri di immagine. Un set di parametri di sequenza attivo rimane invariato durante un'intera sequenza video codificata, e un set di parametri di immagine attivo rimane invariato all'interno di un'immagine codificata. Le strutture dei set di parametri di sequenza e immagine contengono informazioni come la dimensione dell'immagine, le modalità di codifica opzionali impiegate e la mappa da macroblocco a gruppo di slice.

Per poter modificare i parametri dell'immagine (come la dimensione dell'immagine) senza dover trasmettere aggiornamenti del set di parametri in modo sincrono al flusso di pacchetti di slice, l'encoder e il decoder possono mantenere un elenco di più di un set di parametri di sequenza e immagine. Ogni intestazione di slice contiene una parola di codice che indica il set di parametri di sequenza e immagine da utilizzare.

Questo meccanismo consente il disaccoppiamento della trasmissione dei set di parametri dal flusso di pacchetti e la loro trasmissione tramite mezzi esterni (ad esempio, come effetto collaterale dello scambio di capacità) o attraverso un protocollo di controllo (affidabile o non affidabile). Potrebbe anche essere possibile che non vengano mai trasmessi ma siano fissati da una specifica di progettazione dell'applicazione.

1.3. Network Abstraction Layer Unit Types (Tipi di unità del livello di astrazione di rete)

Informazioni tutorial sulla progettazione NAL possono essere trovate in [13], [14] e [15].

Tutte le unità NAL sono costituite da un singolo ottetto di tipo di unità NAL, che funge anche da intestazione del payload per questo formato di payload RTP. Segue una descrizione del payload di un'unità NAL.

La sintassi e la semantica dell'ottetto di tipo di unità NAL sono specificate in [1], ma le proprietà essenziali dell'ottetto di tipo di unità NAL sono riassunte di seguito. L'ottetto di tipo di unità NAL ha il seguente formato:

   +---------------+
   |0|1|2|3|4|5|6|7|
   +-+-+-+-+-+-+-+-+
   |F|NRI|  Type   |
   +---------------+

La semantica dei componenti dell'ottetto di tipo di unità NAL, come specificata nella specifica H.264, è descritta brevemente di seguito.

F: 1 bit forbidden_zero_bit. La specifica H.264 dichiara un valore di 1 come violazione di sintassi.

NRI: 2 bit nal_ref_idc. Un valore di 00 indica che il contenuto dell'unità NAL non è utilizzato per ricostruire immagini di riferimento per la predizione inter-frame. Tali unità NAL possono essere scartate senza rischiare l'integrità delle immagini di riferimento. Valori maggiori di 00 indicano che la decodifica dell'unità NAL è richiesta per mantenere l'integrità delle immagini di riferimento.

Type: 5 bit nal_unit_type. Questo componente specifica il tipo di payload dell'unità NAL come definito nella Tabella 7-1 di [1] e successivamente in questo memo. Per un riferimento di tutti i tipi di unità NAL attualmente definiti e la loro semantica, si prega di fare riferimento alla Sezione 7.4.1 in [1].

Questo memo introduce nuovi tipi di unità NAL, che sono presentati nella Sezione 5.2. I tipi di unità NAL definiti in questo memo sono contrassegnati come non specificati in [1]. Inoltre, questa specifica estende la semantica di F e NRI come descritto nella Sezione 5.3.