Paragrafo 2: H.261

1.1 introduzione

Le raccomandazioni H.261 sono state preparate dal Gruppo di Studio XV del CCITT, organo permanente dell'ITU, e approvate nel Dicembre del 1990, vennero poi rivedute e leggermente modificate nel 1993 quando ormai il CCITT era stato inglobato dall'ITU ed era diventato ITU-T (settore dell'ITU per la standardizzazione delle telecomunicazioni). Esse descrivono i metodi di codifica e decodifica per sequenze di immagini in movimento ai fini di trasmissioni audio/video su reti con p x 64 Kbit/s di rate (p valore intero compreso tra 1 e 30). Le specifiche H.261 includono, inoltre, uno schema di organizzazione gerarchica a strati per i dati video.

1.2 formato del sorgente

Ai fini di utilizzare un unico insieme di specifiche per nazioni che utilizzano standard televisivi diversi quali possono essere il PAL (625/50) e l' NTSC (525/60), il CCITT ha adottato come formato dell'immagine il CIF e il QCIF, l'immagine, inoltre, viene codificata in luminanza (Y) e due componenti (CB e CR), funzione dei componenti standard di crominanza RGB (red green blue).

Il formato CIF ha 352 pixel in orizzontale e 288 in verticale e il QCIF 176 e 144 in pratica metà delle righe e metà delle colonne del CIF, Q sta appunto per quarter, in entrambi i casi per ogni quattro pixel di luminanza ve ne sono due di crominanza come in figura 1.

Secondo le specifiche H.261 tutti i Codec devono saper gestire i QCIF mentre l'utilizzo dei CIF è raccomandato ma comunque opzionale. La codifica viene fatta sia sugli INTERFRAME che sugli INTRAFRAME: ci si riferisce ai primi quando si parla di immagini che dipendono da quelle precedenti, per esempio nel caso di predizione dell'errore, ci si riferisce ai secondi quando, invece, l'immagine è autonomamente decodificata e non ha nessuna relazione con quelle precedenti. Per riassumere si può affermare che l'intraframe può essere decodificata senza bisogno di informazioni esterne, l'interframe invece contiene solo informazioni sulle differenze dell'immagine rispetto alla precedente è quindi impossibile decodificarla e portarla in chiaro senza prima aver decodificato quella che la precedeva. Nel caso di intraframe vengono rimosse solamente le ridondanze spaziali, esattamente come fosse un'immagine fissa compressa in JPEG o GIF, nelle interframe vengono rimosse anche le ridondanze temporali cioè quanto quel determinato blocchetto di pixel differisce da quello nella medesima posizione nell'immagine precedente.

1.3 organizzazione gerarchica dei dati video

Le immagini in formato CIF e QCIF vengono suddivise in blocchi, macroblocchi, gruppi di blocchi e immagini complete. Ogni blocco è formato da un quadrato di 8x8 pixel e ogni macroblocco (MB) è formato da quattro blocchi, quindi è un quadrato di 16 pixel di lato; quando in questo campo si parla di un certo numero di pixel, a meno che non sia specificato, si intende sempre pixel di luminanza, come si può notare dalla figura 2 per ogni quattro pixel di luminanza ve ne sono uno di CB e uno di CR quindi in realtà un macroblocco è formato da quattro blocchi di luminanza, uno di crominanza CB e uno di crominanza CR.

Ogni gruppo di blocchi (GOB, group of blocks) è formato da 3x11 macroblocchi per cui si può infine affermare che una immagine in formato CIF (352x288) è composta da 12 GOB e una QCIF (176x144) da 3 GOB.

Il trattamento di tali suddivisioni si può vedere in pratica come una suddivisione a strati non troppo dissimile dal modello ISO/OSI-RM dove ogni strato aggiunge il suo header al pacchetto dati che riceve dallo strato superiore. Come si può vedere in figura 3 ad ogni strato è associato un pacchetto dati che nello specifico contiene: per lo strato Picture un header seguito dai dati dei GOB, l'header contiene un codice di inizio immagine, alcuni bit di sincronizzazione e il formato video usato (CIF o QCIF); il pacchetto a livello GOB contiene i dati degli MB e un header che indica l'inizio gruppo di blocchi e il numero del blocco; a livello di macroblocco abbiamo un header seguito dai dati dei blocchi, l'header contiene un codice a lunghezza variabile (VLC, variable length code) che indica la posizione dell'MB all'interno del GOB, un altro VLC che indica il tipo di MB che può essere: codificato inter o intra frame, con o senza stima del vettore di moto (motion vector) e altre informazioni relative alla codifica che vedremo comunque in seguito più dettagliatamente; infine a livello di blocco non abbiamo un header bensì una codifica dei 64 coefficienti della Trasformata Discreta Coseno (DCT) seguiti da un codice a lunghezza fissa ( FLC, fixed length code) che indica la fine del blocco (EOB, end of block). Un'ultima considerazione va fatta sulla sequenza dei coefficienti, essi vengono trasmessi, e calcolati, nella classica sequenza a zig-zag (vedi figura 4) sì da aumentare il rapporto di compressione.

1.4 problematiche concernenti interframe ed intraframe

Tornando a riprendere per un attimo il concetto di intraframe e interframe va detto che tale stima viene fatta non sull'immagine intera bensì sui macroblocchi, per intendersi un'immagine completa essendo composta da diversi MB può averne alcuni codificati inter e altri codificati intra, tale decisione viene presa a livello di Codec, che ripetiamo può essere sia software che hardware, confrontando il macroblocco con il relativo dell'immagine precedente, se tale differenza è molto elevata, cioè al di sopra di una certa soglia, viene scelta una codifica intra, saltando quindi il processo di predizione dell'errore, se invece risulta essere abbastanza bassa ecco che il macroblocco viene codificato in modo inter e parte così la routine di predizione dell'errore che darà come risultato un vettore di moto per ogni MB, a questo punto la serie di vettori di moto verrà codificata e trasmessa, è palese quindi il risparmio di 'spazio' in termini di trasmissione dei dati con questo secondo metodo di codifica, va detto di contro che l'algoritmo sarà un po' più lento perché dovrà fare una serie di confronti più onerosi rispetto ai calcoli della codifica intra quindi andrà scelto un compromesso tra velocità di codifica ed efficienza della compressione, tantopiù che le specifiche H.261 in realtà non danno un valore fisso della soglia di cui sopra e lasciano all'utente o programmatore la libertà di fissarla a seconda delle esigenze e delle caratteristiche del proprio sistema di videoconferenza.

Un altro paio di grossi problemi sorgono dall'utilizzo degli inter e intraframe e sono: l' 'impossibilità' di far girare la sequenza all'indietro e la ricostruzione dell'immagine se un pacchetto perduto sulla rete conteneva proprio un'intraframe (si ricordi che, per aumentare la velocità di trasmissione, utilizziamo un protocollo non orientato alla connessione). Per il primo caso, che esce un po' dai binari della videoconferenza e abbraccia il campo dei montaggi video in digitale, basti pensare ad un qualsiasi operatore video che ricerca una certa sequenza mandando indietro il nastro, che nel nostro caso nastro non è bensì informazioni su disco fisso o in memoria centrale: se il ventesimo frame, ad esempio, dipende dal diciannovesimo e può essere ricostruito solo da quello, non sarà possibile vederlo se ci si arriva dal ventunesimo, appunto procedendo all'indietro. Il secondo problema nasce dalla non troppo remota possibilità di perdere sulla rete un pacchetto dati, o dal caso questo arrivi ma sia errato, ecco che anche in questo caso la ricostruzione delle immagini seguenti quel pacchetto sarebbe impossibile almeno senza qualche accorgimento.

Per entrambi i problemi, comunque, si può trovare una soluzione parlando del concetto di refresh rate che starebbe ad indicare ogni quanti interframe ci deve per forza essere un'intraframe, indipendentemente dal criterio della 'soglia' di cui prima parlavamo. In questa maniera è possibile mandare all'indietro la sequenza video che tornerà al primo intraframe precedente il fotogramma che vogliamo visionare e andrà avanti ricostruendo immagine per immagine, chi mai avesse avuto esperienza di montaggio digitale si sarà reso conto di quanto costa in termini di tempo andare all'indietro fotogramma per fotogramma. Anche per il caso di pacchetti perduti o errati l'utilizzo di questi intraframe indice permette la ricostruzione della sequenza a partire dall'intraframe successivo il pacchetto perduto o errato. Così come per la soglia, le specifiche H.261 non indicano un preciso refresh rate ma semplicemente un tetto massimo oltre il quale conviene codificare un macroblocco in modo intra, questo valore è 132 e sta ad indicare che al massimo un MB deve essere rinfrescato con una codifica intra ogni 132 volte che viene trasmesso. In realtà questo valore è anche troppo elevato tantopiù che sistemi di videoconferenza quali l' IVS rinfrescano il MB ogni 30 consecutivi MB inter.


Torna in cima

1.5 Algoritmo di rivelazione del movimento

Una volta che è stata scelta una codifica inter, parte un algoritmo che confronta i pixel di luminanza del macroblocco dell'immagine corrente con il MB nella medesima posizione riferito però all'immagine precedente, viene così calcolato un SAD (sum of absolute differences), tale confronto, e calcolo del SAD, viene fatto anche sui MB 'vicini' a quello della posizione originale, sempre dell'immagine precedente, con granularità 1 pixel (Integer Pixel Motion Estimation) e fino ad allontanarsi di 15 pixel (figura 5) sia orizzontalmente che verticalmente. Tra tutti i SAD così calcolati viene preso quello di valore più basso e viene calcolato il vettore di moto (MV, motion vector), che sarà poi quantizzato. Tale procedimento viene ripetuto per ogni macroblocco dell'immagine: in pratica un frame codificato inter non sarà altro che una serie di vettori di moto tramite i quali sarà poi possibile, conoscendo il frame precedente, ricostruire il frame corrente. Per riassumere un'ultima volta il concetto, è come se io cercassi nel frame diciannovesimo un MB del frame ventesimo, o almeno uno che gli assomiglia parecchio, e per trovarlo cercassi nelle vicinanze di dove era prima: si pensi ad un braccio che saluta, la porzione di frame che conteneva la mano, nel frame successivo, sarà di sicuro lì vicino, ecco, una volta trovata la nuova posizione io trasmetto soltanto un vettore a due dimensioni che mi indica di quanto si è spostata orizzontalmente e verticalmente. Tale metodo mi permette di trasmettere soltanto la quantizzazione di una serie di vettori bidimensionali, invece che dei campioni di una immagine intera, con notevole miglioramento della compressione.

Alla luce delle caratteristiche e delle definizioni fino ad ora descritte, diamo di seguito una trascrizione delle raccomandazioni H.261 così come le presenta ufficialmente l' ITU-T, mantenendo, tra l'altro, gli stessi numeri dei capitoli del documento ufficiale per una più facile comprensione e comparazione dell'originale con la nostra relazione, si fa notare che le specifiche vere e proprie cominciano dal capitolo 2 poiché il capitolo 1, sia nella versione ufficiale che nella nostra relazione, contiene un'introduzione allo standard.

2 brief specification:

• Per coprire standard televisivi a 625 e 525 linee con un'unica raccomandazione sono stati adottati i formati CIF e QCIF.
• L'encoder deve generare in uscita un bit stream fisso a p x 64 Kbit/s, secondo le specifiche H.221 previste dall'H.320. Il video decoder deve saper gestire il processo inverso.
• Le immagini devono essere campionate con un multiplo intero del video line rate.
• L'algoritmo di codifica del sorgente deve prevedere la rimozione di ridondanza temporale e spaziale, deve utilizzare inoltre la quantizzazione con trasformata.
• Le informazioni trasmesse contengono un codice per la correzione dell'errore BCH. L'uso di tale codice è opzionale per il decoder.
• Il codec deve poter essere utilizzato per comunicazioni uni e bi-direzionali.
• Le presenti raccomandazioni sono relative a reti di banda compresa tra 40 Kbit/s e 2 Mb/s.
• Il codec deve rispettare lo schema di figura 6

3 source coder

• La codifica del sorgente opera con immagini non interlacciate a 29.97 frame al secondo con tolleranza di 50 ppm.
• L'immagine deve essere codificata come luminanza Y e due componenti del colore CB e CR.
• Nel formato CIF la struttura della luminanza deve essere di 352x288 pixel, la crominanza 176x144 pixel. Nel formato QCIF, rispettivamente 176x144 e 88x72 pixel.
• Il numero di pixel per linea è compatibile col campionamento delle porzioni attive dei segnali di luminanza e di crominanza per i formati a 525 e 625 linee. (N.d.R.: 6.75 MHz e 3.375 Mhz)
• Il source coder è descritto in figura 7, i principali elementi sono: blocco di predizione (P), di trasformazione (T), di quantizzazione (Q).

• Le immagini devono essere suddivise in blocchi di 8x8 pixel: 4 blocchi di Y, 1 blocco di CB e 1 blocco di CR formano un macroblocco. La posizione dei blocchi all'interno del macroblocco è indicata in figura 8. Tale suddivisione vale sia per gli interframe che per gli intraframe. (N.d.R.: si noti che le specifiche non spiegano la differenza tra inter e intraframe)
• Le presenti raccomandazioni non indicano criteri di scelta sui modi di trasmissione di un blocco, indicano semplicemente che, una volta deciso di trasmettere un blocco, esso deve venire trasformato con DCT e i coefficienti risultanti devono poi venire quantizzati.
• La predizione viene fatta solo sugli interframe e si divide in compensazione del moto e loop filter.
• La compensazione del moto viene calcolata su ogni macroblocco (16x16 di Y) e dà come risultato un vettore (motion vector) a due dimensioni (orizzontale e verticale). Sia la componente verticale che quella orizzontale è formata da numeri interi compresi tra +15 e -15, un numero positivo intende uno spostamento verso il basso per la componente verticale e verso destra per quella orizzontale.
• Il loop filter è un filtro passabasso che viene applicato al macroblocco per tagliare i picchi di alta frequenza. (Nd.R.: le componenti in alta frequenza vengono tagliate per ottimizzare il rapporto di compressione non trasmettendo i coefficienti della DCT relativi a frequenze elevate grazie anche al fatto che l'occhio umano è meno sensibile alle alte frequenze, la figura 9 mostra l'andamento della sensibilità dell'occhio umano al variare della frquenza sia per luminanza che per crominanza)
• I blocchi trasmessi vengono processati da una DCT a due dimensioni. Tale trasformata si adatta molto bene al caso delle immagini, per l'efficienza della compressione ottenibile, per la mancanza di componenti immaginarie nello spettro ottenuto e per la simmetria dello spettro attorno all'origine. La DCT opera sui blocchi 8x8 e un grosso vantaggio consiste nel fatto che, per tale blocco, l'energia è concentrata alle frequenze più basse. Tale particolarità permette in fase di quantizzazione di utilizzare un passo più largo per le frequenze più elevate essendo l'occhio umano meno sensibile in questa parte di spettro. E' evidente il notevole aumento della compressione dei dati. In decodifica si utilizza la trasformata inversa IDCT, per passare dai valori quantizzati delle frequenze spaziali ai valori spaziali dei pixel.

• Il medesimo macroblocco non deve essere trasmesso per più di 132 volte consecutive in modo inter.

Torna in cima

4 Video Multiplexer Decoder

• La struttura gerarchica dei dati è composta da quattro strati (figura 3): strato dell'immagine completa (Picture Layer), strato dei gruppi di blocchi (GOB Layer), strato dei macroblocchi (MB Layer), strato dei blocchi (B Layer).
• Lo strato picture è formato da un header seguito dai dati dei GOB. La struttura dell'header, figura 10, contiene:

  - 20 bit per il codice di inizio immagine (PSC, picture start code), fisso per ogni frame.

  - 5 bit di riferimento temporale (TR, temporal reference), per gestire la sincronizzazione della sequenza in presenza di immagini non trasmesse.

  - 6 bit per il tipo del sorgente (PTYPE, picture type) che contengono informazioni sull'immagine completa, come CIF o QCIF.

  - 1 bit per l'inserimento di informazioni extra (PEI, picture extra information) che indica se è presente il campo informativo successivo PSPARE a 8 bit. In fase di decodifica le informazioni contenute nel PSPARE vengono, quindi, lette a seconda del valore del PEI. Ogni PSPARE, a sua volta è seguito da un altro bit di PEI che indica se esiste un secondo campo PSPARE e così via.
  

• Lo strato dei gob è formato da un header seguito dai dati dei macroblocchi, MB. La struttura dell'header, figura 11, contiene:

- 16 bit di inizio GOB (GBSC, group of block start code)

- 4 bit indicanti la posizione del GOB all'interno dell'immagine, figura 12.

- 5 bit che indicano il passo del quantizzatore (GQUANT) riferito al gruppo di blocchi. In fase di decodifica viene utilizzato tale valore, a meno che non ne sia indicato un altro nell'header del macroblocco (MQUANT).

- 1 bit GEI ed eventuali campi GSPARE analoghi a quelli dello strato picture.

• Lo strato dei MB è formato da un header seguito dai dati dei blocchi. La struttura dell'header, figura 13, contiene:

  - Un codice a lunghezza variabile (MBA, macroblock address) contenente l'indirizzo del macroblocco all'interno del GOB. Il primo macroblocco di ogni GOB ha un MBA che contiene un indirizzo assoluto, mentre gli MBA dei successivi macroblocchi hanno un indirizzo relativo.

  - Un codice (MTYPE, macroblock type) che indica se il MB è codificato in modo inter o intra e se sono presenti gli ultimi tre campi MQUANT, MVD, CBP.

  - 5 bit che indicano il passo di quantizzazione del MB (MQUANT), tale codice è presente solo se indicato da MTYPE e in questo caso comanda sul GQUANT.

  - Un codice a lunghezza variabile (MVD, motion vector data) che contiene la componente orizzontale e verticale della differenza del vettore di moto del corrente MB rispetto al MB precedente. Tramite tale differenza e il vettore di moto del MB precedente è possibile calcolare il vettore di moto del macroblocco corrente.

  - Un codice a lunghezza variabile (CBP, coded block pattern) che indica quali blocchi del macroblocco hanno almeno un coefficiente della DCT diverso da zero.

• Lo strato dei blocchi contiene i 64 (8x8) coefficienti della DCT (TCOEFF, transform coefficients) seguiti da un codice di fine blocco (EOB, end of block) come in figura 14. I coefficienti vengono trasmessi con la già nota sequenza a zig-zag vista in figura 3.

5 Transmission coder

• Bit rate: il clock di trasmissione è provvisto esternamente, per esempio da un'interfaccia I.420
• Video data buffering: l'encoder deve controllare il proprio flusso di bit in uscita sì da seguire le specifiche dell'HRD (hypotetical reference decoder) dell'Annesso B. Quando si opera con i CIF ogni singola immagine non può essere codificata con più di 256 Kbit., per i QCIF il numero scende a 64 Kbit. In entrambi i casi il conto dei bit include i campi PSPARE, GSPARE e MBA.
• Video coding delay: per poter sincronizzare l'audio con la sequenza video, è necessario misurare il ritardo tra video encoder e video decoder. Esso deve venir calcolato secondo le specifiche dell'Annesso C.
• Error correcting code: il flusso di bit trasmesso deve contenere un codice di correzione dell'errore BCH (511,493). L'utilizzo di tale metodo è comunque opzionale.
• Error correction framing: per permettere al decoder di identificare univocamente le informazioni sull'errore di parità e non scambiarle con i dati video, tali informazioni devono essere precedute da un preciso pattern univocamente identificabile.

A questo punto le raccomandazioni H.261 presentano tre appendici: Annesso A, B e C.

Il primo Annesso indica specifiche strettamente riguardanti l'antitrasformata da eseguire in fase di ricostruzione dell'immagine; l'Annesso B indica le specifiche di un ipotetico decoder (HRD) che segua le raccomandazioni H.261; l'Annesso C indica il metodo da seguire per calcolare il ritardo tra video decoder e video encoder.

Come abbiamo già detto, le raccomandazioni H.261 vennero riviste in piccole parti nel 1993, tra le piccole variazioni del documento c'era anche l'aggiunta di un Annesso D che indicava le specifiche da seguire per trasmettere immagini statiche con risoluzione quadrupla rispetto a quella usata, si parlava quindi di CIF se QCIF era il formato adottato e Super-CIF se il formato adottato era il CIF. (N.d.R.: si noti che per la prima volta si parla di formato Super-Cif che altro non è che un immagine formata da quattro CIF, due in orizzontale e due in verticale (704x576 pixel), tale formato è stato, tra l'altro, implementato dall'IVS Inria Videoconference System).