Sistemi e Reti Multimediali - studio della codifica 3D

SISTEMI E RETI MULTIMEDIALI:
3D Video Coding
Tema d’anno in:

«Indagine sulla codifica del video 3D nei tre principali
formati: MV, SideBySide, Video Plus Depth»

Relatori:
Prof. Ing. L.A.Grieco
Ing. C. Ceglie

Studenti:
Donato Barone - red_barone@libero.it
Marco Suma – smumrc@gmail.com

Sommario
1. Introduzione ................................................................................................................................................... 4
2. Cos’è il Video 3D ............................................................................................................................................. 4
3. Formati video 3D ............................................................................................................................................ 5
3.1 Conventional Stereo Video ....................................................................................................................... 5
3.2 Video 2D+Mappa di profondità (Video Plus Depth) ................................................................................. 8
3.3 Mixed Resolution Stereo (MRS)..............................................................................................................11
4. Tecniche di codifica ......................................................................................................................................13
4.1 H.264/AVC ..............................................................................................................................................13
4.2 Multiview Video Coding .........................................................................................................................16
4.3 MPEG-C Parte 3 ......................................................................................................................................18
5. Strumenti Utilizzati .......................................................................................................................................19
5.1 JMVC .......................................................................................................................................................19
5.2 Compilazione piattaforma Linux.............................................................................................................20
6. VIDEO 3D ......................................................................................................................................................20
7. PSNR3D .........................................................................................................................................................21
8. Descrizione del lavoro svolto ........................................................................................................................22
8.1 Encoder Configuration ............................................................................................................................23
8.2 Operazioni svolte ....................................................................................................................................23
9. Discussione dei risultati ................................................................................................................................23
9.1 Osservazioni preliminari .........................................................................................................................24
9.2 Osservazioni grafiche..............................................................................................................................25
10. Conclusioni .................................................................................................................................................27
APPENDICE A ...................................................................................................................................................30
APPENDICE B....................................................................................................................................................31
MV – Configuration File ...............................................................................................................................31
VpD – Configuration File ..............................................................................................................................32

SbS – Configuration File ...............................................................................................................................34
RIFERIMENTI ....................................................................................................................................................37

1. Introduzione
Il lavoro svolto in questo tema d’anno è stato quello di confrontare le prestazioni di codifica inerenti ai tre
formati principali di rappresentazione del video 3D: MV (Multiview Video) codificato con MVC[1], SbS
(SideBySide) codificato con H.264/AVC e VpD (Video Plus Depth) codificato anch’esso con MVC. Di seguito
mostriamo alcuni aspetti teorici riguardanti il video 3D ed i vari formati utilizzabili.

2. Cos’è il Video 3D
Per poter capire cosa significhi esattamente realizzare un video 3D è opportuno chiedersi come l’essere
umano sia in grado di percepire la tridimensionalità (stereoscopia = visione nello spazio)[6].
Il sistema visivo umano è un architettura complessa che cattura informazioni dall’esterno mediante l’uso
degli occhi (due “dispositivi di input”), ma la domanda è: com’è possibile riuscire a percepire un
informazione di profondità attraverso una membrana (rètina) dotata di una superficie bidimensionale?
Tutto ciò è ovviamente possibile, e la spiegazione è data dal fatto che il nostro cervello è in grado di
sfruttare i cosiddetti indizi pittorici (monoculari) [2] e indizi fisiologici (binoculari) [6], ricostruendo la
scena 3D a partire dalle informazioni provenienti dalle due rètine.
Sulla base di queste conoscenze, l’obiettivo è quindi quello di “ingannare” il nostro cervello cercando di
riprodurre (su schermi o proiettori adeguati) immagini ricostruibili tridimensionalmente; le fasi saranno
quindi le seguenti:
1) Acquisire flussi video da due telecamere distinte, emulando il comportamento dei nostri occhi;
2) Sfruttare gli indizi monoculari e binoculari per “ingannare” il cervello;
Riuscire a discriminare il flusso video diretto all’occhio sinistro da quello diretto all’occhio destro;
questo è possibile mediante:
a. Stereoscopia passiva [6];
i. Separazione dei canali (rosso e ciano);
ii. Polarizzazione (lineare o circolare);
b. Stereoscopia attiva (active shutter – tecniche basate sulla persistenza retinica)[6];
c. Autostereoscopia (mediante la barriera di parallasse o rete lenticolare) [5][6].

3. Formati video 3D
3.1 Conventional Stereo Video
Il Conventional Stereo Video (CSV) è un formato di rappresentazione di un video 3D e si compone di due
flussi video distinti: uno per la vista sinistra e uno per la vista destra di una stessa scena. Si sfrutta il
fenomeno della stereopsi, cioè basare la rappresentazione del video 3D su ciò che fa normalmente il nostro
sistema visivo. Il nostro cervello preleva i due “flussi” video provenienti dall’occhio sinistro e destro e
successivamente fonde le due immagini. In questo modo si ottiene una visione tridimensionale e si ricavano
informazioni sulla profondità e sulla posizione dell’oggetto. Il principio che si utilizza per la CSV è appunto
quello di usare due telecamere distinte poste ad una distanza usualmente di 65 mm (distanza interpupillare
media); i due flussi rappresenteranno rispettivamente la vista sinistra e destra della scena. L’obiettivo è
stimolare il cervello a riprodurre la stereopsi [6] andando a veicolare all’occhio sinistro il flusso video
sinistro e all’occhio destro quello destro. Poi a seconda della tecnologia utilizzata i due frame saranno usati
per ottenere l’effetto 3D.
I problemi che ci si trova ad affrontare durante la fase di acquisizione non sono pochi; alcuni di questi sono:


Problemi di allineamento: le telecamere devono essere perfettamente allineate;



Problemi di sincronia: l’acquisizione dei due flussi deve essere sincronizzata;



Problemi di messa a fuoco e zoom: i parametri caratterizzanti lo zoom e la messa a fuoco devono
essere identici.

Di seguito, a titolo di esempio, in Fig.1 e Fig.2 vengono mostrati i due frame sinistro e destro di una stessa
scena.

Fig.1 : Esempio di frame di una vista.

Fig.2 : Esempio di frame di un'altra vista.

3.1.1 Top-and-Bottom e Side-by-Side
Il multiplexing dei frame di un video 3D [6][10][11] può essere suddiviso in:
 Frame compatibile;
 Frame incompatibile.
Nel primo caso i due frame relativi alle due viste vengono sottocampionati e successivamente inseriti
all’interno di un unico frame 2D. Questo approccio permette di utilizzare la stessa banda usata per l’invio di
un normale video 2D, ma porta ad una perdita di risoluzione. Nel secondo caso, invece, i frame sono lasciati
a piena risoluzione: questo porta ad un maggior spreco di banda, ma in compenso non si ha perdita di
risoluzione.
Se il multiplexing viene fatto inserendo in ogni frame le immagini delle due viste una sotto l’altra, allora si
parlerà di formato Top and Bottom.

Fig.3 : Schema Top-and-Bottom.

In Fig.3 viene mostrato il Top-and-Bottom (TaB) frame compatibile in cui i frame relativi alle due viste
subiscono il processo di undersampling verticale con fattore 2 e successivamente vengono inseriti uno sotto
l’altro all’interno del frame multiplexato che avrà dimensioni pari a quelle del frame 2D. L’altra soluzione

consiste nell’andare a prelevare le immagini a piena risoluzione e di andarle ad inserire all’interno di un
unico frame con larghezza pari a quella del frame 2D e con altezza doppia rispetto allo stesso.

Fig.4 : Frame Top-and-Bottom.

Usualmente l’immagine inserita nella parte alta del frame si riferisce alla vista sinistra. Tale tecnica viene
normalmente utilizzata con formati 720p e 1080p; nel primo caso (720p) le righe dalla 26 alla 385 saranno
utilizzate per la vista sinistra, mentre dalla 386 alla 745 per la vista destra (in totale sono 720 righe relative
all’immagine che stiamo inviando); nel secondo caso (1080p) invece l’immagine sinistra va dalla 42 alla 581
e quella destra dalla 582 alla 1121 (ossia 1080 righe). L’offset iniziale è dovuto ad un blanking verticale che
viene fatto sul frame come mostrato nella Fig.4 per un frame 720p[11].
Se il multiplexing viene fatto inserendo in ogni frame le immagini delle due viste una affianco all’altra, allora
si parlerà di formato Side-by-Side. Analogamente al Tab, anche il SbS può essere frame compatibile e in
questo caso il sottocampionamento è effettuato orizzontalmente di un fattore 2 e i due frame sono inseriti
uno di fianco all’altro all’interno di un frame di dimensione pari a quella di un frame 2D; oppure frame
incompatibile in cui vengono prese le immagini a piena risoluzione e vengono inserite all’interno di un
frame che avrà stessa altezza di quello 2D, ma larghezza doppia. I vantaggi e gli svantaggi delle due tecniche
li abbiamo già analizzati. In Fig.5 viene mostrato un esempio di multiplexing SbS frame compatibile.

Fig.5 : Schema Side-by-side.

All’interno dei frame generati sia per il primo che per il secondo formato è importante che venga
mantenuto l’allineamento. Nel TaB i pixel di una i-esima riga dell’immagine multiplexata devono ritrovare i
corrispettivi pixel relativi alla seconda vista con un shift costante di M/2 (M=altezza). Stessa cosa deve
succedere per il SbS in cui lo shift è orizzontale e non verticale ed è pari a N/2 (N=larghezza). È possibile
osservare il frame SbS nella Fig.6.

Fig.6 : Frame side-by-side.

3.2 Video 2D+Mappa di profondità (Video Plus Depth)
Uno dei formati molto spesso utilizzati per la rappresentazione di un video 3D è il video 2D+Mappa di
profondità. Tale formato consiste nell’andare ad associare ad ogni frame, prelevato dalla vista destra o

sinistra, una mappa di profondità ossia un’immagine in scala di grigi con le stesse dimensioni dell’immagine
di partenza. Quest’ultima associa ad ogni pixel un livello di grigio proporzionale alla posizione che ogni pixel
deve assumere sull’asse cartesiano Z (profondità), cioè se deve essere rappresentato dentro o fuori dal
piano dello schermo; per questo motivo tale rappresentazione viene anche chiamata 2D+Z.
Ogni pixel viene rappresentato con 8 bit e quindi il range di variabilità va da 0 a 255. Nel formato classico
più un’area è chiara, quindi più i suoi pixel sono prossimi a 255 e più questa dovrà essere percepita vicina
dall’utente; viceversa più un’area è scura e più l’utente dovrà percepirla lontana. L’unione delle due
immagini: quella 2D e la mappa di profondità, vengono usate per realizzare il video 3D. Un esempio di
un’immagine più mappa di profondità è stato riportato in Fig.7:

Fig.7 : esempio di Video2D+mappa di profondità.

Le tecniche attualmente utilizzate per realizzare la mappa di profondità sono principalmente tre:


Singola immagine 2D;



Geometria epipolare;



Time of Flight.

La tecnica basata su singola immagine 2D consiste nel partire da un normale frame bidimensionale sul
quale vengono individuati degli oggetti. Ad ogni singolo oggetto verrà associata una determinata profondità
espressa in livelli di grigio; più l’oggetto è vicino e più questo dovrà essere bianco.
Il metodo basato su geometria epipolare va ad effettuare un’analisi di uno stesso frame prelevato da due
viste differenti (sinistra e destra) e sfrutta le informazioni relative ai punti di acquisizione per poter
calcolare la profondità. La geometria epipolare non fa altro che descrivere le relazioni che intercorrono fra i

frame 2D prelevati da fotocamere con posizione e orientamento differente. Per realizzare la mappa di
profondità si parte dalle informazioni relative alla posizione delle videocamere, ipotizzando di avere una
situazione simile a quella visibile in Fig.8:

Fig.8 : prinicio di base per la geometria epipolare.

A e B in questo caso rappresentano le due videocamere e C rappresenta l’oggetto preso in considerazione.
Avendo le informazioni relative agli angoli α e β e la distanza b diventa poi semplice calcolare d che
rappresenterà la profondità all’interno della nostra immagine. La tecnica utilizzata per ottenere la mappa di
profondità sfrutta gli stessi principi.
La tecnica Time of Flight consiste nell’andare ad utilizzare telecamere ad impulsi ad infrarossi per poter
realizzare la mappa di profondità. La scena è catturata tramite queste particolari telecamere che emettono
impulsi di luce e successivamente basandosi sul ritardo con cui il fascio prodotto per un determinato pixel
ritorna sul sensore della fotocamera, si calcola la distanza che verrà associata al pixel. Il tutto quindi si basa
sulla velocità della luce c=300000 km/s e il ritardo che i fasci associati ad ogni pel producono. La distanza
sarà banalmente calcolabile come segue:

Nel formato video 2D+Mappa di profondità si hanno i seguenti vantaggi:


Bandwidth necessaria molto vicina a quella del video 2D, quindi è possibile utilizzare le
infrastrutture preesistenti per poter trasmettere siffatti contenuti;



Compatibilità con i tool di codifica per video 2D;



Elaborazioni più semplici e veloci.

La banda necessaria si avvicina molto a quella richiesta per la trasmissione di un video 2D, perché in questo
caso ci troviamo ad avere un video 2D a cui viene associata una mappa di profondità, ricordiamo che ogni
frame della mappa non è nient’altro che un’immagine in scala di grigi e questo spiega come mai ci sia così
poco overhead nella comunicazione.

Anche la complessità computazionale nella fase di codifica viene ridotta, dato che la seconda vista 2D è una
semplice sequenza di immagini in scala di grigi.
Ovviamente utilizzare il formato video+Mappa prevede anche degli svantaggi:


Alcuni display esistenti non sono compatibili con questo formato;



8 bit per rappresentare la profondità può non sempre essere sufficiente;



Non permette di gestire trasparenza o parziale occlusione degli oggetti;



Non gestisce fenomeni di riflessione e rifrazione;



Il processo di generazione delle mappe non è banale.

3.3 Mixed Resolution Stereo (MRS)
Un altro formato utilizzato per la rappresentazione di video 3D è il mixed resolution stereo [3]. Tale formato
è normalmente utilizzato per ridurre il bitrate, cercando di mantenere praticamente invariata la qualità
percepita dall’utente. Nel MRS una delle due viste viene filtrata e poi sottocampionata, mentre l’altra viene
lasciata a piena risoluzione, quindi avremo come risultato i frame della prima vista di dimensione
MxN(M=larghezza e N=altezza) e i frame della seconda vista a risoluzione più bassa pari ad esempio ad
M/2xN/2.
Ciò che si tenta di fare è sfruttare la teoria della soppressione binoculare attraverso la quale, anche se la
nitidezza e la risoluzione dei frame di una delle due viste sono inferiori rispetto a quelle dei frame dell’altra
vista, la qualità binoculare percepita è molto vicina a quella che si otterrebbe utilizzando i due video a piena
risoluzione. Lo svantaggio principale è legato all’affaticamento a cui è sottoposto il sistema visivo umano;
per ovviare a tale problematica, solitamente la vista sottocampionata viene alternata.
Le operazioni che normalmente vengono fatte su una delle due viste sono:


Filtraggio passa basso;



Sottocampionamento.

Il filtraggio passa basso viene utilizzato per eliminare tutte le componenti in alta frequenza presenti
nell’immagine. Come risultato di tale operazione si ottiene un frame identico a quello di partenza, ma meno
nitido come mostrato in Fig 9.

Fig.9 : a sinistra viene mostrata l’immagine non filtrata e a destra quella filtrata passa basso.

L’operazione successiva consiste in un undersampling, ossia un sottocampionamento per poterne
diminuire la risoluzione. A destinazione il frame verrà sovracampionato ed utilizzato per la riproduzione del
contenuto 3D.
Questo porta alla conclusione che il formato MRS permette di ottenere una qualità molto vicina a quella
che si otterrebbe utilizzando le due viste a piena risoluzione, restituendo un bitrate inferiore. Normalmente
il formato MRS viene utilizzato in applicazioni di MOBILE 3DTV, per diminuire il bitrate riuscendo comunque
a mantenere una qualità del video 3D elevata. Altro vantaggio nell’utilizzo di questo formato è relativo alla
minore complessità computazionale con cui è possibile effettuare la decodifica, il che su dispositivi dalle
capacità computazionali limitate è un elemento importantissimo.

4. Tecniche di codifica
4.1 H.264/AVC
Il protocollo H.264 nasce dalla collaborazione tra MPEG e ITU-T. H.264 mira all’obiettivo di creare una
codifica video altamente scalabile in grado di adattarsi a qualsiasi evenienza (da trasmissioni in real-time a
codifiche in alta definizione). Macroscopicamente, si basa su due tecniche di codifica:
-

CAVLC (Context-Adaptive Variable Length Coding): è una codifica che, a scapito di una minore
efficienza, richiede un minore sforzo computazionale;

-

CABAC (Context Adaptive Binary Arithmetic Coding): consente una maggiore efficienza nella
codifica, richiedendo una maggiore complessità computazionale.

H.264 definisce tre profili di codifica:
1. Baseline profile: che supporta la codifica intra- e inter- (con I-slices e P-slices) mediante una
codifica entropica di tipo CAVLC;
2. Main profile: fornisce il supporto per l’interlaced video, la codifica inter- con l’uso di B-slice e una
codifica entropica di tipo CABAC;

3. Extended profile: non utilizza CABAC, ma introduce nuovi tipi di slice (SP- e SI-slice) con l’aggiunta
di un modulo Data Partitioning per la gestione degli errori di trasmissione.
La struttura di una generica coded picture (ottenuta dalla fase di encoding del corrispondente frame) è
organizzata in macroblocks, i quali a loro volta sono raggruppati in slice (i macroblocks non sono
necessariamente contigui). Ciascuna slice può essere di tipo I, P o B e quindi conterrà solo macroblocks
rispettivamente di tipo I, P o B [12].
H.264 si basa sempre sulla codifica di tipo intra-coding e inter-coding (descritte in MPEG-1), ma aggiunge
delle ulteriori tecniche predittive: in particolare, nella intra-coding, i pixel di un determinato blocco (che
può essere di dimensioni 8x8 o 4x4, a seconda di come venga scomposto il macroblocco 16x16) possono
essere predetti dai pixel adiacenti al blocco in alto e a sinistra, sfruttando così la correlazione spaziale (vedi
Fig. 10 e Fig. 11).

Fig.10. rappresentazione dei pixel da predire in funzione dei pixel di riferimento in H.264.

Fig. 11. Le 9 possibilità di predizione (mostrate dalle frecce) di un blocco 4x4.

Nella inter-coding vengono ampliate le tecniche di codifica MPEG-1, consentendo:
-

la predizione anche da più di due frame (come invece accadeva per i frame di tipo B);

-

la scelta di blocchi di dimensione variabile (vedi Fig.12);

Fig 12. Le varie possibilità di scelta della dimensione di macroblocks e sub-macroblock.

-

l’utilizzo dei vettori di moto con risoluzione pari a ¼ di pixel per la componente di luminanza e ⅛ di
pixel per le componenti di crominanza.

In Fig.13 viene mostrata una possibile scelta della dimensione dei blocchi che ottimizzi le prestazioni di
codifica

Fig 13. Visualizzazione della scelta delle dimensioni dei blocchi ottimale.

La codifica si basa non più sull’utilizzo della trasformata DCT, bensì sulla trasformata di Hadamard, costruita
esclusivamente mediante operazioni di somma e shift.
Un ulteriore feature introdotta per migliorare la qualità del video è il filtro di de-blocking, il quale consente
di “smussare” (smoothing) i pixel dei blocchi adiacenti per annullare gli effetti di codifica a blocchi.
La struttura di un terminale di encoding H.264/AVC, è composta da:
-

un blocco VLC, il quale effettua le operazioni di codifica;

-

un blocco Data Partitioning, il quale suddivide e frammenta i pacchetti in base a un ordine di
priorità legata al contenuto degli stessi;

-

un blocco di Network Abstraction Layer, il quale si occupa di trasmettere in rete il contenuto
codificato del video (vedi Fig.14).

Fig. 14. Rappresentazione architetturale di un terminale di encoding H.264.

4.2 Multiview Video Coding
La multiview video coding (MVC) [7][10] non è nient’altro che un estensione del codec H.264/AVC; la
differenza fondamentale tra i due è che il primo è ottimizzato per la compressione di Multiview Video
(MVV), mentre il secondo è stato realizzato per la compressione di filmati 2D.
Un MVV è un formato di rappresentazione dei video 3D che non utilizza la classica stereocoppia, ma va a
sfruttare le N viste ottenute da una stessa scena. L’acquisizione viene effettuata utilizzando N videocamere
equidistanziate, quindi è possibile intuire come le immagini acquisite siano altamente correlate tra loro.
La MVC va proprio a sfruttare questa elevata correlazione e cerca di eliminare le ridondanze intervista in
modo tale da ottenere la massima compressione dei file originali. Ovviamente il codec di base per la
compressione rimane H.264/AVC: la differenza sta appunto nel considerare la correlazione intervista che
tale codec non prevede.
L’approccio di MVC è il seguente: la prima vista passata viene codificata nel modo classico sfruttando solo
le dipendenze intravista; le successive, al contrario, vengono codificate in modo tale da prendere in
considerazione le ridondanze intervista. Un esempio della matrice di picture che si viene a generare è
mostrata in Fig.15:

Fig.15 : esempio di disposizione dei frame I,P,B nelle 8 viste.

Si può osservare come solo all’interno della prima vista (prima riga) siano presenti frame di ancoraggio di
tipo I, ossia la cui codifica va a considerare solo le ridondanze intraframe. Le successive viste negli istanti
T0 e T8 presentano solo frame di tipo P o B e non frame di tipo I. Gli archi presenti nella figura ci mostrano
quali sono le dipendenze in termini di immagine di riferimento che ci sono fra i vari frame. Ad esempio nella
vista S2 il frame all’istante T0 ha come immagine di riferimento per la predizione quello della vista S0
all’istante T0, mentre il frame all’istante T0 della vista S1 utilizza come immagini di riferimento i frame
corrispondenti nella vista S0 e S2 allo stesso istante.
Le altre innovazioni portate nel MVC sono state la compensazione dell’illuminazione (Illumination
Compensation) e del moto (Motion skip) [7]. Dato che vengono utilizzate immagini prese da N viste in
molti casi si possono avere delle inconsistenze di illuminazione e di colore dovute a variazioni di
illuminazione tra lo stesso frame appartenente a viste differenti. Per questo motivo si utilizza la
compensazione dell’illuminazione che consiste nell’andare a calcolare un fattore di compensazione per ogni
singolo macroblocco che in fase di ricostruzione del video viene sommato o sottratto allo stesso. Tale
fattore di compensazione sarà presente se la compensazione dell’illuminazione è abilitata per quel
determinato macroblocco; normalmente tale coefficiente viene ottenuto tramite delle medie effettuate sul
macroblocco del frame di riferimento presente in un’altra vista. Per quanto riguarda la compensazione del
moto, come abbiamo già visto in precedenza, non ci si limita a permettere la predizione dei frame solo con
frame di riferimento appartenenti alla stessa vista, ma vengono utilizzati frame appartenenti a viste
adiacenti.
Nel nostro tema d’anno i formati video MV e VpD sono stati codificati entrambi con MVC.

4.3 MPEG-C Parte 3
Lo standard ISO/IEC 23002-3, conosciuto anche come MPEG-C Parte 3, è uno standard creato dal Motion
Picture Experts Group ottimizzato per la compressione di file 3D rappresentati nel formato Video+Mappa
di profondità.

Con la realizzazione del MPEG-C Parte 3 si è cercato di realizzare uno standard che prevedesse le seguenti
caratteristiche:
1. Interoperabilità;
2. Indipendenza dalla tecnologia degli schermi;
3. Retrocompatibilità;
4. Efficienza di compressione.
L’indipendenza dalla tecnologia degli schermi utilizzati è una caratteristica importantissima da prendere in
considerazione; infatti questo standard è in grado di funzionare (e quindi di essere utilizzato per la
riproduzione di contenuti 3D) sia da schermi autostereoscopici con barriera di parallasse, sia da schermi
autostereoscopici con rete lenticolare e sia da schermi basati su stereoscopia attiva o passiva in cui si ha
bisogno dell’ausilio di occhiali per poter visionare il contenuto 3D.
La retrocompatibilità è stata presa in considerazione in modo da sfruttare standard di codifica già
consolidati e testati per video 2D e utilizzarli per codificare un video rappresentato nel formato VpD. Inoltre
MPEG-C Parte 3 è stato realizzato in modo tale da poter consentire anche la compatibilità con eventuali
standard di codifica futuri.
In Fig.16, viene mostrata una completa catena stereoscopica che illustra le varie fasi che bisogna affrontare
dal momento in cui il video nel formato VpD viene acquisito a quando viene visualizzato.
Tale standard non si limita a definire come trattare la profondità, ma specifica un formato Dati per il Video
Ausiliario [4]. Viene associato un vettore di N-bit ad ogni pixel che rappresenta la profondità e questo
permette di poter comprimere tali informazioni con gli algoritmi attualmente presenti per la compressione
di un normale video 2D.
Aux_video_data_type è un elemento di dimensione pari ad un singolo byte utilizzato per poter descrivere il
tipo di dati immagazzinato nel video ausiliario. La potenza di tale soluzione risiede nel fatto che viene
specificata solo la semantica dell’elemento, ma non il modo in cui questo deve essere trasmesso. Due
erano i tipi di dati inizialmente previsti: Profondità o Parallasse (restituisce informazioni sulla profondità). Il
primo codificato con il valore 0x10 e il secondo con 0x11. Gli altri valori previsti sono stati riservati per usi
futuri.
MPEG-C Parte 3 può essere utilizzato anche con applicazioni a bassissimo bitrate, infatti viene data la
possibilità di sottocampionare la mappa di profondità sia nel tempo che nello spazio, in questo modo si ha
una bassa perdita di informazioni, ma si guadagna parecchio in termini di banda necessaria. A destinazione
verrà effettuato un sovracampionamento per poter permettere la visualizzazione.

Fig.16: esempio di una catena stereoscopica completa per il VpD.

5. Strumenti Utilizzati
5.1 JMVC
La fase di codifica è stata elaborata per mezzo del software JMVC 8.5(Joint Multiview Video Coding),
particolarmente adatto alla codifica MVC, ma utilizzabile anche per il SbS, il VpD (considerando la mappa di
profondità come essa stessa una vista) e per il SbS (una sola vista). A conferma di quanto detto, JMVC è
basato sulla codifica H.264/AVC: in aggiunta prevede le features opportune per codificare le varie viste.
Questo software è ottenibile accedendo ad un CVS Server mediante un CVS client installabile sulla propria
macchina specificando i parametri descritti nella Tab.1. Il software è scritto in C++ ed è disponibile per
piattaforma Windows e Linux; viene messo a disposizione sottoforma di codice sorgente e quindi
dev’essere compilato sulla propria macchina: nel nostro caso è stata utilizzata una piattaforma Linux
(distribuzione Ubuntu v12.04).
Tab.1: CVS access parameters

authentication:
host address:
path:
user name:
password:
module name:

pserver
garcon.ient.rwth-aachen.de
/cvs/jvt
jvtuser
jvt.Amd.2
jmvc

5.2 Compilazione piattaforma Linux
Utilizzando il compilatore gcc versione 4 è sufficiente, da linea di comando, posizionarsi all’interno della
cartella JMVC/H264AVCExtension/build/linux e lanciare il comado make. In questo modo verranno generati
gli eseguibili e le librerie necessarie per l’utilizzo. In particolare i file eseguibili utilizzati sono stati i seguenti:
-

bin/H264AVCDecoderLibTestStatic;

-

bin/H264AVCEncoderLibTestStatic;

-

bin/MVCBitStreamAssemblerStatic;

-

bin/PSNRStatic.

H264AVCEncoderLibTestStatic: attraverso questo tool è possibile effettuare l’encoding vero e proprio di un
video.
MVCBitStreamAssemblerStatic: i vari stream .264 ottenuti dalla codifica di ciascuna vista vengono
assemblati grazie all’utilizzo di questo tool.
H264AVCDecoderLibTestStatic: questo tool è dedicato alla fase di decodifica ed è quindi utilizzato per
poter ricostruire il flusso video .yuv simulando la fase di ricezione.
PSNRStatic: passando il file originale e il file ottenuto dalla fase di decodifica, con questo eseguibile è
possibile ottenere le informazioni circa il bitrate e il psnr per ciascuna delle tre componenti (Y, U, V).

6. VIDEO 3D
Il video utilizzato e disponibile nei tre formati è ottenibile consultando [8] e utilizzando un client FTP per
accedere ai contenuti richiesti; nel nostro caso abbiamo utilizzato quanto riportato in Fig.17:

Fig.17 Descrizione del video e frame di esempio del video codificato.

7. PSNR3D
Per poter valutare i risultati ottenuti dalla codifica e decodifica dello stesso video nei tre formati: MV, SbS e
Video+Mappa è stato realizzato un applicativo con le librerie Qt [9]. La versione utilizzata è la 4.7.4.
Il software, vedi Appendice A, permette all’utente di selezionare tramite una classica finestra di browsing,
Fig.18, i file con estensione .txt che contengono i valori di bitrate e PSNR per le tre componenti generati dal
tool messo a disposizione da JMVC. Essendo questi file .txt strutturati in maniera molto semplice, viene
effettuata una banale scansione del testo e vengono estratti i dati di nostro interesse. Dopo aver caricato i
file l’utente potrà decidere di generare i grafici associati ai dati caricati. I grafici generati dal software sono
tre in totale e permettono di mettere in relazione il PSNR della componente Y in funzione sia del Qp che del
bitrate e di analizzare il bitrate in funzione del Qp. In ogni singolo grafico sono state generate le curve
evidenziandole rispetto al formato.
Le motivazioni alla base della creazione di questo applicativo sono le seguenti:


Automatizzare il processo di reperimento dei dati dai vari file risultanti dal calcolo del PSNR
attraverso il tool messo a disposizione da JMVM;



Rendere il caricamento dei dati UserFriendly grazie all’utilizzo di un’interfaccia grafica;



Generare e confrontare tutti i grafici di nostro interesse all’interno di un’unica schermata, così da
rendere più semplice la loro analisi;



Riuso, nel caso si volesse effettuare la stessa elaborazione associata ad un video differente
potrebbe essere fatta in pochi semplici click;



Acquisire i dati direttamente dai file eliminando possibili errori di trascrizione.

Ovviamente si poteva optare anche per la via più semplice e cioè utilizzare banalmente Excel, ma per i
motivi suddetti e per poter approfondire la conoscenza delle librerie Qt è stata scelta questa strada.
Il software si presenta con una semplice interfaccia grafica tramite la quale è possibile caricare i file con
all’interno i valori di PSNR per i tre formati. Dopo aver terminato il caricamento l’utilizzatore potrà generare
i grafici cliccando sull’icona apposita. La GUI di partenza è mostrata in Fig.19.

Fig.18 Finestra di browsing utilizzata per selezionare i file .txt

Fig.19 : GUI del PSNR3D.

8. Descrizione del lavoro svolto
Per analizzare in dettaglio le varie prestazioni ottenute dai tre formati video 3D, abbiamo opportunamente
configurato il file .cfg utile alla procedura di encoding: in particolare, per ciascuno dei tre formati, abbiamo
lanciato la procedura di encoding con 5 valori di BasisQp (Quantization parameter) diversi
(21,24,28,31,34): il nostro obiettivo parziale è stato quello di misurare le prestazioni (in termini di bitrate e

psnr) al variare del BasisQp, constatando, tra l’altro, una degradazione della qualità percepita
all’aumentare dello stesso.

8.1 Encoder Configuration
La configurazione dell’encoder per codificare i tre formati diversi è rimasta pressoché la stessa, in modo
tale da poter effettivamente confrontare i risultati in maniera attendibile: questo è stato anche il motivo
per il quale abbiamo utilizzato sempre JMVC per poter codificare MV e VpD con MVC e SbS con H.264/AVC.
[per i file di configurazione vedi Appendice B].

8.2 Operazioni svolte
Sono stati lanciati i seguenti comandi relativi agli eseguibili messi a disposizione da JMVC per 5 volte, una
per ogni BasisQp scelto. Tale procedura è stata ripetuta per tutti e tre i formati presi in analisi, il che ha
condotto ad un totale di 15 iterazioni:
./H264AVCEncoderLibTestStatic
-vf
cfg_<tipo-formato>_<BasisQP>
<view_x>
>>
encoding_<viev_x>_<tipo-formato>_<BasisQP>.log
./MVCBitStreamAssemblerStatic
-vf
assembler_<tipo-formato>_<BasisQP>
>>
assembling_<tipo-formato>_<BasisQP>.log
./H264AVCDecoderLibTestStatic stream-<tipo-formato>_<BasisQP>.264 decoded_<tipoformato>_<BasisQP>.yuv 2 >>decoding_<tipo-formato>_<BasisQP>.log
./PSNRStatic 432 240 view_0.yuv decoded_<tipo-formato>_<BasisQP>_<viex_x>.yuv 0
0
stream-<tipo-formato>_<BasisQP>_<view_x>.264
25
>>PSNR_<tipoformato>_<BasisQP>_<view_x>.log

Ad esempio, per la codifica del formato VpD, la sequenza di istruzioni per BasisQp=34 è stata la seguente:
./H264AVCEncoderLibTestStatic -vf cfg_left-plus-depth_34 0 >> encoding_0_leftplus-depth_34.log
./H264AVCEncoderLibTestStatic -vf cfg_left-plus-depth_34 1 >> encoding_1_leftplus-depth_34.log
./MVCBitStreamAssemblerStatic
-vf
assembler_left-plus-depth_34
>>
assembling_left-plus-depth_34.log
./H264AVCDecoderLibTestStatic stream-left-plus-depth_34.264 decoded_left-plusdepth_34.yuv 2 >>decoding_left-plus-depth_34.log
./PSNRStatic 432 240 view_0.yuv decoded_left-plus-depth_34_0.yuv 0 0 streamleft-plus-depth_34_0.264 25 >>PSNR_left-plus-depth_34_0.log
./PSNRStatic 432 240 view_1.yuv decoded_left-plus-depth_34_1.yuv 0 0 streamleft-plus-depth_34_1.264 25 >>PSNR_left-plus-depth_34_1.log

9. Discussione dei risultati
Per ciascuno dei tre formati, vengono mostrati nelle Tab.2, Tab.3 e Tab.4 i risultati della codifica ottenuti
variando i valori di BasisQp.
Oss.: nei casi di MV e VpD i risultati sono ottenuti come media dei singoli valori ottenuti per ciascuna vista.
Tab.2. – Video-plus-depth

BasisQp

bitrate [Kbps]

PSNR-y [dB]

21

168,704

45,01075

24

112,342

43,7539

28

66,485

42,1062

31

45,848

40,72395

34

31,962

39,56145

Tab.3. – Side by Side

BasisQp

Bitrate [Kbps]

PSNR-y [dB]

21

305,812

44,4761

24

207,316

43,1406

28

128,134

41,4000

31

92,832

40,1323

34

67,854

38,8073

Tab.4. –MultiView

BasisQp

bitrate [Kbps]

PSNR-y [dB]

21

136,679

44,5571

24

91,037

43,2159

28

54,682

41,4419

31

39,437

40,12905

34

28,986

38,65445

9.1 Osservazioni preliminari
Premesso che

PSNR=10 log 10

Max 2
MSE

Peak Signal to Noise Ratio
Formula n.1

MSE =

1
M∗N

M −1 N−1

∑ ∑ [ x (i , j)−x ' (i , j )]2
i=0

Mean Squared Error

j=0

Formula n.2

Nella Formula n.1 del rapporto tra Max e MSE viene calcolato il logaritmo in base 10 e poi quest’ultimo
viene moltiplicato per 10 per poterlo esprimere in dB. Max all’interno della stessa formula sta ad indicare
semplicemente il valore massimo che un pixel, appartenente alle due immagini che si stanno comparando,
può assumere. MSE non è nient’altro che l’errore quadratico medio la cui espressione viene esplicitata nella
Formula n.2. In quest’ultima M e N rappresentano la larghezza e l’altezza del frame. Infine x(i,j) e x’(i,j)
rappresentano rispettivamente il valore del pixel che occupa la riga i-esima e la colonna j-esima del frame
non compresso e di quello ricostruito.
Possiamo immediatamente notare che, nei tre casi, all’aumentare del BasisQp diminuisce il bitrate e il
PSNR della componente Y: questa è una ovvia conseguenza del ruolo che svolge il parametro BasisQp: esso
infatti misura il fattore di degradazione inerente alla fase di quantizzazione della codifica.

9.2 Osservazioni grafiche

Grafico 1. Rappresentazione del PSNR della componente di luminanza in funzione del BasisQp.

Nel Grafico 1, il PSNR della componente di luminanza viene calcolato in funzione del BasisQp; per tutti e tre
i formati possiamo osservare una relazione del tipo y=k-a*x, in cui x rappresenta il QP, y il PSNR della
componente di luminanza, a il coefficiente angolare che determina l’inclinazione delle rette e k non è
nient’altro che il termine noto che permette di shiftare le rette. In questo caso il formato VpD codificato
con MVC, a parità di Qp, risulta avere un maggior valore del PSNR-Y: questo è un aspetto importante
perché ci indica che il formato VpD ha subito una minore degradazione (in termini di qualità) rispetto agli
altri. La motivazione è verosimilmente legata al fatto che, poiché la seconda vista è una mappa di
profondità (vedi Fig. 20), si riesce a comprimere meglio un immagine di questo tipo.

Fig.20 : esempio di mappa di profondità associata ad un dato frame:
come è possibile vedere, la descrizione della profondità, ottenuta ad esempio come frutto di
operazioni di segmentazione e labeling degli oggetti principali presenti nel frame, consente
una codifica intra-frame ottimale.

Grafico 2. Rappresentazione del PSNR della componente di luminanza in funzione del bitrate.

Nel Grafico 2, rapportiamo il PSNR della componente di luminanza Y al bitrate necessario; ciascuno dei
punti evidenziati (cerchio, croce o triangolo) corrisponde ad uno dei 5 valori di BasisQp (per valori più alti di
bitrate corrispondono i BasisQP con valore più basso); nei tre casi l’andamento delle tre curve è di tipo
logaritmico. L’osservazione che può essere fatta è che il massimo valore di PSNR (≈45) è stato ottenuto con
il formato VpD codificato con MVC con BasisQp = 21, peraltro con un valore non elevato del bitrate. Nel

complesso le prestazioni ottenute con i formati VpD e MV codificati con MVC sono piuttosto simili; il
formato SbS codificato con H.264/AVC ha restituito risultati meno positivi.

Grafico 3. Rappresentazione dell’andamento del bitrate in funzione del BasisQp

Nel Grafico 3 il bitrate viene espresso in funzione del BasisQp: notiamo immediatamente nei tre casi che
l’andamento del bitrate è inversamente proporzionale al BasisQp secondo la legge y=k/x, con ksbs>kvpd>kmx.
Di conseguenza, a parità di BasisQp, il formato MV codificato con MVC necessità di un minor bitrate.
Questo aspetto è sicuramente positivo, dal momento che in una ipotetica trasmissione multimediale in
rete, avremmo bisogno di una banda inferiore rispetto agli altri formati. È anche vero che guardando il
Grafico 1, a parità di QP il PSNR di VpD codificato con MVC è superiore al PSNR di MV codificato sempre con
MVC; ciò significa che MV, a parità di QP, avrà un bitrate inferiore ma a scapito della qualità.

10. Conclusioni
In conclusione si può affermare che i formati MV con codifica MVC e VpD con codifica MVC si equivalgono,
nonostante ci si poteva aspettare delle prestazioni superiori da VpD codificato con MVC. Questo è dovuto
ad un limite pratico dell’analisi effettuata in quanto non si dispone di un tool specifico per la codifica della
mappa di profondità. Per sopperire a tale mancanza è stata utilizzata la codifica MVC che non è ottimizzata
per la compressione di video con la sola componente di profondità. Infine per il formato SbS codificato con
H.264/AVC non è stato possibile sfruttare alcuna correlazione tra viste poiché questo formato “ingloba” i
frame provenienti dalle due viste in un unico frame; e, tra l’altro, nella codifica intra-frame non si sfrutta in
maniera appropriata il fatto che ci sia un’elevata correlazione all’interno del dato frame. In conclusione
possiamo osservare che utilizzando il tool JMVC i risultati prestazionalmente più elevati in termini di bitrate
e PSNR si ottengono per i due formati MVC e VPD codificati con MVC.
Per poter effettuare una scelta tra i due, bisogna prendere in considerazione altri fattori:

 Numero di viste;
 Apparecchi target;
 Specifiche del servizio;
 Costi.
Il numero di viste è un elemento importantissimo nella scelta del formato di rappresentazione, infatti nel
caso volessimo codificare N viste prelevate da N videocamere differenti allora la scelta propenderà verso il
formato MV codificato con MVC; ma, se ci sono particolari vincoli in termini di bandwidth disponibile da
dover rispettare, utilizzare N/2 viste associando ad ognuna una mappa di profondità potrebbe essere utile
allo scopo e porterebbe anche ad un risparmio economico dimezzando il numero di videocamere
necessarie.
Gli apparecchi target, ossia i dispositivi a cui verrà affidata la decodifica di video 3D, sono un altro
parametro importantissimo da valutare perché, come già accennato nel paragrafo 3.2, alcuni potrebbero
non essere in grado di riprodurre il video 3D partendo da informazioni rappresentate nel formato VpD
codificate con MVC e quindi la scelta dovrebbe propendere automaticamente verso l’MV codificato con
MVC.
Altro fattore da non sottovalutare sono le specifiche del servizio: bandwidth disponibile, capacità
computazionali a disposizione, destinatari del video codificato, etc. Sicuramente è di fondamentale
importanza avere informazioni relativamente a quale sia il fine dell’encoding di questo video 3D. Per poter
effettuare una scelta corretta, quindi, bisogna capire se il video codificato dovrà essere visualizzato in
locale oppure dovrà essere distribuito in rete. Nel secondo caso si potrebbe scegliere di usare il formato
MV codificandolo con MVC dato che garantisce un bitrate leggermente più basso, a parità di QP, rispetto al
VpD portando però ad una degradazione della qualità maggiore del video rispetto a quest’ultimo.
Infine è il fattore economico, ossia i costi associati ad una determinata scelta. Utilizzare il formato di
codifica VpD potrebbe essere una scelta vantaggiosa sotto alcuni punti di vista, ma potrebbe portare a dei
costi maggiori sia in termine di tempo che economici, perché le tecniche di acquisizione o generazione
della mappa di profondità, come spiegato sempre nel paragrafo 3.2, sono complesse e dispendiose.
Ovviamente anche utilizzare l’MV può prevedere dei costi non indifferenti, basti pensare che si necessità di
N videocamere che devono essere sincronizzate nel minimo dettaglio, allineate e stabili.
Grazie ai risultati pervenuti possiamo quindi dire che in questo particolare confronto, ottenuto sfruttando
il tool JMVC, l’MV codificato con MVC sembra fornire i risultati migliori e quindi ci sentiamo di poter
affermare che è il formato di rappresentazione migliore tra i tre.

APPENDICE A
Qt è una cross-platform application e un framework UI dotato di APIs per la programmazione in C++. Per
poter utilizzare il software realizzato su un'altra macchina, non è necessario effettuare alcuna installazione
dello stesso, ma si dovranno installare le librerie Qt [9] (l’applicativo non è stato realizzato mediante
compilazione statica delle librerie) e un compilatore gcc per sistemi Linux.
Installare le librerie Qt è molto semplice, anche se attualmente viene solo fornita una versione di prova
delle librerie per 30 giorni (le librerie Qt non sono più fruibili gratuitamente ma solo a pagamento, anche
per scopi non commerciali): per la versione Linux, ci si dovrà registrare al seguente indirizzo
http://qt.digia.com/Try-Qt-Now/Qt-commercial-evaluation/?platform=embedded-linux-cpp.
Successivamente bisognerà seguire una semplice procedura di compilazione (i comandi da utilizzare
saranno: “./configure” – “./make” – “./make install”) preceduta dal settaggio delle variabili d’ambiente del
nostro sistema.
Installate le librerie, bisognerà spostarsi (da terminale) nella cartella contenente l’eseguibile, accertarsi che
l’utente sia dotato dei privilegi di esecuzione “chmod +x <nomefile>” e lanciarlo “./<nomefile>”.

APPENDICE B
MV – Configuration File
# JMVC Main Configuration File
#====================== GENERAL =========================================
InputFile
./InputSample/test
# input file
OutputFile
./OutputSample/QP21/stream
# bitstream file
#./OutputSample/QP24/stream
ReconFile
./OutputSample/QP21/rec
# reconstructed file
#...
MotionFile
motion
# motion information file
SourceWidth
432
# input frame width
SourceHeight
240
# input frame height
FrameRate
25.0
# frame rate [Hz]
FramesToBeEncoded
100
# number of frames
#======================
SymbolMode
FRExt
BasisQP

CODING ==========================================
1
# 0=CAVLC, 1=CABAC
1
# 8x8 transform (0:off, 1:on)
21
# Quantization parameters
#24,28,31,34
#====================== INTERLACED ======================================
MbAff
0
# 0=frameMb, 1=MbAff
PAff
0
# 0=frame, 1=field, 2=frame/field
#======================
GOPSize
IntraPeriod
NumberReferenceFrames
InterPredPicsFirst
Log2MaxFrameNum
Log2MaxPocLsb
DeltaLayer0Quant
DeltaLayer1Quant
DeltaLayer2Quant
DeltaLayer3Quant
DeltaLayer4Quant
DeltaLayer5Quant
MaxRefIdxActiveBL0
MaxRefIdxActiveBL1
MaxRefIdxActiveP

STRUCTURE =======================================
16
# GOP Size (at maximum frame rate)
16
# Anchor Period
3
# Number of reference pictures
1
# 1 Inter Pics; 0 Inter-view Pics
11
# specifies max. value for frame_num (4..16)
7
# specifies coding of POCâ€™s (4..15)
0
# differential QP for layer 0
3
4
5
6
7
2
# active entries in ref list 0 for B slices
2
1
# active entries in ref list for P slices

#======================= MOTION SEARCH ==================================
SearchMode
4
# Search mode (0:BlockSearch, 4:FastSearch)
SearchFuncFullPel
3
# Search function full pel
#
(0:SAD, 1:SSE, 2:HADAMARD, 3:SAD-YUV)
SearchFuncSubPel
2
# Search function sub pel
#
(0:SAD, 1:SSE, 2:HADAMARD)
SearchRange
32
# Search range (Full Pel)
BiPredIter
4
# Max iterations for bi-pred search
IterSearchRange
8
# Search range for iterations (0: normal)
#======================== LOOP FILTER ====================================
LoopFilterDisable
0
# Loop filter idc (0: on, 1: off, 2:

#
on except for slice boundaries)
# AlphaOffset(-6..+6): valid range
# BetaOffset (-6..+6): valid range

LoopFilterAlphaC0Offset 0
LoopFilterBetaOffset
0

#========================= WEIGHTED PREDICTION ============================
WeightedPrediction
0
# Weighting IP Slice (0:disable, 1:enable)
WeightedBiprediction
0
# Weighting B Slice (0:disable, 1:explicit,
2:implicit)
#=================== PARALLEL DECODING INFORMATION SEI Message
==================
PDISEIMessage
0
# PDI SEI message enable (0: disable,
1:enable)
PDIInitialDelayAnc
2
# PDI initial delay for anchor pictures
PDIInitialDelayNonAnc
2
# PDI initial delay for non-anchor pictures
#============================== NESTING
=============================
NestingSEI
0
#(0:
SnapShot
0
#(0:
#========================== ACTIVE VIEW
========================
ActiveViewSEI
0
#(0:
#===================== VIEW SCALABILITY
==================
ViewScalInfoSEI
0
#(0:

SEI MESSAGE
NestingSEI off, 1: NestingSEI on)
SnapShot off, 1: SnapShot on)
INFO SEI MESSAGE
ActiveViewSEI off, 1: ActiveViewSEI on)
INFOMATION SEI MESSAGE
ViewScalSEI off, 1: ViewScalSEI on)

#============== Level conformance checking of the DPB size ==============
DPBConformanceCheck
0
# (0: disable, 1: enable, 1:default)
#================= MULTIVIEW CODING PARAMETERS ===========================
NumViewsMinusOne
1
# (Number of view to be coded minus 1)
ViewOrder
0-1
# (Order in which view_ids are coded)
View_ID
Fwd_NumAnchorRefs
Bwd_NumAnchorRefs
Fwd_NumNonAnchorRefs
Bwd_NumNonAnchorRefs
View_ID
Fwd_NumAnchorRefs
Bwd_NumAnchorRefs
Fwd_AnchorRefs
0 0

0
0

# view_id (0..1024): valid range
# (number of list_0 references for anchor)
# (number of list 1 references for anchor)
# (number of list 0 references for non-anchor)

0
0
0
1
1
0
0
0

#(number of list 0 references for non-anchor)

VpD – Configuration File
#====================== GENERAL =========================================
InputFile
view
# input file
OutputFile
stream-left-plus-depth_21
# bitstream file
#stream-left-plus-depth_24
ReconFile
rec-left-plus-depth_21
#rec-left-plus-depth_24

MotionFile
SourceWidth
SourceHeight
FrameRate
FramesToBeEncoded

motion
432
240
25.0
100

#
#
#
#
#

motion information file
input frame width
input frame height
frame rate [Hz]
number of frames

#====================== CODING ==========================================
SymbolMode
1
# 0=CAVLC, 1=CABAC
#CAVLC (Context Adaptive Variable Length Coding: minore complessità
#computazionale e minore efficienza);
#CABAC (Context Adaptive Binary Arithmetic Coding: maggiore complessità
#computazionale richiesta e maggiore efficienza nella codifica);
FRExt
1
BasisQP
21
#24,
#28,
#31,
#34
#====================== INTERLACED ======================================
MbAff
0
PAff
0
#======================
GOPSize
IntraPeriod
InterPredPicsFirst
Log2MaxFrameNum
Log2MaxPocLsb
DeltaLayer0Quant
DeltaLayer1Quant
DeltaLayer2Quant
DeltaLayer3Quant
DeltaLayer4Quant
DeltaLayer5Quant
MaxRefIdxActiveBL0
MaxRefIdxActiveBL1
MaxRefIdxActiveP

STRUCTURE =======================================
16
16
# Anchor Period (>=GOPSize)
3
1
11
7
0
3
4
5
6
7
2
2
1

#======================= MOTION SEARCH ==================================
SearchMode
4
SearchFuncFullPel
3
#
SearchFuncSubPel
2
#
SearchRange
32
BiPredIter
4
IterSearchRange
8
#======================== LOOP FILTER ==========================================
LoopFilterDisable
0
# on except for slice boundaries)
0
#========================= WEIGHTED PREDICTION =================================
WeightedPrediction
0
0
2:implicit)
#=================== PARALLEL DECODING INFORMATION SEI Message =================

PDISEIMessage
1:enable)
PDIInitialDelayAnc

0


2
2


#============================== NESTING SEI MESSAGE ============================
NestingSEI
0
#(0: NestingSEI off, 1: NestingSEI on)
SnapShot
0
#(0: SnapShot off, 1: SnapShot on)
#========================= ACTIVE VIEW INFO SEI MESSAGE ========================
ActiveViewSEI
0
#(0: ActiveViewSEI off, 1: ActiveViewSEI on)
#==================== VIEW SCALABILITY INFOMATION SEI MESSAGE ==================
ViewScalInfoSEI
0
#(0: ViewScalSEI off, 1: ViewScalSEI on)
DPBConformanceCheck
0
NumViewsMinusOne
1
ViewOrder
0-1
View_ID
Fwd_NumAnchorRefs
Bwd_NumAnchorRefs
View_ID
Fwd_NumAnchorRefs
Bwd_NumAnchorRefs
Fwd_AnchorRefs
0 0

0
0


0
0
0
1
1
0
0
0


SbS – Configuration File
#====================== GENERAL =========================================
InputFile
./InputSample/testSbS
# input file
OutputFile
./OutputSample/QP21/streamSbS
# bitstream file
#./OutputSample/QP24/streamSbS
ReconFile
./OutputSample/QP21/recSbS
#...
MotionFile
motion
# motion information file
SourceWidth
864
# input frame width
SourceHeight
240
# input frame height
FrameRate
25.0
# frame rate [Hz]
FramesToBeEncoded
100
# number of frames
#======================
SymbolMode
FRExt
BasisQP

CODING ==========================================
1
# 0=CAVLC, 1=CABAC
1
21
#24,28,31,34
#====================== INTERLACED ======================================
MbAff
0
PAff
0

#======================
GOPSize
IntraPeriod
InterPredPicsFirst
Log2MaxFrameNum
Log2MaxPocLsb
DeltaLayer0Quant
DeltaLayer1Quant
DeltaLayer2Quant
DeltaLayer3Quant
DeltaLayer4Quant
DeltaLayer5Quant
MaxRefIdxActiveBL0
MaxRefIdxActiveBL1
MaxRefIdxActiveP

STRUCTURE =======================================
16
16
# Anchor Period
3
1
11
7
0
3
4
5
6
7
2
2
1

#======================= MOTION SEARCH ==================================
SearchMode
4
SearchFuncFullPel
3
#
SearchFuncSubPel
2
#
SearchRange
32
BiPredIter
4
IterSearchRange
8
#======================== LOOP FILTER ====================================
LoopFilterDisable
0
#
on except for slice boundaries)
0
#========================= WEIGHTED PREDICTION ============================
WeightedPrediction
0
0
2:implicit)
#================== PARALLEL DECODING INFORMATION SEI Message ==================
PDISEIMessage
0
1:enable)
PDIInitialDelayAnc
2
2
#============================= NESTING SEI MESSAGE =============================
NestingSEI
0
#(0: NestingSEI off, 1: NestingSEI on)
SnapShot
0
#(0: SnapShot off, 1: SnapShot on)
#========================== ACTIVE VIEW INFO SEI MESSAGE
========================
ActiveViewSEI
0
#(0: ActiveViewSEI off, 1: ActiveViewSEI on)
#===================== VIEW SCALABILITY INFOMATION SEI MESSAGE =================
ViewScalInfoSEI
0
#(0: ViewScalSEI off, 1: ViewScalSEI on)
DPBConformanceCheck
0
NumViewsMinusOne
0
ViewOrder
0
View_ID

0


Fwd_NumAnchorRefs
Bwd_NumAnchorRefs

0
0
0
0


RIFERIMENTI
[1]
N.A. Dodgson, J.R. Moore, S.R. Lang, “Multi-view autostereoscopic 3D display,” International
Broadcasting Convention, pp.497-502, 1999
[2]
Site: http://boccignone.di.unimi.it/Modelli_Percezione_files/LezPMPSpazio(1).pdf, “La percezione
dello spazio (1): indizi monoculari”;
[3]
H. Brust, A. Smolic, K. Müller, G. Tech, and T. Wiegand, "Mixed Resolution Coding of Stereoscopic
Video for Mobile Devices", Proc. 3DTVCON 2009, Potsdam, Germany, May 2009
[4]
A. Bourge, J. Gobert and F. Bruls, “MPEG-C part 3: Enabling the introduction of video plus depth
contents,” in Proc. of IEEE Workshop on Content Generation and Coding for 3D-television, Eindhoven, The
Netherlands, June 2006.
[5]
M. Halle, “Autostereoscopic Displays and Computer Graphics,” Computer Graphics, ACM Siggraph,
vol. 31, no. 2, 1997, pp. 58-62.
[6]

“Seminario sulle tecnologie 3D”, Ing. C.Ceglie, Telematics, Politecnico di Bari.

[7]
Y. Chen, M. Hannuksela, L. Zhu, A. Hallapuro, M. Gabbouj, and H. Li, "Coding techniques in
multiview video coding and joint multiview video model," in Picture Coding Symposium, 2009. PCS 2009,
pp. 1 -4, 6-8 2009.
[8]

Site: http://sp.cs.tut.fi/mobile3dtv/stereo-video/;

[9]

Site: http://qt.digia.com/product/ - Qt Products;

[10]
M. Flierl and B. Girod. Multiview video compression. IEEE Signal Processing Mag., 24(6):66–76,
November 2007.
[11]
Site: http://www.cablelabs.com/specifications/OC-SP-CEP3.0-I01-100827.pdf, “Content Encoding
Profiles 3.0 Specification”
[12]
Iain E. G. Richardson, “H.264 and MPEG-4 Video Compression: Video Coding for Next-generation
Multimedia”, 2003 John Wiley & Sons, Ltd. ISBN: 0-470-84837-5.

Sistemi e Reti Multimediali - studio della codifica 3D

Recommandé

Recommandé

Contenu connexe

Similaire à Sistemi e Reti Multimediali - studio della codifica 3D

Similaire à Sistemi e Reti Multimediali - studio della codifica 3D (20)

Dernier

Dernier (17)

Sistemi e Reti Multimediali - studio della codifica 3D