Cap.9

Capitolo 9
Lo standard ISO MPEG-4
9.1
Principi dello standard MPEG-4
Gli standard di codifica video MPEG-1, MPEG-2 e H.26x nascono per applicazioni chiaramente definite e limitate,
quali, rispettivamente la distribuzione di televisione digitale e la videocomunicazione interpersonale. Lo standard
MPEG-4 nasce per soddisfare le esigenze di un ampio insieme di applicazioni, non tutte completamente definite al
momento della definizione dello standard.
Lo standarda MPEG-4 é stato concepito per applicazioni multimediali estremamente differenziate dal punto di
vista dei dati stessi (audio, video, immagini fisse), della natura delle sorgenti di dati (naturali o sintetiche), della
architettura di comunicazione (punto-punto, punto-multipunto, multipunto-multipunto), e delle funzionalitá richieste
(post-elaborazione avanzata, editing e manipolazione, robustezza agli errori).
L’attivitá di standardizzazione di MPEG-4, sviluppatasi fra il 1993 e il 1999, ha mirato a definire un insieme
di strumenti (tools) di codifica per un insieme di applicazioni differenziate fra di loro. Fra le principali aree di
applicazione sono state considerate particolarmente rilevanti:
• Distibuzione di dati a qualitá televisiva, con avanzata interattivitá dell’utente
• Comunicazioni multimediali per utenti mobili
• Produzione di dati multimediali con elevata flessibilitá rispetto al contenuto
• Giochi e applicazioni di intrattenimento basate su dati naturali e sintetici
• Video Streaming su Internet
Per supportare tali applicazioni, lo standard MPEG-4 offre caratteristiche riconducibili a
• Elevata efficienza di compressione (Compression Efficiency)
• Accessibilitá mediante differenti supporti, fissi o mobili, a banda larga o stretta (Universal Access)
• Interattivitá orientata al contenuto (Content-based Interactivity)
96
9.1. PRINCIPI DELLO STANDARD MPEG-4
97
Per supportare le funzionalitá sopra citate, lo standard definisce una codifica dei dati multimediali, e in particolare
della sequenza video, orientata agli oggetti. La scena da rappresentare, (composta da video e audio, di tipo naturale
o sintetico), é descritta come una composizione di oggetti con evoluzione spaziale e temporale indipendenti.
Figura 9.1: Esempio di decomposizione di contenuto multimediale in oggetti audio e video .
Un oggetto MPEG-4 puó essere di tipo video o audio, naturale o sintetico. Un oggetto video naturale puó essere
di tipo rettangolare di dimensioni arbitrarie, oppure puó avere forma arbitraria ed essere eventualente caratterizzato
da informazioni di trasparenza; puó inoltre essere caratterizzato da profonditá di colore variabile fra 4 bit e 12 bit;
puó inoltre degenerare in un’immagine fissa. Un oggetto video di tipo sintetico, che a sua volta puó contenere una o
piú porzioni estratte da video naturale, puó avere differente complessitá, ma é tipicamente di tipo animato, a partire
da video e immagini fisse sintetiche o naturali. Fra gli oggetti audio di MPEG-4 compaiono oggetti di tipo audio
tradizionale, fra cui il segnale vocale, oggetti ibridi quale segnale vocale generato a partire da un testo, o anche
oggetti sintetici per la generazione di suoni piú o meno complessi.
L’approccio ad oggetti apre la strada ad una differenziazione del trattamento degli oggetti stessi in termini di:
• strumenti di codifica (tools9.1);
• risorse allocate per la trasmissione;
• risorse allocate per la protezione;
• formati di codifica.
9.1 Nell’ambito
MPEG-4 é usuale parlare di tools piuttosto che di algoritmi di codifica, perché lo standard mira a fornire strumenti utilizzabili
in modo flessibile e riconfigurabile.
98
CAPITOLO 9. LO STANDARD ISO MPEG-4
I principali oggetti multimediali individuati in MPEG-4 e i corrispondenti profili di codifica sono
• gli oggetti video naturali (Tabella 9.1),
• gli oggetti video sintetici e ibridi (Tabella 9.2),
• gli oggetti audio naturali e sintetici(Tabella 9.3),
• gli oggetti grafici (Tabella 9.4),
• i descrittori della scena (Tabella 9.5).
Per ció che concerne la codifica di oggetti video, gli oggetti video naturali sono codificati mediante tecniche di
codifica ibrida a trasformata, opportunamente adattate alla codifica di oggetti forma arbitraria. Oltre a tali tecniche
di codifica, MPEG-4 include nei profili di codifica di oggetti video sintetici, l’animazione di volti umani descritta
mediante la caratterizzazione della locazione assoluta e dell’evoluzione temporale di opportuni punti di riferimento
(Simple Facial Animation). MPEG-4 offre inoltre la possibilitá di mappare tessiture statiche in superfici 2D e 3D per
la generazione di oggetti sintetici, e di descrivere tessiture animate. Le tessiture statiche sono codificate utilizzando
strumenti di codifica wavelet-based, analoghi a quelli definiti in JPEG 2000; a differenza di quanto previsto nel
JPEG 2000, tali tool prevedono la predizione fra elementi di differenti sottobande, risultando cosi’ piú efficienti in
compressione ma meno robusti rispetto agli errori. Le tessiture animate sono descritte mediante l’animazione di un
grigliato (mesh) a maglia triangolare, che consente l’uto di trasformazioni di tipo affine per la motocompensazione.
Infine, MPEG-4 consente la codifica indipendente di sfondi, detti sprite; per gli oggetti sprite sono abilitate operazioni
di image warping, per supportare variazioni quali zoom o panning, e cambiamenti di illuminazione.
Profilo
Funzionalitá
Simple
Efficienza di compressione, Resistenza agli errori, Oggetti video rettangolari,
Simple Scalable
Scalabilità in spazio, in tempo
Core
Oggetti di forma arbitraria, Scalabilità in tempo
Main
Oggetti interallacciati, Oggetti semitrasparenti, Sprite
N-Bit
Oggetti con dinamica da 4 a 12 bit/pixel
Tabella 9.1: Profili video naturale.
Profilo
Funzionalitá
Simple Facial Animation
Animazione di un modello di viso umano
Scalable Texture
Scalabilità in spazio di immagini fisse
Basic Animated 2D Texture
Hybrid
Scalabilità SNR, Animazione di immagini fisse basata su mesh
Video sintetico e naturale (con oggetti del profilo Core)
Tabella 9.2: Profili video sintetico o ibrido.
9.1. PRINCIPI DELLO STANDARD MPEG-4
Profilo
Funzionalitá
Speech
Coder parametrico VLB, Coder CELP narrow/wideband, Interfaccia Text-To-Speech
Synthesis
Sintesi di suoni e rumori, Interfaccia Text-To-Speech
Scalable
Scalabilità per parlato e musica
Main
Funzionalitá precedenti e algoritmi di tipo AAC e TWinVQ
Tabella 9.3: Profili audio.
Profilo
Simple 2D
Funzionalitá
posizionamento di uno o più oggetti visuali
Complete 2D
testo e grafica bidimensionale
Complete 3D
grafica avanzata, gestione di illuminazione degli oggetti
Tabella 9.4: Profili grafici.
Profilo
Funzionalitá
Audio
applicazioni con solo contenuto audio
Simple 2D
Complete 2D
Complete (VRML)
uno o più oggetti audiovisuali senza supporto di interattività
descrizione di scene 2D
insieme completo degli elementi BInary Format for Scene description(BIFS)
Tabella 9.5: Profili di descrizione della scena.
Figura 9.2: Oggetto video sintetico di tipo Simple Face rappresentato nel profilo Simple Facial Animation.
99
100
CAPITOLO 9. LO STANDARD ISO MPEG-4
9.2
La codifica video di oggetti di forma arbitraria
La figura 9.3 mostra l’architettura base di un codificatore video basato sul contenuto della scena. Gli oggetti (di tipo
naturale o sintetico 2D o 3D) sono rappresentati come entità indipendenti, individualmente accessibili nel bitstream.
Gli oggetti che costituiscono la scena sono poi ricomposti tramite informazioni dette di composizione. Ciascun
oggetto puó essere rappresentato in modo scalabile mediante diversi Layer, ovvero diversi livelli di informazione;
grazie all’approccio ad oggetti, la scalabilitá puó essere realizzata in modo differenziato per i diversi oggetti che
compongono la scena.
Figura 9.3: Il codificatore video MPEG-4.
Il codificatore dei VOP, rappresentato in Fig.9.10, è composto da due componenti, che operano parallelamente
sullo stesso VOP. Il primo componente è il codificatore della forma, che può essere binaria o a scala di grigi
per consentire la codifica di trasparenze; tale componente è opzionale ed è omesso laddove il VOP sia di forma
rettangolare e coincida con il singolo quadro. Il secondo componente è il codificatore di movimento e tessitura,
applicato al VOP di forma arbitraria. Le informazioni di forma, moto e tessitura possono essere multiplate a livello
di macroblocco (modalitá combined) oppure i dati di forma, moto e tessitura relativi ai diversi macroblocchi possono
essere raggruppati a livello di VOP e trasmessi in tre sezioni separate (modalitá separated).
9.2.1
Gli strumenti per la codifica dell’informazione di forma
Le informazioni di forma possono essere di natura binaria ( alpha plane) o a scala di grigio (grey scale alpha plane).
Nel caso binario i pixel sono rappresentati da valori di luminanza pari a 255 se sono parte dell'oggetto (pixel opachi)
e con valori di luminanza nulli se sono esterni all'oggetto (pixel trasparenti). Il supporto dell'informazione di forma
9.2. LA CODIFICA VIDEO DI OGGETTI DI FORMA ARBITRARIA
101
Figura 9.4: Il codificatore di oggetti video naturali.
dell'oggetto è un rettangolo (bounding box) che contiene l'oggetto da codificare esteso a multipli di macroblocchi di
16x16 pixels. Le informazioni di forma di tipo binario sono codificate mediante una tecnica di codifica aritmetica
detta Content-based Arithmetic Encoding, CAE; le informazioni di forma a scala di grigio sono trattate tramite moto
compensazione e DCT.
Nel caso di informazione di forma di tipo binario, i macroblocchi del bounding box sono detti binary alpha blocks,
BAB. Si distinguono tre tipi di BAB: blocchi trasparenti, esterni all'oggetto, blocchi opachi, interni all'oggetto, e
blocchi di bordo, che coprono i bordi dell'oggetto. La codifica della forma dei blocchi di bordo è basata sul contesto
e sfrutta la ridondanza spaziale e temporale dell'informazione di forma binaria da codificare. Se il BAB é codificato
in modalitá Intra, per ogni pixel viene considerato un contesto causale di 10 pixel per la predizione del valore di forma
del pixel corrente. In base al contesto, il codificatore di tipo aritmetico indicizza una tabella di codice differente;
utilizzando tale tavola, si pilota un encoder di tipo aritmetico (CAE), che seleziona un’opportuna parola di codice.
Se il BAB é codificato in modalitá Inter, ad esso é assegnato un vettore di moto, ed il residuo di predizione é ancora
calcolato utilizzando un codificatore aritmetico basato su contesto causale. Il contesto utilizza 9 pixel, di cui 4 estratti
dal quadro attuale e 5 alla locazione moto compensata nel VOP precedente. La codifica della forma può essere con
perdita, ed un’opportuna soglia (alpha threshold) indica, per ciascun BAB, il massimo numero di pixel non codificati
correttamente all'interno di un blocco di bordo.
9.2.2
Gli strumenti per la codifica di movimento e tessitura di oggetti di forma arbitraria
La codifica del singolo VOP é una codifica ibrida a trasformata basata sulla motocompensazione e sulla trasformata
DCT, opportunamente adattati per essere applicati ad oggetti di forma arbitraria.
102
CAPITOLO 9. LO STANDARD ISO MPEG-4
La stima del movimento, viene effettuata attraverso un algoritmo di ricerca basato su una misura della differenza
tra i blocchi del VOP attuale e i blocchi di quello di riferimento traslati. La ricerca viene effettuata sia sulla base
di macroblocchi 16x16 che di blocchi 8x8. Per ció che concerne il blocco attuale la funzione di costo utilizzata
nella stima di spostamento viene calcolata unicamente sui pixel interni all’oggetto, e nel VOP di riferimento si
effettua un padding esterno all’oggetto prima di operare la motocompensazione come rappresentato in Fig.9.5. La
precisione dei vettori spostamento può essere a pixel interi, al mezzo pixel e al quarto di pixel. Ciascun vettore
spostamento è trasmesso in forma differenziale rispetto ad un predittore, analogamente a quanto definito in H.263.
La motocompensazione ammette le modalità Unrestricted Motion Vector e Advanced Prediction, analoghe a quelle
definite in H.263.
I VOP INTRA e gli errori di predizione relativi ai VOP INTER sono codificati utilizzando la trasformata DCT
8x8 delle componenti di luminanza e crominanza. I macroblocchi al bordo di un VOP di forma arbitraria sono
opportunamente completati prima di operarne la DCT. Se il macroblocco é codificato INTER, i pixel esterni al VOP
sono posti a zero; se il macroblocco é codificato INTRA, si effettua un padding detto Low-Pass Extrapolation. La
LPE é effettuata in due passi, estendendo prima il valor medio dei pixel interni al VOP ai pixel esterni al VOP stesso,
e sfumando successivamente i bordi fra pixel interni ed esterni (vedi Fig.9.5).
I coefficienti DCT possono essere quantizzati utilizzando lo stesso passo di quantizzazione per tutti i coefficienti
di frequenza non nulla, analogamente a quanto avviene in H.263, ovvero quantizzando più finemente i coefficienti
di frequenza più bassa, analogamente a quanto avviene in MPEG-2; inoltre, le matrici possono essere scelte dal
codificatore e scritte nel bitstream. Non solo il coefficiente a frequenza nulla (DC), ma anche la prima riga e la
prima colonna degli altri coefficienti (AC) possono essere codificati in forma differenziale, come illustrato in Fig.9.7.
L’ordine in cui sono trasmessi i coefficienti quantizzati e predetti viene scelto fra tre diversi ordini di scansione: a
zig zag, orizzontale alternata, verticale alternata. Infine viene effettuata la codifica entropica dei coefficienti non nulli
presenti nel blocco e del numero di zeri che compaiono tra di essi utilizzando codici a lunghezza variabile (VLC),
oppure codici a lunghezza variabile reversibili (RVLC).
9.2.3
La sintassi MPEG-4 Visual
La struttura sintattica del bitstream video é la seguente:
• Visual Object Sequence, o Video Session (VS), che rappresenta la scena completa, e contiene uno start code
non emulabile di 24 bit, seguito da un byte che segnala l’inizio o la fine della sessione;
• Video Object (VO), che rappresenta l’intero oggetto in evoluzione, contiene uno start code e un identificativo
dell’oggetto;
• Video Object Layer (VOL), che convoglia le informazioni relative allo strato (di bae o di enhancement) dell’oggetto in questione; fra le informazioni a livello di VOL citiamo uno start code, il tipo di forma (rettangolare,
binaria, scala di grigio), le dimensioni in pixel nel caso di oggetto rettangolare, la precisione in bit per pixel, il
metodo di quantizzazione scelto (H.263 o MPEG-2 ), le eventuali matrici di quantizzazione INTRA e INTER,
la precisione della stima del vettore di moto (che puó arrivare al quarto di pixel), la attivazione degli strumenti
di robustezza agli errori di trasmissione, ivi compresa la possibilitá di effettuare la predizione temporale a
partire da VOP di riferimento diversi dall’ultimo decodificato;
• Group of Video Object Plane (GOV), che svolge un ruolo analogo a quello del GOP
9.2. LA CODIFICA VIDEO DI OGGETTI DI FORMA ARBITRARIA
Figura 9.5: Adattamento della notocompensazione e della trasformata per la codifica di oggetti di forma arbitraria.
Figura 9.6: Predizione dei coefficienti DCT fra blocchi adiacenti.
103
104
CAPITOLO 9. LO STANDARD ISO MPEG-4
• Video Object Plane (VOP), che sostituisce il tradizionale concetto di quadro della sequenza video; contiene
informazioni di Start Code, di tipo di VOP (I,P,B), le dimensioni del bounding boxnel caso di oggetto di forma
arbitraria, un opportuno marker di risincronizzazione, il numero di macroblocchi all’interno del VOP, il valore
del parametro di quantizzazione, e informazioni di sincronizzazione della presentazione.
• Video packet, che convoglia l’informazione di forma, un flag di abilitazione della predizione fra macroblocchi INTRA, il parametro di quantizzazione dell’immagine ed eventualmente della forma, i vettori di moto,
ed i coefficienti trasformati relativi ai macroblocchi considerati. La sintassi del pacchetto video é discussa
ulteriormente nel paragrafo dedicato agli strumenti di robustezza all’errore di MPEG-4.
Figura 9.7: Predizione dei coefficienti DCT fra blocchi adiacenti.
9.3
La codifica video in ambienti di trasporto soggetti ad errore
La distribuzione di video per servizi televisivi é stata, almeno in origine, progettata per canali caratterizzati da elevata
qualità, con specifiche di BER dell’ordine di 10−10 , 10−11 all’ingresso del decodificatore video. Con la diffusione
dei servizi video in ambienti di trasmissione maggiormente soggetti ad errori, caratterizzati da BER dell’ordine di
10−3 , 10−5, si è reso necessario dotare i sistemi di codifica e decodifica di strumenti per reagire alla degradazione
della sequenza decodificata causata dagli errori di trasmissione
9.2 Osserviamo
9.2
. Si consideri che mentre il primo tipo di servizi
che l’adozione di protocolli di ritrasmissione a livello radio comporta un aumento dei ritardi e del jitter di trasferimento; pertanto
essi non sono adottati sistematicamente, ed in ogni caso sono limitati. Ad esempio, i protocolli di ritrasmissione H.223 AL3 prevedono al massimo
una ritrasmissione per unitá dati.
9.3. LA CODIFICA VIDEO IN AMBIENTI DI TRASPORTO SOGGETTI AD ERRORE
105
citato prevedeva un errore ogni ora di trasmissione, nel secondo caso l’errore si presenta su una larga percentuale dei
quadri
9.3
.
Il bistream codificato utilizza tipicamente tavole di codice di lunghezza variabile (VLC), ed un errore anche su
un solo bit puó causare diversi tipi di effetti:
• l’errore produce una sequenza illegale ed il decoder rivela immediatamente l’errore; questa circostanza é
piuttosto rara;
• l’errore trasforma la parola di codice in un’altra parola di uguale lunghezza; il corrispondente parametro é
decodificato erroneamente e la lettura del bitstream prosegue a partire dal punto corretto; osserviamo che anche
in questo caso, a causa dell’uso intensivo di tecniche di codifica differenziale, la decodifica errata del parametro
tipicamente conduce all’interpretazione errata dei dati decodificati successivamente;
• l’errore trasforma la parola di codice in un’altra parola di lunghezza differente, e la lettura del bitstream
prosegue a partire da un punto errato; in tal caso, si dice che il decodificatore ha perso il sincronismo con il
bitstream; la lettura prosegue fintantoché il decoder incontra una sequenza di bit che corrisponde ad una parola
di codice illegale.
In considerazione di questi effetti di errori, ancorché isolati, é essenziale fornire al decodificatore dei punti di
risincronizzazione col bitstream. A fronte di un errore rivelato, il decodificatore salta i dati codificati fino al primo
punto di sincronizzazione disponibile. I dati mancanti vengono rimpiazzati mediante tecniche dette di mascheramento
dell’errore (error concealment ), che mirano alla costruzione di una sequenza decodificata in cui le aree mancanti siano
mascherate. Fra le piú comuni tecniche di mascheramento dell’errore citiamo la copia di macroblocchi dal quadro
precedente, in posizione corrispondente oppure prescelta in base a criteri di continuitá spaziale, ovvero l’interpolazione
spaziale a partire da macroblocchi adiacenti. Osserviamo che poiché la rivelazione dell’errore avviene con una certa
latenza rispetto all’occorrenza dell’errore, una volta rivelato l’errore il decodificatore puó effettuare il concealment
anche sui blocchi che precedono la rivelazione, allo scopo di evitare i fastidiosi artefatti tipici degli errori non rivelati,
dovuti alla decodifica di parole di codice errate e completamente casuali.
Tra i diversi parametri convogliati nel bitstream, é possibile stabilire una gerarchia di importanza ai fini della
qualitá visuale della sequenza ricostruita, ció che induce a progettare tecniche che proteggano i dati in modo differenziato. Inoltre, la codifica predittiva -insita nel meccanismo di motocompensazione e tipicamente sfruttata almeno
per la codifica dei vettori di moto e per i coefficienti DC- provoca la propagazione degli errori di ricostruzione anche
su aree ricostruite in base a dati correttamente decodificati; pertanto, in ambienti soggetti ad errori, l’efficienza di
compressione puó essere ridotta a favore di una codifica indipendente di diverse sezioni del video, che risulta piú
robusta in presenza di errori.
9.3.1
Le funzionalità di robustezza all’errore dello standard MPEG-4
Lo standard MPEG4 offre funzionalità di protezione e recupero di errore finalizzate alla trasmissione di audio e video
a bit-rate relativamente basso (< 64Kb/s) in ambienti soggetti a errori, come quelli delle comunicazioni mobili. Le
metodologie di recupero includono funzionalità di
9.3 Si
consideri una sequenza codificata a 48 Kb/s, 10 quadri al secondo; ogni quadro consta di circa 5000 bit, e un BER di 10−4 conduce ad
una media di un errore ogni due quadri; fortunatamente, gli errori tipicamente non sono isolati ma appaiono in burst, condizione piú favorevole
in quanto concentra la degradazione su un area spazialmente e tempoalmente piú contenuta.
106
CAPITOLO 9. LO STANDARD ISO MPEG-4
• risincronizzazione
• recupero di dati
• mascheramento dell’errore
Le funzionalità di risincronizzazione abilitano la risincronizzazione fra il decodificatore e la stringa codificata a
valle della rivelazione di uno o più errori, e si basano su un approccio a pacchetto video (video packet approach),
che rappresenta un’evoluzione dell’approccio utilizzato da H.261 e H.263. Rispetto alle metodiche previste da
questi standard, MPEG-4 consente l’inserzione nel bitstream di marker ad intervalli di lunghezza in bit prefissata,
migliorando cos´ la protezione delle informazioni relative ad aree in movimento, alle quali, a parità di estensione
spaziale, compete un maggior numero di marker di risincronizzazione di aree più lentamente variabili. I punti di
sincronizzazione nella stringa possono inoltre contenere informazioni addizionali, che ridondano la descrizione di
parametri critici per la decodifica.
A questo approccio si affianca l’approccio a intervalli di sincronizzazione definiti (fixed interval synchronization),
nel quale i marker di risincronizzazione possono apparire unicamente in alcuni intervalli autorizzati della stringa. In
questo caso errori che causino l’emulazione degli start code nella stringa ricevuta non hanno effetto, a meno che non
compaiano negli intervalli autorizzati.
Le informazioni codificate che riguardano la forma e il moto degli oggetti rappresentati nella scena (motion
information) possono essere codificate separatamente dalle informazioni che ne descrivono i dettagli spaziali (texture
information), e dotate di un proprio resynchronization marker (data partitioning). Nel caso dunque che sia danneggiata
la porzione di stringa relativa alle texture information, il funzionamento corretto dei meccanismi di sincronizzazione
consente di utilizzare metodologie di mascheramento dell’errore basate unicamente sulla motion information che sono
estremamente semplici, (ad es. sostituzione di un blocco del quadro attuale con un opportuno blocco di un quadro
precedentemente ricostruito), che forniscono però risultati qualitativamente accettabili in applicazioni a basso bit-rate
e con requisiti di basso ritardo.
La risincronizzazione fra il decodificatore e la stringa codificata consente l’identificazione della quantità di
dati persi, e della loro tipologia (informazione di moto, informazione di tessitura, etc.). Una volta ristabilita la
sincronizzazione, il parziale recupero dei dati contenuti fra i marker di sincronizzazione riconosciuti è consentito sia
da codici di correzione di errore sia da opportune tecniche di codifica. In particolare si adottano codici a lunghezza di
parola variabile decodificabili tanto a partire dal primo quanto dall’ultimo bit di codice (Reversible Variable Length
Coding, RVLC). Ciò consente, una volta identificati due resynchronization marker consecutivi, fra i quali si sia
verificato un burst di errori, di recuperare non solo i dati che seguono il primo resynchronization marker (precedendo
il burst), ma anche i dati rappresentati dai bit non danneggiati che precedono il secondo resynchronization marker.
9.4
Multiplazione e trasporto di dati MPEG-4
Il trasferimento di dati MPEG-4 puó avvenire con diverse modalitá alternative, fondamentalmente dipendenti dalle
applicazioni.
Una prima modaliá definita dallo standard prevede la presentazione dei dati da parte dell’applicazione allo
strato di trasporto tramite l’interfaccia Delivery Multimedia Integration Framework, DMIF. Lo strato di trasporto
non é specificato dallo standard. Il trasporto basato sull’interfaccia DMIF sará prevalentemente utilizzato come
9.4. MULTIPLAZIONE E TRASPORTO DI DATI MPEG-4
Figura 9.8: Struttura del pacchetto video nella modalitá Data Partitioning.
Figura 9.9: Impatto dell’uso di tavole RVLC sulla qualitá del video ricostruito.
107
108
CAPITOLO 9. LO STANDARD ISO MPEG-4
modello concettuale per lo sviluppo di applicazioni di tipo proprietario. Una seconda modalitá definita dallo standard
prevede l’uso di un formato di file multimediale estremamente flessibile, adatto tanto alla memorizzazione quanto ad
applicazioni di video streaming su rete a pacchetto. Infine, il bitstream codificato MPEG-4 puó essere direttamente
incapsulato in un flusso RTP secondo utilizzando il formato di pacchettizzazione e i criteri appositamente definiti
in ambito IETF; tale modalitá é utilizzabile in differenti applicazioni basate su IP, quali la videocomunicazione
interpersonale o il video streaming, su rete fissa o rete mobile.
9.4.1
Il formato di trasporto MPEG-4: il Delivery Multimedia Integration Framework
L’architettura funzionale di un generico terminale conforme alla specifica ISO/IEC 14496 (MPEG-4) è costituita da
tre strati:
• lo strato di Codifica (Compression Layer);
• lo strato di Sincronizzazione (Synchronization Layer);
• lo strato di Consegna (Delivery Layer).
Lo strato di codifica produce in uscita flussi dati codificati elementari (Elementary Stream, ES) secondo le sintassi
di codifica del video, dell’audio, e della descrizione della scena9.4 . Oltre ai dati codificati di tipo audiovisuale, gli
ES possono veicolare ulteriori informazioni di descrizione degli oggetti, come informazioni sui diritti d’autore o sulla
protezione del contenuto multimediale, mediante apposite strutture sintattiche (Object Descriptors). Inoltre i dati
codificati possono essere costituiti da apposite librerie definite nello standard e sviluppate in linguaggio Java, destinate
principalmente all’industria dello sviluppo software, dette MPEG-J. Le librerie MPEG-J contengono informazioni di
controllo del terminale ricevente e consentono di manipolare il contenuto della scena audio-video interagendo con il
bitstream, identificare il tipo di decoder e i profili supportati, controllare le risorse locali, interrogare le risorse di
rete; tali librerie possono essere preinstallate sul terminale MPEG-4 oppure possono essere trasferite attraverso ES
dedicati.
Gli ES sono inoltrati allo strato di sincronizzazione che associa ai flussi elementari le informazioni di temporizzazione, necessarie a sincronizzare i flussi e la descrizione gerarchica delle relazioni reciproche. Lo strato di
sincronizzazione presenta una sintassi configurabile in modo da introdurre un maggiore o minore overhead in funzione
delle applicazioni. In generale, lo strato di sincronizzazione puó aggiungere agli ES informazioni di temporizzazione e sequence numbering; fra le informazioni di temporizzazione segnaliamo la presenza, oltre ai time stamps, di
un’informazione opzionale sulla frequenza del clock di riferimento, eventualmente condiviso da piú flussi ES. Da un
punto di vista implementativo, lo strato di compressione e lo strato di sincronizzazione sono tipicamente integrati in
un’unità funzionale. I flussi elementari di pacchetti prodotti dallo strato di sincronizzazione (Synchronization Layer
Packetized Stream, SPS), sono inoltrati allo strato protocollare inferiore di consegna.
Lo Strato di Consegna é specificato nella parte dello standard denominata Digital Multimedia Integration Framework. Il DMIF definisce primitive che permangono per l’intera durata della sessione di comunicazione. In
particolare, il DMIF specifica le primitive del Piano di Controllo sia dal lato trasmissione che dal lato ricezione, e
specifica le primitive del Piano d’Utente dal lato ricezione. Esso adatta le richieste di acquisizione dati, di trasferimento dati, e piú in generale di interazione con entità remote ai servizi messi a disposizione dallo strato di trasporto
9.4 La
descrizione della scena utilizza una sintassi appositamente definita, detta Binary Format for Scene description, BIFS.
9.4. MULTIPLAZIONE E TRASPORTO DI DATI MPEG-4
109
effettivamente disponibile. In tal modo, lo strato di consegna maschera agli strati superiori la tecnologia di trasporto
utilizzata, che dipende dallo scenario applicativo (broadcasting, memorizzazione locale, comunicazioni interattive).
Il confine tra lo strato di sincronizzazione e lo strato di consegna è denominato Interfaccia Applicativa DMIF
(DMIF-Application Interface - DAI). L’interfaccia DAI fornisce primitive classiche del livello di applicazione (PLAY,
PAUSE, etc.), definendo le possibili interazioni fra le applicazioni multimediali e lo strato di consegna. Pertanto, dal
punto di vista del paradigma di comunicazione ISO/OSI, un’istanza DMIF realizza funzionalità di Strato di Sessione
e l’interfaccia DAI corrisponde a un Punto d’Accesso al Servizio di Sessione (Session Service Access Point, SSAP).
Il DMIF maschera agli utenti la tecnologia effettivamente utilizzata per il trasporto assegnando i parametri di
qualità per ciascun flusso elementare ricevuto all’interfaccia DAI e gestendo in tempo reale canali che risentono di
variazioni della QoS.
All’interno dello strato di consegna (strato DMIF) possono essere individuate due multiplazioni indicate rispettivamente con Flex-Mux (opzionale) e Trans-Mux. La multiplazione Flex-Mux riunisce i flussi elementari che richiedano
per la trasmissione gli stessi parametri di qualità di servizio, al fine di ridurre il numero delle connessioni instaurate
per la trasmissione dei dati. La multiplazione Trans-Mux, non definisce una procedura di multiplazione chiusa, ma
si limita a definire le regole per l’incapsulamento dei flussi MPEG-4 pacchettizzati nei protocolli delle differenti
infrastrutture di multiplazione disponibili. Per il trasferimento puó dunque essere utilizzata una qualunque pila di
protocolli per il trasporto, quali ad esempio (RTP)/UDP/IP, AAL2/ATM, oppure il Transport Stream di MPEG-2.
Per ciascuna pila, il trasferimento avverrá sfruttando opportunamente le funzionalità di multiplazione/demultiplazione
native, rispettivamente le porte IP, i VC dell’ATM, i PID di MPEG-2.
Unicamente per il caso di trasporto su reti interattive (reti IP e ATM9.5 ), lo standard specifica l’interfaccia fra lo
strato Trans-Mux del DMIF e la rete (DMIF Network Interface, DNI), e descrive esplicitamente la corrispondenza
fra la segnalazione DMIF e la segnalazione nativa della rete. Infine per il trasporto su reti eterogenee, lo standard
recepisce i protocolli Digital Storage Media Command & Control - User to Network (DSMCC-UN) che definiscono
una sintassi di descrittori delle risorse di rete utilizzate.
9.4.2
Il formato di memorizzazione MPEG-4: il file MP4
La memorizzazione di una presentazione MPEG-4, ovvero delle Elementary Streams che la compongono, in linea
di principio può basarsi sul bitstream codificato fin qui descritto. La definizione di un formato di file per la
memorizzazione di una scena multimediale MPEG-4 risponde all’esigenza di fornire, oltre alle informazioni contenute
nella presentazione vera e propria, informazioni specializzate per applicazioni di editing o di accesso. Ciò è stato
realizzato adattando un formato di file multimediale esistente alle esigenze di MPEG-4. Il formato di file MP4 così
progettato contiene le informazioni multimediali di una presentazione MPEG4 in un formato flessibile ed orientato
allo scambio, all’editing, e alla presentazione in ambito locale o remoto. Rispetto alla rappresentazione costituita dal
bitstream, la rappresentazione in file presenta alcune differenze significative:
• I dati multimediali veri e propri possono essere localizzati tanto nel file MP4 o essere esterni al file e referenziati
tramite URL.
• Il file contiene alcuni metadati per l’editing, il playback, e la manipolazione dei dati multimediali.
9.5 Il
protocollo ATM é un protocollo di rete a pacchetto di lunghezza fissa. E’ connection-oriented, stabilisce cioé un circuito virtuale fra
sorgente e destinatario.
110
CAPITOLO 9. LO STANDARD ISO MPEG-4
Figura 9.10: Architettura dello strato di consegna DMIF.
• Il file contiene istruzioni (hint tracks) per il trasferimento dei dati sullo strato di trasporto disponibile da parte
dell’applicazione. Tali istruzioni segnalano, ad esempio, la modalitá di pacchettizzazione suggerita nel caso di
servizi di streaming basati sul modello client-server, ovvero l’importanza dei pacchetti dati ai fini della qualitá
soggettiva della sequenza decodificata.
Il formato di file MP4 é inoltre alla base del formato .3gp utilizzato nelle comunicazioni video su radiomobile.
9.5
La comunicazione video su reti a pacchetto
La diffusione dei servizi di comunicazione e distribuzione di video su reti a pacchetto dipende da un insieme di fattori
favorevoli.
• In primo luogo, le reti a pacchetto sono diffusissime e basate su standard universalmente accettati.
• Esse offrono strumenti di multiplazione nativi molto potenti di flussi multimediali 9.6 .
• Il formato di multiplazione a pacchetto consente la gestione integrata di dati di natura differente.
• Il formato di multiplazione a pacchetto offre strumenti nativi di monitoring della comunicazione basati su
semplici riscontri a livello di pacchetto.
9.6 A
titolo esemplificativo, si osservi che una videoconferenza H.323 punto/multipunto puó realizzarsi utilizzando una trasmissione multicast a
livello IP, laddove in un sistema a commutazione di circuito la videoconferenza H.324 necessita di un’apposita entitá, il Multipoint Processor del
MCU, per realizzare la multiplazione dei flussi in modalitá punto multipunto.
9.5. LA COMUNICAZIONE VIDEO SU RETI A PACCHETTO
111
• Il formato di multiplazione a pacchetto confina gli errori trasmissivi a livello di pacchetto, semplificandone la
gestione a livello di applicazione.
Su una rete a pacchetto possono offrirsi, accanto a servizi di download, tanto servizi multimediali conversazionali
(real-time) quanto servizi di streaming. I servizi conversazionali sono caratterizzati da ritardi massimi tollerabili
dell’ordine dei 200 ms, i servizi di streaming richiedono ritardi massimi dell’ordine di qualche secondo. La pila
protocollare di gran lunga piú diffusa per il trasferimento di dati audio video su reti a pacchetto é la pila RTP/UDP/IP
che offre un protocollo end-to-end con funzionalitá di rivelazione d’errore, numerazione dei pacchetti, sincronizzazione
dei flussi, monitoraggio delle consegne.
Per il trasferimento di video su rete a pacchetto, anche i dati del livello di applicazione sono tipicamente organizzati
a pacchetto. In presenza di perdite di pacchetto, che anche su una rete fissa possono arrivare al 5-10 %, é opportuno
adottare dei criteri di impacchettamento che forzino una corrispondenza fra strutture sintattiche di livello applicativo
e pacchetti di rete. Per ció che concerne la trasmissione su RTP/UDP/IP, tali criteri sono descritti in RFC dedicate.
In linea di principio tali criteri richiedono l’incapsulamento di un quadro in un pacchetto, ovvero di una struttura
sintattica di livello immediatemente inferiore9.7 in un pacchetto, e richiedono che non si suddividano mai gli header di
livello applicativo fra piú pacchetti. Inoltre, un importante criterio di pacchettizzazione prevede l’adattamento della
dimensione del pacchetto alla Maximum Transfer Unit (MTU)9.8 del cammino sottostante (1500 byte per Ethernet,
100 byte per canali radiomobili), al fine di evitare una frammentazione operata al di fuori del controllo dell’encoder.
In generale, pertanto, la dimensione del pacchetto non dovrebbe superare la dimensione della MTU per evitare che la
perdita, a livello di rete o inferiore, di una porzione del pacchetto del livello di applicazione costringa il decodificatore
a scartare le altre porzioni, pur ricevute correttamente.
La pacchettizzazione deve rispondere ad un trade-off fra overhead introdotto9.9 e robustezza rispetto agli errori; in
generale, a pacchetti piú lunghi corrisponde un minore overhead ma una minore robustezza, e viceversa a pacchetti
piú brevi maggiore overhead e maggiore robustezza. Sul flusso video codificato, questo ha un effetto immediato: a
paritá di banda assegnata al video, al diminuire della dimensione del pacchetto deve aumentare la quantizzazione, ció
che diminuisce la qualitá della sequenza decodificata in assenza di errori di trasmissione. D’altro canto la perdita di
qualitá sperimentata nel caso di assenza di errori corrisponde ad un miglioramento di qualitá in presenza di errori, e
la scelta della dimensione del pacchetto deve essere adattata alla qualitá del trasferimento utilizzato. Il problema é
piú complesso su reti eterogenee; in tal caso é prevista la possibilitá di aggregare o frammentare pacchetti, in misura
quanto piú possibile aderente alle unitá sintattiche di livello applicativo.
A fronte di perdite di pacchetti e/o di errori di trasmissione, é possibile delineare diverse strategie per garantire
il servizio:
• Ritrasmissione (tecniche di Picture Header Repetition, Packet Duplication, ritrasmissione con diverso formato
di codifica, piggy-backing)
• Forward Error Correction, Media Independent o Media Dependent (protezione selettiva dei dati piú importanti)
• Interleaving di livello di applicazione
9.7 Nel
9.8 La
caso MPEG-4 la struttura sintattica é il Video Packet, in H.263 il GOB, in H.263+, H.263++, H.264 la Slice.
dimensione della MTU é la dimensione massima del pacchetto IP che puó essere trasferito senza essere frammentato a livello di rete. La
frammentazione del pacchetto IP prevede la replica dell’header su tutti i frammenti ed il riassemblaggio degli stessi a destinazione; se non tutti i
frammenti arrivano entro un tempo pre-assegnato misurato a partire dall’istante di arrivo del primo frammento l’intero pacchetto é scartato.
9.9 Si osservi che l’header RTP/UDP/IP é di 40 byte.
112
CAPITOLO 9. LO STANDARD ISO MPEG-4
• Congestion control: tali tecniche si basano sulla capacitá del codec di adattare la banda istantanea. Tale
adattamento, in una comunicazioneinterpersonale punto-punto puó essere realizzato adattando i parametri di
codifica utilizzati. Nell’accesso a dati precodificati e memorizzati oppure in collegamenti punto multipunto
l’adattemento puó essere reso possibile da una codifica di tipo scalabile, che consenta di utilizzare lo stesso
bitstream codificato in condizioni di congestione di banda differenti. Tale
Protocolli IETF per il controllo e la descrizione della sessione video su reti a pacchetto
Il protocollo Session Initiation Protocol (SIP, RFC 3261) sviluppato dal IETF MMUSIC Working Group é un
protocollo di livello applicativo finalizzato ad inizializzare, modificare e terminare una sessione interattiva che
coinvolga video, voce, messaggistica, etc, tra due dispositivi multimediali.
Il Real Time Streaming Protocol (RTSP, RFC 2326) è un protocollo di livello applicativo sviluppato dal IETF
MMUSIC Working Group allo scopo di controllare la consegna on-demand di flussi dati con requisiti real-time,
come ad esempio flussi audio e video. Il protocollo é stato concepito per essere utilizzato in un paradigma
client-server (web, content e proxy/caching server). Le funzionalitá variano dall’invito di un media server ad una
conferenza, all’aggiunta di media ad una sessione già esistente, alla gestione di piú content server al livelo di trasporto
(multiserver), alla negoziazione di capacitá. Il protocollo prevede metodi che devono essere obbligatoriamente
implementati (setup, teardown, play, client-to-server options), metodi raccomandati per l’implementazione ma non
obbligatori (describe, pause) e metodi opzionali (announce, get parameter, set parameter, record, server-to-client
options). Il protocollo mantiene lo stato, consentendo quindi ai server di mantenere traccia delle sessioni aperte
anche quando il flusso dati é interrotto.
La sessione multimediale puó essere descritta utilizzando il Session Description Protocol (SDP, RFC 2327) che
convoglia informazioni sui media coinvolti, sulla pila protocollare utilizzata dal piano di utente, sugli indirizzi del
trasporto, e su altri metadati. La descrizione SDP puó essere usata congiuntamente ai protocolli SIP, RTSP, Session
Announcement Protocol (SAP, 2974) o Multipurpose Internet Mail Extension (MIME, RFC 2045, 2046).
La pila protocollare di gran lunga piú usata per il piano d’utente é la pila RTP/UDP/IP.
9.5.1
Il formato RTP per il flusso binario MPEG-4 Visual
La [3] definisce la pacchettizzazione RTP del flusso binario MPEG-4 Visual. Dal momento che MPEG-4 è uno
standard di codifica video generico, adattabile cioè ad una varietà di reti caratterizzate da differenti bande e qualità di
trasporto, le regole di frammentazione sono alquanto flessibili, e mirano fondamentalmente a garantire la preservazione
delle caratteristiche di robustezza agli errori. L’header del pacchetto RTP contiene sempre un Marker bit (M),
che segnala se il pacchetto contiene o meno la fine del quadro corrente, ed il Time Stamp che indica l’istante
di campionamento del primo quadro contenuto del pacchetto, consentendo la sincronizzazione fra media differenti,
nonché fra strati base e enhancement nel caso di codifica scalabile.
La stringa MPEG-4 Visual, opportunamente frammentata viene inserita direttamente nel payload del pacchetto.
Non vengono eliminati caratteri, come succede nel caso di header H.263, né inserita informazione ridondante, dal momento che l’MPEG-4 Visual dispone già di funzionalità per il recupero di header corrotti. I criteri di frammentazione
si possono riassumere in alcune linee guida:
• ogni pacchetto RTP non dovrebbe contenere più di un VOP, a meno che il VOP sia molto piccolo;
9.5. LA COMUNICAZIONE VIDEO SU RETI A PACCHETTO
113
• ogni pacchetto RTP non dovrebbe eccedere la Maximum Transfer Unit del path;
• un header MPEG-4, di qualsiasi livello gerarchico, non può essere suddiviso in più pacchetti, e deve comparire
all’inizio del pacchetto;
• nel caso che più header siano trasportati in un pacchetto, il payload inizierà con l’header di livello gerarchico
più alto;
• un pacchetto video dovrebbe essere mandato in un unico pacchetto RTP; tuttavia, è ammessa la trasmissione di
più pacchetti video in un pacchetto RTP in quanto il pacchetto video potrebbe essere talmente corto da risultare
di lunghezza confrontabile con l’header RTP.
Bibliografia
[1] T. Ebrahimi, C. Horne, “MPEG-4 Natural Coding-An overview”, Signal Processing: Image Communication, Vol. 15, 2000, 365-385.
[2] R. Koenen, “Profiles and levels in MPEG-4 -Approach and overview”, Signal Processing: Image Communication, Vol. 15, 2000, 365-385.
[3] IETF RFC 3016: RTP Payload Format for MPEG-4 Audio/Visual Streams, Kikuchi Y. et al., November 2000.
114