Progetto 3DCloudViz
NICE -DIEE
WP 2
Algoritmi e sistemi per la visualizzazione
remota anche su reti a banda limitata ed
elevata latenza
Deliverable D2
R.2.1 Stato dell'arte sugli algoritmi di compressione
e metriche per la comparazione degli algoritmi di
compressione
R.2.2 Relazione test comparativo sulle performance
reali degli algoritmi di compressione in contesti
operativi generici e per categorie specifiche di
contenuto (es. testo, grafica, fotografie )
R.2.3 Dataset per la validazione degli algoritmi di
compressione
R.2.4 Modello architetturale di un sistema di
compressione adattativa, sistema di decisione per
la selezione dinamica dell'algoritmo di
compressione e protocollo di comunicazione tra
client e server
Pattern Recognition and Applications Lab
DIEE - Università di Cagliari
R2.1
STATO DELL'ARTE SUGLI ALGORITMI DI COMPRESSIONE E
METRICHE PER LA COMPARAZIONE DEGLI ALGORITMI DI
COMPRESSIONE
Progetto 3D CloudWiz
Progetto 3D CloudWiz | ATI NICE - DIEE
Sommario
Sommario..............................................................................................................................................i
Obiettivo del documento......................................................................................................................1
Compressione lossless di immagini in real-time..................................................................................2
Algortimi di compressione dati........................................................................................................3
Codici di Huffman........................................................................................................................4
Codifica aritmetica.......................................................................................................................5
LZ77 – LZ78................................................................................................................................5
LZW(Lempel-Ziv-Welch)............................................................................................................6
RLE – Run Length Encoding.......................................................................................................7
Deflate..........................................................................................................................................7
Algoritmi di compressione lossless per immagini............................................................................8
Lossless JPEG e JPEG-LS............................................................................................................8
JPEG2000 – lossless...................................................................................................................10
JPEG XR.....................................................................................................................................11
Confronti tra i tre algoritmi precedentemente descritti..............................................................12
GIF..............................................................................................................................................13
PNG............................................................................................................................................13
Implementazioni multithread di diverso tipo.................................................................................15
ImageZero...................................................................................................................................15
LZ4.............................................................................................................................................17
Algoritmi di compressione proposti in letteratura..........................................................................17
A Lossless Image Compression Technique using Location Based Approach............................18
Context-based Dictionary Image Compression..........................................................................19
A new Algorithm for Lossless Compression applied to two-dimensional Static Images...........21
Fast Lossless Color Image Compressing Method Using Neural Network.................................22
Conclusioni.....................................................................................................................................24
Bibliografia.....................................................................................................................................25
Compressione di immagini generiche a contenuto eterogeneo (compound images).........................29
Metodi di segmentazione delle componenti di un'immagine.........................................................30
Approccio ad oggetti..................................................................................................................30
Approccio a layer.......................................................................................................................30
Approccio a blocchi....................................................................................................................32
i
Progetto 3D CloudWiz | ATI NICE - DIEE
Approccio ibrido.........................................................................................................................33
Algoritmi proposti in letteratura.....................................................................................................34
Metodi a blocchi.............................................................................................................................34
Metodi a layer.............................................................................................................................39
Metodi ibridi...............................................................................................................................41
Conclusioni.....................................................................................................................................44
Bibliografia.....................................................................................................................................44
Metriche per il confronto fra algoritmi di compressione di immagini...............................................47
Compression ratio...........................................................................................................................47
Tempo di compressione e decompressione....................................................................................47
Mean Squared Error – MSE...........................................................................................................48
Peak Signal to Noise Ratio – PSNR...............................................................................................48
Structural Similarity Index – SSIM................................................................................................49
Bibliografia.....................................................................................................................................50
ii
Progetto 3D CloudWiz | ATI NICE - DIEE
Obiettivo del documento
Scopo di questo documento l’identificazione degli algoritmi più promettenti, tra quelli emergenti,
per la compressione delle informazioni e la definizione di un insieme di metriche che consentano
un efficace confronto dei diversi algoritmi sia nell'utilizzo in contesti generici che nell'applicazione
a particolari categorie di informazioni e di pesare opportunamente la possibilità di modulare dei
parametri di configurazione in modo da poterne modificare dinamicamente il funzionamento in
funzione di contesti operativi (differenti condizioni di banda e latenza).
Il documento è organizzato in diverse sezioni e coprirà i seguenti argomenti:
Compressione lossless di immagini in real-time;
Compressione di immagini generiche a contenuto eterogeneo (compound images);
Metriche per il confronto fra algoritmi di compressione di immagini.
1
Progetto 3D CloudWiz | ATI NICE - DIEE
Compressione lossless di immagini in real-time
In questa sezione del documento si andrà ad analizzare lo stato dell'arte relativo alla codifica e alla
decodifica delle immagini 2D nello specifico caso di algoritmi di tipo lossless, quindi senza perdita
d'informazione, che possano essere utilizzati in un contesto nel quale sia necessaria la loro
applicazione in real time (RT) o near real time.
In letteratura vengono presentati un elevato numero di algoritmi di compressione di tipo lossy,
specialmente facenti uso di DCT (Discrete Cosine Transform) o di DWT (Discrete Wavelet
Transform) e/o loro combinazioni, mentre gli algoritmi di tipo lossless, presenti in numero più
limitato, rimandano a tecniche di compressione più generiche ed universali per tutti i tipi di dati.
All'interno di quest'insieme di algoritmi risulta ancora più complesso andare ad identificare
tecniche che agiscano in real time o near real time.
L'evoluzione degli studi sugli algoritmi di compressione d'immagini viene inoltre condizionata dalla
presenza sul mercato di alcuni algoritmi di COdifica e DECodifica (CODEC) ormai ritenuti degli
standard (ad esempio i vati PNG, JPEG ecc): essi raggiungono dei risultati tali che risulta complessa
la realizzazione di metodologie che possano migliorarne le performance.
In relazione alle specificità richieste, algoritmi di tipo lossless e funzionanti in real time o near real
time, vengono presentate in questo documento tre categorie di algoritmi di compressione:
algoritmi generici di compressione dati;
algoritmi di compressione immagini considerati standard;
algoritmi di compressione immagini proposti nella ricerca.
Per gli algoritmi generici di compressione dati verrà presentato un riepilogo delle tecniche di
compressione dati più comuni (es. codici di Huffman, LZ77, RLE ecc) con una breve descrizione
dell'algoritmo che esse implementano.
Per quanto riguarda gli algoritmi di compressione immagini considerati standard verranno
presentate, anche con tabelle di confronto, quelle metodologie di compressione più diffuse nel
mercato oggetto di studi specialmente nel settore di sviluppo di tipo industriale (es. JPEG-XR, PNG
2
Progetto 3D CloudWiz | ATI NICE - DIEE
ecc).
Per quanto riguarda gli altri algoritmi allo stato dell'arte proposti nella letteratura verrà presentato
un resoconto delle tecniche che appaiono più interessanti dal punto di vista delle performance
promesse.
Algortimi di compressione dati
In questo paragrafo andiamo ad analizzare le tecniche di compressione dei dati senza perdite, o
lossless, che avviene attraverso l'utilizzo di codici, quindi definendo delle corrispondenze tra
simboli d'ingresso e simboli d'uscita. Tali codici agiscono sui dati in ingresso, che possono essere
sequenze di simboli e/o dati, in virtù di un modello statistico della sorgente che genera gli stessi
simboli.
Il modello al quale si fa riferimento può essere adattativo, quindi costruito e/o perfezionato
contestualmente alla codifica dei simboli, oppure sussistere o essere dato a priori, quindi costruito
sui dati stessi in modo globale ad esempio con una pre analisi delle statistiche dei simboli che
occorre codificare.
L'output di queste tecniche sarà quello di generare un bit-stream dal quale è possibile, mediante
l'operazione inversa di decodifica, risalire perfettamente e senza nessuna alterazione o perdita
d'informazione ai dati originali.
Le principali tecniche di compressione dati presenti in letteratura risultano essere:
codici di Huffman;
codifica aritmetica [1];
LZ77 – LZ78;
LZW(Lempel-Ziv-Welch);
RLE – Run Length Encoding.
Altri algoritmi di compressione dati spesso utilizzati sono:
trasformata di Burrows-Wheeler (BWT) [2];
Prediction by Partial Matching (PPM) [3];
3
Progetto 3D CloudWiz | ATI NICE - DIEE
Deflate [4].
Queste compressioni lossless sono assolutamente generiche, adattabili quindi a qualunque
formato dati, ma al variare della tipologia di dati in ingresso esse offrono prestazioni notevolmente
differenti le une dalle altre.
Combinazioni di queste tecniche, o parti di esse sono già utilizzati all'interno di comuni codec per
immagini. Abbiamo ad esempio che LZW viene utilizzato per le immagini GIF, una variante di
Deflate è stata implementata per PNG, mentre LZW e RLE sono utilizzate direttamente nel formato
TIFF.
Codici di Huffman
I codici di Huffman sono tra i primi algoritmi di compressione dell'informazione. Nel 1952 David A.
Huffman pubblicò un articolo [5] in cui mostrava un metodo per la costruzione di codici con criteri
di minima ridondanza, questo metodo si mostra quindi particolarmente adatto alla compressione
lossless dei dati in differenti contesti.
Si può definire il processo di definizione dei codici come segue:
1) si crea una lista ordinata di simboli in base alle occorrenze degli stessi nel messaggio originale;
2) si ripetono i passi 2a, 2b e 2c tante volte finché all'interno della lista non rimane un unico
simbolo;
a) si determinano i due elementi meno frequenti all'interno della lista. Si crea un nodo
“genitore” dell'albero di Huffman avente come nodi “figli” questi due elementi;
b) si assegna la somma delle frequenze dei nodi “figli” al nodo “genitore” e lo si reinserisce
nella lista ordinata;
c) si cancellano i figli dalla lista ordinata;
3) si assegna infine una parola codice ad ogni elemento basandosi sulla sua posizione a partire
dalla radice: in questo modo i simboli più frequenti saranno codificati con parole più corte e
viceversa quelli più rari con parole più lunghe.
4
Progetto 3D CloudWiz | ATI NICE - DIEE
Questo algoritmo di compressione è stato poi adattato e migliorato in differenti modi. I più
conosciuti, qui non presentati, sono:
Codifica adattativa di Huffman [6];
Algoritmo di Huffman con template;
Codifica di Huffman a base n [7];
Codifica con costi per lettera diseguali [8].
Codifica aritmetica
Negli anni '80 sono stati introdotti nuovi tipi di algoritmi statistici che hanno ovviato ad alcuni
problemi che si presentavano con l'algoritmo di Huffman: i codici aritmetici [12].
Il codice di Huffman associa un valore intero ad ogni elemento della sorgente, il che porta ad un
dispendio eccessivo in termini di memoria e proporzionale al numero di simboli all'interno della
sorgente.
I codici aritmetici codificano invece simboli, o gruppi di simboli, con numeri decimali, e permettono
quindi di adoperare per la codifica dei numeri frazionari di bits.
Se esaminiamo un solo simbolo, ovviamente, i risultati ottenuti con le due diverse tecniche
saranno molto simili; ma una volta che esaminiamo una sequenza lunga di dati d'ingresso, la
somma degli arrotondamenti (tali si possono considerare i bits adoperati dalla codifica di Huffman
rispetto a quelli dei codici aritmetici) per la codifica dei singoli simboli porta ad una differenza
netta tra i risultati ottenuti con i codici aritmetici e il codice di Huffman.
LZ77 – LZ78
Altre tipologie di codifica sono quelle descritte dagli algoritmi Lempel-Ziv: di queste esistono
differenti implementazioni.
Nella prima versione (LZ77) [13] la codifica/compressione avviene mediante la sostituzione di parti
di dati già processate. Si utilizza una finestra di scorrimento dei dati avente dimensione fissa:
quando la finestra incontra un dato ripetuto allora tale dato viene sostituito da una coppia
“lunghezza-distanza” che indica l'esigenza di dover copiare una certa porzione di dati, avente una
certa “lunghezza”, da una determinata “distanza”.
5
Progetto 3D CloudWiz | ATI NICE - DIEE
Con questa tipologia di compressione la possibilità di trovare una corrispondenza nel “dizionario”
per la stringa di dati esaminata è quindi dipendente unicamente dai dati contenuti nella finestra di
scorrimento in quell'istante e non si tiene invece conto dei record precedenti.
Per superare questi inconvenienti e aumentare l'efficacia della codifica Lempel e Ziv, un anno dopo,
svilupparono la codifica LZ78 [14]: si costruisce un dizionario dei dati già incontrati e si
sostituiscono le occorrenze dei dati presenti nella finestra con un riferimento ai dati del dizionario.
La decodifica è analoga alla codifica, all'inizio il dizionario contiene solo la stringa vuota e mentre
viene riempito viene anche restituita la codifica originale.
La differenza con il precedente algoritmo è il ridotto numero di confronti tra stringhe di dati e
quindi una maggiore velocità, riguardo al coefficiente di compressione non ci sono rilevanti
differenze.
Anche a questi algoritmi sono stati applicati diversi adattamenti: da essi, ad esempio, derivano
LZW, LZMA(Lempel Ziv Markov chain) [15] e LZSS [16].
LZW(Lempel-Ziv-Welch)
Nel 1984 Terry Welch rivisitò l'algoritmo LZ78 [17] cercando di migliorarlo dal punto di vista della
velocità adottando un dizionario base non vuoto.
L’algoritmo LZW si basa sulla creazione di un dizionario di stringhe ricorrenti in un determinato
insieme di dati utilizzando un dizionario di base che di norma è costituito dai 255 caratteri
derivanti dalla codifica ASCII.
Leggendo un unico carattere alla volta si aggiorna il dizionario mantenendo la sequenza codificata
più lunga incontrata sino a quel momento. La velocità di questo algoritmo, rispetto a LZ78, è tale
che l'ha portato da essere stato scelto e utilizzato in sistemi come:
l'utility UNIX compress/uncompress.
formato grafico TIFF.
formato grafico GIF.
standard V.42 bis per la trasmissione dati.
6
Progetto 3D CloudWiz | ATI NICE - DIEE
Il prezzo da pagare per un incremento di performance in termini di velocità è un fattore di
compressione che risulta non essere elevato.
RLE – Run Length Encoding
L'algoritmo RLE è una forma molto semplice di codifica per la compressione dati.
Esso è basato sul fatto che in ogni flusso di dati sono presenti diversi dati simili, i valori ripetuti
vengono definiti “run”, questi dati ridondanti saranno sostituiti con un contatore e il valore ad esso
associato.
Questo tipo d’algoritmo intuitivo funziona bene con tipologie di dati in cui in cui sono presenti un
largo numero di occorrenze consecutive dello stesso byte pattern: da questo deriva il suo largo
impiego nel settore legato alla compressione di immagini. Ad esempio RLE si presta bene per la
compressione di formati grafici come BMP, PCX, TIFF (basandosi sulla ridondanza spaziale delle
immagini) e viene anche utilizzato in alcune implementazione di formati editoriali come PDF o
nella tecnologia per l'invio di FAX.
Possiamo trovare diverse implementazioni di quest’algoritmo:
RLE a livello di bit: ogni byte codifica sequenze di bit uguali;
RLE a livello di byte: ogni run è codificato da due byte;
RLE a livello di byte misto: si utilizza il concetto di byte di lunghezza, ossia un byte in cui il
bit più indicativo denota il tipo di run (1 = compresso, 0 = non compresso).
Deflate
L'algoritmo Deflate è un algoritmo per la compressione dei dati introdotto dal programma PKZIP, e
quindi formalizzato nella RFC 1951 [18]. Esso utilizza una combinazione dei metodi di
compressione LZ77 e la codifica di Huffman.
Deflate comprime i dati del flusso d'ingresso in blocchi di byte di lunghezza arbitraria massima di
64KB. Ognuno di questi blocchi è compresso separatamente mediante una combinazione di LZ77 e
Huffman secondo il seguente criterio:
gli alberi di Huffman usati per un blocco sono indipendenti da quelli utilizzati per blocchi
precedenti o successivi;
7
Progetto 3D CloudWiz | ATI NICE - DIEE
LZ77 può utilizzare un riferimento a una stringa duplicata vista in precedenza nella
sequenza di input.
La decisione relativa alla modalità di suddivisione in blocchi viene demandata all'utilizzatore finale
in base alle proprie esigenze e in base alla tipologia di dato da andare a comprimere.
Algoritmi di compressione lossless per immagini
In questa sezione vengono presentati i principali algoritmi di compressione e decompressione delle
immagini considerati degli standard.
In particolare si farà riferimento alle alla famiglia di codec lossless appartenenti allo standard JPEG
(Lossless Jpeg / Jpeg-LS, Jpeg2000 e JpegXR), il formato GIF e il formato PNG.
Vengono inoltre presentati ImageZero e LZ4 che, pur non rappresentando una novità in termini di
tecniche di compressione, rappresenta una novità in quanto aggiunge la parallelizzazione delle
operazioni rispetto alle implementazioni dei codec tradizionali al fine di garantire una notevole
velocità di codifica.
Lossless JPEG e JPEG-LS
A partire dal 1993, in seguito al successo della serie degli standard JPEG lossy, la commissione JPEG
(Joint Photographic Experts Group) valutò che fosse necessario adottare una modalità di
compressione lossless nello standard JPEG.
La prima versione del "lossless" JPEG codificava la differenza tra ogni pixel ed il valore "predetto"
per quel pixel. Il valore "predetto" è il risultato di una funzione che usa come parametri i valori dei
pixel che si trovano sopra, sopra a sinistra e immediatamente alla sinistra del pixel in esame. Tale
codifica viene anche chiamata Pulse Code Modulation (DPCM) e veniva utilizzata al posto della
comune DCT utilizzata nel lossy JPEG.
La sequenza di dati ottenuta veniva poi codificata con il metodo di Huffman o con altre codifiche
aritmetiche.
La ricerca di un sostituto che garantisse minore complessità computazionale e aumentasse le
performance in termini di efficienza di compressione portò all'analisi di algoritmi che
continuassero a non utilizzare la DCT – o le trasformazioni tra spazi di colore – ma che altresì
8
Progetto 3D CloudWiz | ATI NICE - DIEE
portassero ad una compressione lossless o quasi lossless. Il risultato di tale ricerca è stato poi
standardizzato in ISO-14495-1/ITU-T.87 con il nome di JPEG-LS.
Il core del JPEG - LS è basato sull'algoritmo LOCO -I [19]di HP che si contraddistingue in quanto la
fase di codifica viene preceduta da due fasi: quella di predizione e quella di modellazione degli
errori.
La bassa complessità di questa tecnica deriva da due fattori:
il fatto che la previsione residuale segue quella che viene chiamata “Discrete Laplace Distribution”;
l'utilizzo, in fase di codifica, di codici come quelli di Golomb-Rice, noti per essere ideali per le
distribuzioni geometriche.
Di seguito una tabella comparativa che illustra i risultati di compressione per un test set di
immagini con l'utilizzo di differenti algoritmi candidati ad appartenere allo standard JPEG-LS
espressi in bits/sample [20]:
Image
LOCO-I
JPEG-LS FELICS LossLess LossLess CALIC
JPEG
JPEG
Arithm
Huffman Arithm
LOCO-A PNG
Bike
3.59
3.63
4.06
4.34
3.92
3.50
3.54
4.06
cafe
4.80
4.83
5.31
5.74
5.35
4.69
4.75
5.28
woman
4.17
4.20
4.58
4.86
4.47
4.05
4.11
4.68
tools
5.07
5.08
5.42
5.71
5.47
4.95
5.01
5.38
bike3
4.37
4.38
4.67
5.18
4.78
4.23
4.33
4.84
cats
2.59
2.61
3.32
3.73
2.74
2.51
2.54
2.82
water
1.79
1.81
2.36
2.63
1.87
1.74
1.75
1.89
finger
5.63
5.66
6.11
5.95
5.85
5.47
5.50
5.81
us
2.67
2.63
3.28
3.77
2.52
2.34
2.45
2.84
chart
1.33
1.32
2.14
2.41
1.45
1.28
1.18
1.40
chart s
2.74
2.77
3.44
4.06
3.07
2.66
2.65
3.21
compound1 1.3
1.27
2.39
2.75
1.50
1.24
1.21
1.37
compound2 1.35
1.33
2.40
2.71
1.54
1.24
1.25
1.46
9
Progetto 3D CloudWiz | ATI NICE - DIEE
aerial2
4.01
4.11
4.49
5.13
4.14
3.83
3.58
4.44
faxballs
0.97
0.90
1.74
1.73
0.84
0.75
0.64
0.96
gold
3.92
3.91
4.10
4.33
4.13
3.83
3.85
4.15
hotel
3.78
3.80
4.06
4.39
4.15
3.71
3.72
4.22
Media
3.18
3.19
3.76
4.08
3.40
3.06
3.06
3.46
JPEG2000 – lossless
Si tratta del successore designato del JPEG, già ufficializzato come standard ISO/ITU che va sotto il
nome di JPEG2000 [21].
La versione completa delle specifiche relative a questo formato è scaricabile dalla pagina web del
JPEG.org [22].
JPEG2000 è completamente diverso dal suo predecessore JPEG: propone prima di tutto il fatto che
uno stesso algoritmo possa essere adatto sia alla codifica lossy che a quella lossless.
La differenza tra i due standard è sostanziale e possiamo brevemente identificarle come segue:
durante la prima trasformazione, quella che in JPEG veniva svolta tramite l'utilizzo di una
DCT (Discrete Cosine Transform), in JPEG2000 si utilizza la DWT (Discrete Wavelet
Transform);
la fase di quantizzazione dei valori è opzionale in JPEG2000 se l'utente desidera ottenere
una compressione senza perdita d'informazione.
JPEG utilizza una versione avanzata della codifica di Huffman, JPEG2000 utilizza un metodo
chiamato Embedded Block Coding with Optimized Truncation (EBCOT) [23].
Queste non sono però le uniche differenze apportate rispetto allo standard JPEG: a causa di questo
i programmi attuali più diffusi (software di grafica, viewer e browser) e l'hardware (ad esempio le
fotocamere digitali) non supportano nativamente il nuovo formato dello standard.
Questo fatto non gioca a favore di JPEG2000 vista l'ampissima diffusione del formato JPEG (oltre
l'80% delle immagini è codificato con lo standard JPEG) per cui il futuro di questo nuovo formato è
ancora molto incerto nonostante le potenzialità che offre.
10
Progetto 3D CloudWiz | ATI NICE - DIEE
Questi i passaggi per la codifica con JPEG2000 lossless:
Passo 1) Preprocessing
Se stiamo comprimendo un'immagine a colori occorre trasformare l'immagine nello spazio
YCbCr e, per ogni canale, sottraiamo 127 ad ogni valore “unsigned” contenuto in esso. In
questo modo avremo una “centratura” dei valori sullo 0.
Passo 2) Trasformazione
Uno dei principali cambiamenti nello standard JPEG2000 è l'uso della Trasformazione
Wavelet Discreta (DWT) invece della DCT. Il risultato di quest’operazione è la decorrelazione
tra le informazioni di bassa e alta frequenza contenute nell’immagine.
La DWT si applica poi ricorsivamente, solitamente 2/3 volte, alla componente delle basse
frequenze. Il risultato finale di tutta l'operazione è che l'intero contenuto informativo
dell'immagine originale è stato segmentato in una serie di trasformazioni successive, che
potranno poi essere compresse in un minimo spazio e poi decompresse in modo
reversibile.
Alla DWT vengono applicati dei filtri per la compressione, nel caso lossless solitamente il
filtro LeGall53 o W5x3. Nel caso lossy i filtri applicati sono differenti.
C'è da fare presente che la complessità della DWT dipende dalla dimensione dei filtri
applicati e dal tipo di filtro. Solitamente essa è computazionalmente più complessa della
DCT e richiede anche una maggiore memoria.
Passo 3) Quantizzazione
Nel caso di codifica lossless non si applica alcun tipo di quantizzazione.
Passo 4) Encoding
Per la compressione senza perdita di dati, usiamo semplicemente la metodologia EBCOT
[24]per codificare gli elementi della trasformazione wavelet.
JPEG XR
JPEG XR [25], precedentemente conosciuto come HD Photo [26], è un formato per la compressione
11
Progetto 3D CloudWiz | ATI NICE - DIEE
delle immagini sviluppato da Microsoft e studiato per superare la limitazione degli 8 bit per canale
del formato JPEG estendendo la profondità del colore a 16 bit o più, supportare un numero
maggiore di di spazi di colore e garantire la possibilità di gestire porzioni di immagine senza dover
decodificare l’intera immagine.
La qualità dell'immagine, percettivamente comparabile a quella del JPEG2000, ha un carico
computazionale più vicino a quello del JPEG offrendo però una compressione superiore anche in
caso di compressione lossless.
L'algoritmo di compressione è molto simile a quello JPEG:
avviene una trasformazione in un differente spazio di colore;
ogni piano di colore viene suddiviso in blocchi di dimensione fissa;
i blocchi vengono trasformati sotto il dominio della frequenza e gli viene applicata una
codifica entropica.
Essendo la trasformazione da RGB a YCbCr leggermente lossy (introduce infatti dei piccoli errori in
fase di arrotondamento), il nuovo standard JPEG XR propone l'adozione della trasformazione dallo
spazio RGB a quello YUV.
La fase di trasformazione nel campo della frequenza avviene su blocchi di dimensioni inferiori e
senza l'utilizzo della trasformata DCT bensì utilizzando, come nel JPEG2000, la DWT (Discrete
Wavelet Transform) utilizzando l'algoritmo con schema “lifting” [27]: esso è un metodo alternativo
per il calcolo dei coefficienti delle wavelet avente un minore costo computazionale e un minore
utilizzo di memoria.
Il vantaggio di questa codifica rispetto a JPEG2000 è il fatto che questa è già supportata dalla gran
parte dei software che utilizzano immagini.
Confronti tra i tre algoritmi precedentemente descritti
In letteratura sono già presenti [28] dei test comparativi tra i tre algoritmi fin'ora trattatati. A puro
titolo d'esempio di seguito vengono riportati brevemente i risultati d'interesse riferiti alle immagini
Lena.bmp, Peppers.bmp, Couple.bmp e Sailboat on Lake.bmp (in alcuni casi si parte da formati
.ppm o .pnm) presenti all'indirizzo http://sipi.usc.edu/database ed utilizzati per avere un PSNR pari
12
Progetto 3D CloudWiz | ATI NICE - DIEE
a 40db (valori in tabella in bpp)
TEST
JPEG-2000
JPEG-XR
JPEG-LS
Lena.bmp
5
4.2
5.5
Peppers.bmp
6.6
6
5.5
Couple.bmp
3.4
3
4.5
Sailboat on Lake.bmp
8
7
6.7
GIF
Il formato GIF (Graphic Interchange Format), diffuso alla fine degli anni 80, usa una forma di
compressione LZW che mantiene inalterata la qualità dell'immagine.
La profondità dei colori delle immagini GIF è di 8 bit, che consente di usare una tavolozza di
massimo 256 colori. Consente inoltre di inserire la trasparenza ad uno dei colori individuati.
Lo schema di compressione LZW è più adatto a comprimere immagini con grossi campi di colore
omogeneo ed è meno efficiente nella compressione di immagini complesse con molti colori e
grane/finiture complesse.
Tale formato è stato superato a partire dal 1995 a causa dello sviluppo del PNG.
PNG
Il formato di codifica PNG [29] (Portable Network Graphics) è un formato grafico di tipo raster
(bitmap) basato sulla compressione deflate. È stato elaborato nel 1995 per fornire un'alternativa
libera al formato GIF per la quale era stato improvvisamente richiesto il pagamento delle royality di
utilizzo.
La compressione proposta con questo formato è una compressione senza perdita (lossless
compression) da 5 a 25% migliore della compressione GIF.
PNG può supportare colori fino a 32 bit. Il formato PNG-8, il primo nato, presenta effettivamente
molte analogie con il formato GIF. Il formato PNG-24 è invece più “simile” a un JPEG e può
supportare la trasparenza anche su più livelli di colore.
Esso possiede solitamente una funzione di intreccio che permette di visualizzare progressivamente
l'immagine.
13
Progetto 3D CloudWiz | ATI NICE - DIEE
La struttura dei file PNG è composta come segue:
una firma in esadecimale del file che identifica il tipo PNG
una serie di chunks dell'immagine
I chunks dell'immagine contengono il contenuto informativo dell'immagine stessa. I più importanti
sono quelli definiti “critical”:
IHDR Image header
PLTE Palette
IDAT Image data
IEND Image trailer
Oltre a questi chunks principali sono poi presenti chunks “accessori”.
I chunks possono essere presenti nel file in qualsiasi ordine ma devono cominciare dal segmento di
titolo (IHDR chunk) e finire dal segmento finale (IEND chunk).
I chunks a loro volta sono suddivisi in quattro parti:
dimensione del chunk, un numero intero di 4 byte
tipo del chunk, un codice di 4 byte di caratteri ASCII alfanumerici che identificano la
tipologia del chunk
i dati del chunk
il CRC (cyclic redundancy check), un codice correttore di 4 byte che permette di verificare
l'integrità del segmento
Di seguito una tabella riepilogativa relativa alla conversione di un'immagine campione che
evidenzia le differenze di compressione tra PNG e le varie compressioni legate al JPEG impostando
la qualità di output pari al 100%.
TEST
BMP
JPEG (Qualità 100%)
JPEG-XR (Qualità 100%) PNG
Butterfly.bmp
668 KB
201 KB
251 KB
267 KB
Questi valori sono stati ottenuti utilizzando il tool di grafica Gimp sulla seguente immagine
14
Progetto 3D CloudWiz | ATI NICE - DIEE
d'esempio avente dimensioni 485x353 reperita gratuitamente sul sito http://pngimg.com/:
Implementazioni multithread di diverso tipo
Come già specificato in fase introduttiva vengono qui di seguito presentati due differenti tools di
compressione, uno specifico per le immagini (ImageZero) e uno più generico (LZ4) che pongono il
loro punto di forza sulla velocità d’esecuzione dell’algoritmo di compressione e decompressione
piuttosto che sui livelli di compressione raggiunti.
Tali performance vengono perseguite adattando gli algoritmi di compressione alle potenze di
calcolo offerte dai moderni processori: in particolare si fa un forte utilizzo del multithreading.
ImageZero
ImageZero [30] nasce nel 2012 da un progetto di Chistoph Feck, sviluppatore di KDE, che ricercava
un codec estremamente veloce, che fosse di tipologia lossless e che offrisse un discreto rapporto di
compressione.
Non avendo trovato quello che cercava ha stabilito di realizzarlo lui stesso. Le piattaforme di
benchmark indipendenti per la valutazione delle prestazioni relative alle procedure di codifica e
decodifica lossless documentano la velocità e la qualità del suo codec [31] [32].
Il codice è attualmente al primo stadio di sviluppo ma è estremamente promettente: rispetto al
PNG comprime un'immagine PPM a 24 bit circa 20 volte più velocemente e la decomprime 2 volte
più velocemente. Il tasso di compressione è estremamente prossimo a quello del PNG.
L'algoritmo utilizzato è molto semplice: la compressione e la decompressione viene realizzata “per
pixel”, senza branches (ad eccezione di un unico branch nel bit coder), in modo che sulle moderne
CPU possa essere eseguito molto velocemente e in parallelo.
Questo tipo di codifica non è adatta per grafici o per immagini in scala di grigi.
15
Progetto 3D CloudWiz | ATI NICE - DIEE
Andando ad utilizzare come immagine campione quella presente all'indirizzo seguente:
http://www.flickr.com/photos/anirudhkoul/3499471010/sizes/o/in/photostream/
questi sono i risultati ottenuti per le varie tipologie di codifica e decodifica:
Metodo
Dimensione del File (KB) Tempo di Compressione (s) Tempo di Decompressione (s)
Originale
46380
-
-
JPEG-LS
14984
6,6
7,3
PNG
16256
42,4
2,4
1,2
1,3
ImageZero 15496
Alcuni interessanti risultati compresi nel “LossLess Photo Compression Benchmark” mostrano i
risultati dei tempi di compressione e decompressione dei sistemi di compressione lossless applicati
su un database di circa 3.46 GB.
Quello che viene evidenziato è che il formato ImageZero, rilasciato con licenza BSD, così come il
codice al quale fa riferimento, è nettamente il codec più veloce e garantisce una notevole velocità
sia di compressione che di decompressione. La tabella seguente fornisce un riepilogo di quanto
emerge.
Software / Codec
Licenza
Dimensione (%)
Compressione (s)
Decompressione (s)
Originale
-
100
-
-
bzip2 -1
bzip2 License
56,3
476
218
PNG
libpng License
42,5
844
72
ImageZero
BSD
41,3
23
21
JPEG-LS
HP License
37,4
107
92
lossless WebP
BSD
35,6
7525
110
Flic
Proprietario
30,0
210
231
Gralic
Proprietario
28,1
1734
1897
16
Progetto 3D CloudWiz | ATI NICE - DIEE
LZ4
LZ4 [33] è un algoritmo di compressione di dati generici, derivante dal filone dei codec LZ77,
particolarmente orientato ad aumentare notevolmente le velocità di compressione e
decompressione.
Attualmente è un progetto presente su google-code [34] e sta avendo un notevole successo in
quanto riesce a garantire velocità di 400MB/s per ogni core dedicato alla compressione.
L'algoritmo è inoltre scalabile con le CPU multi core. I tempi di decompressione ottenuti sono
nell'ordine dei GB/s e raggiungono, nei sistemi multi core, il limite di velocità della ram.
Di seguito, in Tabella 6, viene riportato uno schema comparativo con le performance registrate da
LZ4 rispetto ad altri algoritmi/tools di compressione
Tool
Ratio
Comp. Speed (MB/s)
Decomp. Speed (MB/s)
LZ4 (r101)
2,084
422
1820
LZO 2.06
2,106
414
600
QuickLZ (1.5.1b6)
2,237
373
420
Snappy 1.1.0
2,091
323
1070
LZF
2,077
270
570
Zlib 1.2.8 -6
3,099
21
300
Algoritmi di compressione proposti in letteratura
Di seguito vengono messi in risalto quelli che sembrano essere gli algoritmi di compressione per
immagini più promettenti presenti in letteratura. Il vincolo della ricerca di compressioni lossless (o
near lossless), real time (o near real time) e applicabili a immagini con un contenuto generico ha
portato a un'elevata scrematura dell'offerta scientifica disponibile.
La gran parte degli articoli analizzati è risultata essere non idonea allo scopo del presente
documento. Molte delle pubblicazioni fanno inoltre riferimento a dataset di test non pubblici e/o
comunque di difficile reperibilità o aventi un contenuto molto limitato d'immagini pregiudicando
l'eventuale ripetibilità dei test presentati.
Gli approcci mostrati sono quindi unicamente quelli che presentano delle misure di prestazioni
relative a un dataset di dimensione sufficiente o relative a set di immagini standard.
17
Progetto 3D CloudWiz | ATI NICE - DIEE
A Lossless Image Compression Technique using Location Based Approach
A Lossless Image Compression Technique using Location Based Approach [32] è una tecnica per la
compressione lossless d'immagini basata sulla divisione in blocchi 4x4 dell'immagine originale e in
una loro successiva compressione.
L'algoritmo in oggetto si basa essenzialmente su pochi semplici passi:
1) scomporre l'immagine in blocchi 4x4 non sovrapposti
2) per ogni blocco poi
a) convertire il blocco in un array di 16 elementi con un approccio “da sinistra a destra e
dall'alto in basso”
b) individuare il valore più frequente all'interno dell'array (MFP) e eliminarlo
c) scrivere il valore dell'MFP sul bit stream d'uscita susseguito da 4 bit che indicano il numero
di occorrenze (la frequenza) dell'MFP
d) individuare la frequenza del secondo valore più frequente all'interno dell'array (SMFP): se
occorrono k bit per rappresentare questa frequenza, scrivere k nei successivi 4 bit nel bit
stream d'uscita
e) scrivere quindi il valore dell'SMFP in 8 bit
f) scrivere il numero di occorrenze dell'SMFP
g) scrivere tutte le posizioni delle sue occorrenze in k bit
h) ripetere i passi da e) a g) per tutti i distinti valori di pixel rimasti nell'array
3) ripetere per ogni blocco
per un'immagine a colori occorre ovviamente ripetere l'intero algoritmo per ogni componente di
colore.
Una tabella comparativa dei risultati di compressione, in termini di dimensione dell'immagine in
bit, riportata nell'articolo viene di seguito proposta:
TEST
Non compressa GIF
TIFF
18
PNG
LICTLBA
Progetto 3D CloudWiz | ATI NICE - DIEE
Lena
2097152
443187
521830
387482
252082
Baboon
2097152
654541
535107
501350
196608
Iris
2097152
901120
802816
630784
201583
L'articolo presentato propone un metodo di compressione che sembra dare buoni risultati ma
risulta anomalo il numero ridotto di campioni su cui vengono eseguiti i test. Inoltre esso sembra
presentare dei limiti, ad esempio, il caso in cui tutti i pixel siano diversi comporterebbe un aggravio
in termini di dimensioni dell'immagine, si avrebbero infatti per un singolo blocco 4x4 di un singolo
canale di un'immagine:
8 bit per MFP
bit per la frequenza MFP
4 bit per la rappresentazione di K
8 bit per SMFP
1 bit per la frequenza di SMFP
4 bit per la posizione di SMFP
(8 + 1 + 4)*14 = 182 bit per i restanti valori dei pixel
per un totale di 211 bit di un blocco compresso contro 128 bit del blocco non compresso. L'articolo
stesso specifica però che nei blocchi di test 4x4 analizzati, circa 100.000, solo in una piccola parte
di questi, 79, si è verificato il caso peggiore precedentemente indicato.
Context-based Dictionary Image Compression
Il Context-based Dictionary Image Compression (CDIC) [33] è un algoritmo proposto nel 2012 e che
propone l'applicazione di tecniche di compressione di dati testuali anche nel campo delle
immagini.
In particolare la tecnica di compressione da applicare alle immagini è quella proposta da Nakano e
altri [34] nel 1994, il Classifying to Sub-Dictionaries (CSD), che propone l'idea di combinare
tecniche di compressione basate su dizionari a tecniche di compressione basate sul contesto dei
19
Progetto 3D CloudWiz | ATI NICE - DIEE
dati: in particolare combinando la compressione Lempel-Ziv-Welch (LZW) con lo schema Prediction
by Partial Matching (PPM).
L'algoritmo in questione utilizza un numero elevato di sottodizionari che sono inizialmente presi in
considerazione con tutti i possibili singoli caratteri.
Ogni stringa da codificare viene codificata in base all'ultimo simbolo presente nella precedente
sotto stringa che viene associato al dizionario secondario da utilizzare. Una volta individuato il
dizionario, si utilizza l'algoritmo LZW per la compressione dei dati.
Utilizzando sempre l'ultimo elemento per la codifica di una stringa successiva, viene considerato
[35] come uno schema PPM del primo ordine.
L'applicazione del CSD alle immagini bidimensionali è stata testata e confrontata con le prestazioni
offerte dalla semplice compressione LZW. Per completezza di analisi, per la predizione del corretto
sotto dizionario da andare a utilizzare, sono stati effettuati due differenti test: in un caso veniva
sfruttato il valore del pixel a sinistra, mentre in un secondo caso il valore del pixel superiore.
Quello che viene evidenziato dai test condotti su 9 immagini standard è che mediamente la
codifica LZW riduce lo spazio occupato del 14%, mentre con la codifica CSD si può arrivare fino al
17%. I risultati pubblicati non sono entusiasmanti in termini di compressione anche perché, come
nella maggior parte dei casi, non vengono riportati i tempi di codifica e decodifica delle immagini.
Nella tabella a seguire vengono riportati i risultati ottenuti dai test svolti da El-Sakka dove i valori
sono da intendersi in byte.
TEST
Non Compressa
LZW
CSD (Pixel sinistro)
CSD (Pixel Superiore)
Boats
103680
91183
87215
88816
Camera
65536
54720
51106
52325
Columbia
57600
52350
49666
50845
Crowd
262144
196955
188488
190171
Lake
262144
243225
235806
237016
20
Progetto 3D CloudWiz | ATI NICE - DIEE
Man
262144
227473
220547
212930
Milkdrop
65536
55368
54290
53992
Peppers
65536
64423
63008
62515
Plane
65536
56218
53928
54840
A new Algorithm for Lossless Compression applied to two-dimensional Static Images
A new Algorithm for Lossless Compression applied to two-dimensional Static Images (ALCSI) [36] è
stato proposto nel 2012 e prevede l'utilizzo di una tecnica ibrida per la compressione delle
immagini che sfrutta i concetti introdotti dall'algoritmo INA [37] per la parallelizzazione del
processo.
I risultati sperimentali del metodo INA, dello stesso autore, evidenziano come il metodo indicato
abbia performance superiori alla codifica di Huffman e al JPEG-LS, di seguito un breve schema
riassuntivo nella tabella seguente relativo alla compressione di un'immagine 2048x2048 in cui la
compressione, per il metodo INA è stata ottenuta in 0.105 secondi:
METHODS
COMPRESSION RATIOS
Huffman Coding
4%
Prediction
27%
JPEG-LS (Standard)
54%
INA
58%
Il metodo si compone di tre fasi: una prima fase di segmentazione dell'immagine, una seconda fase
di compressione e una terza di codifica.
Nella prima fase, l'intera immagine viene suddivisa in blocchi di dimensione fissa: ogni blocco
genera due gruppi distinti. Un primo gruppo che identifica la sequenza dei pixel del blocco ordinati
in ordine crescente e l'altro che rappresenta una sequenza formata da pixel organizzati in gruppi di
coppie ordinate. I vantaggi apportati dalla segmentazione dell'immagine, tipicamente in blocchi di
21
Progetto 3D CloudWiz | ATI NICE - DIEE
dimensione 4x4, sono essenzialmente riconducibili all'aumento in termini di velocità, alla riduzione
della memoria richiesta e all'adattamento dei dati stessi per l'utilizzo nell'albero binario.
La seconda fase, quella di compressione, è la novità apportata da questo metodo e si riferisce
all'esecuzione parallela della compressione dei due gruppi ottenuti nella prima fase di
segmentazione tramite l'utilizzo di un albero binario e uno schema di predizione.
Nella terza ed ultima fase viene applicato un codificatore per la generazione del bit stream d'uscita.
I risultati sperimentali pubblicati nella tabella seguente legati a questo metodo sono stati dei lievi
miglioramenti nelle misure del rapporto di compressione e dei bit per punto rispetto al JPEG-LS.
METHODS
COMPRESSION RATIOS
BPP
Methods based on Substitution models
1,03
7,79
Methods based on Arithmetic models
1,11
7,21
Methods based on Dictionary models
1,23
6,53
Methods based on Predictive models
1,57
5,09
Methods based on Transformed models
1,76
4,54
JPEG-LS Standard
1,75
4,57
ALCSI
1,77
4,52
Fast Lossless Color Image Compressing Method Using Neural Network
L'approccio mostrato nel 2002 con la pubblicazione “Fast Lossless Color Image Compressing
Method Using Neural Network” [38] mira a rinunciare alle prestazioni in termini di compressione
per andare invece a migliorare i tempi di compressione dei dati dell'immagine.
Gli autori propongono un algoritmo di tipo predittivo che consta di tre fasi.
Nella prima fase si procede a una trasformazione dello spazio di colore: seguendo gli esempi di
JPEG-LS e JPEG2000 gli autori propongono un loro nuovo spazio di colore. Partendo dalle
componenti originali (denominate genericamente A1, A2 e A3) si ottengono le nuove componenti
secondo queste equazioni:
A1' = floor (0.25A1 + 0.5A2 + 0.25A3)
22
Progetto 3D CloudWiz | ATI NICE - DIEE
A2' = A1 - A2
A3' = A3 - A2
la trasformazione è ovviamente reversibile.
Nella seconda fase si applica invece un modello predittivo: il valore del pixel è predetto pesando i
valori dei quattro pixel in direzione in alto a sinistra. Se il pixel d'interesse è nella prima o
nell'ultima colonna o se è nella prima riga, si utilizza un valore di default per il pixel vicino
mancante. Il pixel k-simo in posizione (i,j) sarà calcolato come:
Pk(i,j) = w1Pk(i,j-1) + w2Pk(i-1,j-1) + w3Pk(i-1,j) +w4Pk(i-1,j+1)
dove i generici w inizialmente assumeranno il valore 0.25.
Nella terza fase viene invece utilizzato una correzione adattativa dei singoli pesi in base
all'algoritmo riportato in [39] attraverso l'utilizzo di una rete neurale a due livelli.
I risultati ottenuti da questo metodo indicano che con questo metodo è possibile ottenere una
compressione nettamente superiore che con il solo utilizzo dei metodi di Huffman o Lzw. Si ottiene
inoltre un rapporto di compressione un po' peggiore rispetto a JPEG-LS ma si riesce, con l'utilizzo
della metodologia proposta, a migliorare i tempi di compressione dell'immagine stessa.
Di seguito sono mostrate due tabelle che riassumono tali prestazioni. Nella prima si fa riferimento
al numero medio di bits per codificare ogni pixel, nella seconda vengono indicati i tempi di
compressione ottenuti per le immagini di test.
I risultati di compressione vengono proposti in termini di bits/pixel:
Image
Huffman
LZW
JPEG-LS
Proposed
Scenery1
2,92
5,01
2,13
2,20
Scenery2
2,27
4,20
1,83
1,89
Aerial
2,65
3,92
1,90
2,22
Computer's
2,47
3,08
2,21
2,55
Peppers
4,67
5,84
3,88
4,28
23
Progetto 3D CloudWiz | ATI NICE - DIEE
Lena
5,12
6,78
4,52
4,76
I tempi di compressione, in termini di secondi, vengono riportati nella seguente tabella:
Image
Huffman
LZW
JPEG-LS
Proposed
Scenery1
6,88
9,87
6,21
5,10
Scenery2
9,35
13,32
8,68
7,27
Aerial
6,83
7,90
6,62
5,55
Computer's
5,24
8,68
4,46
3,89
Peppers
1,18
3,12
0,60
0,51
Lena
2,87
3,89
1,05
0,90
Conclusioni
La letteratura scientifica, in relazione a codec lossless o near lossless che possano essere utilizzati
in real time o in near real time, risulta essere limitata.
Negli ultimi anni la comunità scientifica si è concentrata infatti ad affrontare le problematiche
relative alla compressione e decompressione d'immagini seguendo gli andamenti del mercato: si è
manifestata infatti una proliferazione di studi su specifiche tipologie d'immagine a discapito di
studi legati a immagini generiche (in formato RGB o BGR).
Ad esempio si riscontrano un numero elevato di studi legati alle immagini realizzate secondo il
criterio Bayer CFA [40-42], specifico in particolare per immagini fotografiche ad elevata risoluzione
e dipendente dai filtri implementati nelle fotocamere, come mostrato dagli studi in corso anche in
aziende come Microsoft [43]; si ha anche la ricerca di nuove tecniche di codifica legato a immagini
di tipo medicale [44,45], legato alle immagini astronomiche [46] o più genericamente alle
24
Progetto 3D CloudWiz | ATI NICE - DIEE
tematiche del compound image compression [47,48].
Quello che viene evidenziato è che gli algoritmi e i formati di compressione già presenti sul
mercato (JPEG XR, PNG ecc) sono attualmente considerati stabili e affidabili. Le prestazioni che essi
offrono vengono valutate sufficienti per l'esigenza attualmente manifestata dal mercato: essi
risultano offrire rapporti di compressione molto buoni, superati solo minimamente dai nuovi
algoritmi presentati in letteratura, e tempi di compressione ragionevoli per le più diffuse
applicazioni.
Quello che si evidenzia è inoltre la presenza di una serie di studi e implementazioni che mirano ad
utilizzare le codifiche dati ritenute standard (Huffman, LZ78 ecc) parallelizzandone però il processo
ed adattando quindi queste tecniche al multi threading offerto dai processori oppure andando ad
implementare i medesimi algoritmi al fine di utilizzare la potenza di calcolo presente nella GPU del
sistema.
Ovviamente tali soluzioni non migliorano il rapporto di compressione offerto dagli algoritmi ma si
limitano a migliorare i tempi legati alla compressione e decompressione dei dati.
Bibliografia
1. «http://math.unipa.it/~epifanio/tecnologie/compr07_08.pdf,» [Online].
2. M. Burrows e D. Wheeler, «A block sorting lossless data compression algorithm».
3. «http://compressions.sourceforge.net/PPM.html,» [Online].
4. «http://tools.ietf.org/html/rfc1951,» [Online].
5. D. Huffman, «A method for the construction of minumum-redundancy codes».
6. P. E. Black, «Adaptive Huffman coding,» in Dictionary of Algorithms and Data Structures.
7. P. E. Black, «K-ary Huffman coding,» in Dictionary of Algorithms and Data Structures.
8. M. Golin, C. Kenyon e N. Y. Young, «Huffman Coding with Unequal Letter Costs».
9. I. Witten, R. Neal e J. Cleary, «Arithmetic Coding for Data Compression».
10. J. Ziv e A. Lempel, «A Universal Algorithm for Sequential Data Compression».
11. J. Ziv e A. Lempel, «Compression of Individual Sequences via Variable-Rate Coding».
25
Progetto 3D CloudWiz | ATI NICE - DIEE
12. D. Salomon, «Data Compression: The Complete Reference».
13. J. Storer e T. Szymansky, «Data Compression via Textual Substituion».
14. T. Welch, «A Technique for High-Performance Data Compression».
15. «http://tools.ietf.org/html/rfc1951,» [Online].
16. M. Weinberger, G. Seroussi e G. Sapiro, «The LOCO-I Lossless Image Compression
Algorithm: Principles and Standardization into JPEG-LS».
17. «http://www.hpl.hp.com/research/info_theory/loco/HPL-98-193R1.pdf,» [Online].
18. M. Charrier, D. Santa Cruz e M. Larsson, «JPEG2000, the Next Millenium Compression
Standard for Still Images».
19. «http://www.jpeg.org/jpeg2000/,» [Online].
20. D. Taubman e M. Marcelin, «JPEG2000: Image Compression Fundamentals, Standards and
Practice».
21. AA.VV., «http://www.hpl.hp.com/techreports/2001/HPL-2001-35.pdf,» [Online].
22. AA.VV., «Recommendation T.832 /03/2009, updated 12/2009: Information Technology –
JPEG XR image coding system – Part 2: Image coding specification».
23. AA.VV., «HD Photo: a New Image Coding Technology for Digital Photography».
24. «http://www.dsi.unifi.it/~berretti/download/jpeg-2000.pdf,» [Online].
25. A. Solanki, «Implementation and performance analysis of JPEG2000, JPEG, JPEG-LS, JPEGXR and H.264/AVC Intra frame coding,» [Online].
26. «http://www.ietf.org/rfc/rfc2083.txt?number=2083,» [Online].
27. «http://imagezero.maxiom.de/,» [Online].
28. http://www.squeezechart.com/bitmap.html. [Online].
29. «http://www.imagecompression.info/gralic/LPCB.html,» [Online].
30. «http://fastcompression.blogspot.it/2011/05/lz4-explained.html,» [Online].
31. «https://code.google.com/p/lz4,» [Online].
26
Progetto 3D CloudWiz | ATI NICE - DIEE
32. M. Hasan e K. M. Nur, «A Lossless Image Compression Technique using Location Based
Approach».
33. M. El-Sakka, «Context-based Dictionary Image Compression».
34. AA.VV., «Highly efficient universal coding with classifying to subdictionaries for text
compression».
35. J. Cleary e W. Teahan, «Unbounded length contexts for PPM».
36. J. Larrauri, «A new Algorithm for Lossless Compression applied to two-dimensional Static
Images».
37. J. Larrauri e E. Kahoraho, «A new Method for Real Time Lossless Image Compression
Applied to Artificial Vision».
38. K. Jia, S. Fang e S. Dun, «Fast Lossless Color Image Compressing Method Using Neural
Network».
39. J. Zurada, «Introduction to Artificial Neural System».
40. «http://www.google.it/patents/US3971065,» [Online].
41. K. Chung e Y. Chan, «A Lossless Compression Scheme for Bayer Color Filter Array Images».
42. C. Koh, J. Mukherjee e S. Mitra, «New Efficient Methods of Image Compression in Digital
Cameras with Color Filter Array».
43. H. Malvar e G. Sullivan, «Progressive-to-Lossless Compression of Color-Filter-Array Images
using Macropixel Spectral-Spatial Transformation».
44. C. Flint, «Determining optimal medical image compression: psycometric and image
distortion analysis».
45. J. Janet, D. Mohandass e S. Meenalosini, «Lossless Compression Techniques for Medical
Images in Telemedicine».
46. AA.VV., «Astronomical Image Compression Based on Noise Suppression».
47. T. Lin e P. Hao, «Compound Image Compression for Real-Time Computer Screen Image
Transmission».
27
Progetto 3D CloudWiz | ATI NICE - DIEE
48. AA.VV., «Block-based Fast Compression for Compound Images».
49. C. Taskin e S. Sarikoz, «An Overview of Image Compression Approaches».
50. H. Cai e J. Li, «Lossless Image Compression with Tree Coding of Magnitude Levels».
51. B. Aiazzi, S. Baronti e L. Alparone, «Near Lossless Image Compression By Relaxation Labeled
Prediction».
52. B. Aiazzi, S. Baronti e L. Alparone, «Lossless Image Compression Based on a Fuzzy-Clustered
Prediction».
53. S. Qian, A. Hollinger e Y. Hamiaux, «Study of Real Time Lossless Data Compression for
Hyperspectral Imagery».
54. M. Ciavarella e A. Moffat, «Lossless Image Compression Using Pixel Reordering».
55. AA.VV., «Lossless Image Compression».
56. M. Bhammar e K. Mehta, «Survey of Various Image Compression Techniques».
57. M. Groach e A. Garg, «DCSPIHT: Image Compression Algorithm».
58. M. Ashok e T. Reddy, «Color image compression based on Luminance and Chrominance
using Binary Wavelet Transform and Binary Plane Technique».
59. N. Salam e R. Nair, «An Optimized Real Time Image Codec for Image Data Transmission and
Storage».
60. A. Kaushik e M. Gupta, «Analysis of Image Compression Algorithms».
61. M. Allam e E. Abdel-Ghaffar, «JPEG2000 Performance Evaluation».
28
Progetto 3D CloudWiz | ATI NICE - DIEE
Compressione di immagini generiche a contenuto eterogeneo (compound
images)
Gli algoritmi di compressione illustrati finora applicano lo stesso algoritmo di compressione su
tutto il dato. Questi però, non sono ottimali però nell'applicazione verso le compound image.
Queste ultime sono immagini a contenuto eterogeneo ovvero possono essere composte da diverse
aree contenenti testo, immagini grafiche o fotografie naturali. Due tipici esempi di compound
image sono l'immagine visualizzata nello schermo di un computer ed il sito web di un giornale,
nella figura seguente viene mostrato un semplice esempio.
La compressione di una compound image si basa sul fatto che vengano individuate le varie
29
Progetto 3D CloudWiz | ATI NICE - DIEE
componenti/classi che compongono l'immagine, le quali verranno codificate separatamente
tramite un apposito algoritmo di compressione, differente per ciascuna componente/classe.
Nella prossima sezione verranno presentati i principali approcci proposti in letteratura per
compiere la segmentazione delle compound image.
Metodi di segmentazione delle componenti di un'immagine
Come accennato poco sopra, il primo step da effettuare nella compressione delle compound
image è la classificazione dell'immagine, ovvero l'individuazione di tutte le componenti che
costituiscono la compound image. In relazione a tale classificazione esistono numerosi approcci di
cui i più utilizzati sono i seguenti:
Approccio a oggetti
Approccio a layer
Approccio a blocchi
Approccio ibrido
Approccio ad oggetti
L’approccio a oggetti si propone di suddividere l’immagine in regioni, a loro volta divisibili in oggetti
caratterizzati da bordi perfettamente definiti. Gli oggetti possono essere lettere, fotografie o
elementi grafici. Questo approccio dovrebbe offrire un ottimo rapporto di compressione, in quanto
una volta selezionato correttamente l’oggetto, esso può essere compresso con l’esatto algoritmo
adatto al caso, senza considerare casi in cui la segmentazione non avvenga correttamente. In
pratica la codifica dei bordi delle oggetti risulta essere piuttosto complessa, rendendo poco
vantaggioso questo metodo in quanto fortemente dipendente dallo stato dell'arte attuale delle
tecniche di segmentazione automatica.
Approccio a layer
In questo approccio l'immagine composita viene suddivisa in piani contenenti delle porzioni
dell'immagine di partenza. La ricostruzione avviene attraverso degli layer specifici detti maschere.
Dal punto di vista teorico l'immagine composita può essere suddivisa in un numero di layer che
può dipendere dalla specifica applicazione. Uno dei metodi più diffusi è quello del Mixed raster
30
Progetto 3D CloudWiz | ATI NICE - DIEE
content (MRC) [1] nel quale l'immagine di partenza viene suddivisa nei seguenti layer:
1) Foreground
2) Mask
3) Background
Un semplice esempio può chiarire come viene suddivisa l'immagine composita e come viene
ricostruita nella figura successiva, dove abbiamo un'immagine contenente una porzione di testo di
colore rosa e un'immagine pittorica nella fattispecie un fiore bianco.
Queste tipologie di contenuto sono inserite in uno sfondo azzurro, secondo l'approccio MRC
l'immagine viene suddivisa in tre piani: il primo strato di foreground è costituito da un piano di
colore rosa che quindi conserva l'informazione relativa al colore delle parti di testo.
Esempio di approccio MRC
La maschera è costituita invece da un piano di sfondo bianco con un testo di colore nero che quindi
conserva l'informazione relativa al testo contenuto nell'immagine di partenza. Infine lo strato dello
sfondo è costituito da un piano di colore azzurro nel quale è inserita la componente pittorica, di
conseguenza tale strato conserva l'informazione relativa alla parte pittorica e allo sfondo.
I tre layer ottenuti possono essere quindi compressi separatamente e la ricostruzione può essere
effettuata attraverso la seguente relazione:
I(i, j) = Msk(i, j)FG(i, j) + (1 − Msk(i, j))BG(i, j)
Dove Msk è la maschera contenente il testo mentre FG e BG sono rispettivamente il background e
il foreground.
31
Progetto 3D CloudWiz | ATI NICE - DIEE
La particolare scelta di assimilare l'informazione del colore dello sfondo con la componente
derivante dalle immagini pittoriche deriva dal fatto che la compressione di tali tipologie di
contenuto può avvenire impiegando un singolo compressore.
E' importante soffermarsi su questo aspetto in quanto l'adattamento tra la tipologia di contenuto
del singolo strato ed il metodo di compressione da utilizzare per codificarlo risulta fondamentale in
questo metodo.. In particolare lo scarso adattamento tra metodo di compressione e tipo di dato
gestito può comprometterne l'efficacia, infatti a seconda della stratificazione adottata può capitare
che oggetti di tipo diverso possano risiedere nel medesimo strato che viene compresso attraverso
un singolo metodo di compressione che di fatto risulterà efficace sulla gestione di un solo tipo di
contenuto.
Risulta quindi importante scomporre l'immagine in tipologie di contenuto aventi caratteristiche tali
da sfruttare al meglio le peculiarità dei diversi algoritmi di compressione a disposizione, senza
dimenticare che abbiamo un grado di libertà derivante dalla possibilità di adottare una
stratificazione più o meno profonda. Tale stratificazione ci consente di gestire il giusto contenuto
col giusto metodo di compressione ma va comunque considerato che una suddivisione
dell'immagine di partenza in un numero eccessivo di layer incrementa la complessità e acuisce un
altro aspetto derivante dal fatto che aumentare a dismisura il numero di layer aumenta anche la
ridondanza derivante dalla presenza simultanea di componenti dell'immagine originale in layer
diversi .
Approccio a blocchi
Nella classificazione a blocchi l'immagine di partenza viene analizzata in blocchi di dimensioni
prefissata. Ciascun blocco componente conterrà al suo interno dei punti appartenenti a: testo,
immagini e componenti grafiche.
Quindi ciascun blocco subisce un processo di classificazione nel quale ciascun pixel viene assegnato
ad una tipologia specifica di contenuto. Tale metodo di classificazione ha quindi l'obbiettivo di
identificare le diverse regioni che costituiscono l'immagine composita.
In figura viene mostrato un semplice esempio nel quale si vede chiaramente come l'obbiettivo
della segmentazione sia quello di identificare e separare le regioni dell'immagine di partenza in
32
Progetto 3D CloudWiz | ATI NICE - DIEE
base al contenuto.
Esempio di approccio a blocchi
La conseguenza diretta di tale classificazione è la possibilità di comprimere ciascun tipo di
contenuto con un metodo di compressione specifico consentendo una buona conservazione del
contenuto informativo di partenza. In modo più specifico la classificazione a blocchi ha il vantaggio
di presentare dei metodi di segmentazione tipicamente poco complessi e un buon adattamento tra
metodo di compressione e contenuto gestito.
Lo svantaggio fondamentale risiede nella decomposizione dell'immagine di partenza in blocchi che
non presentano una forma rettangolare e che di conseguenza non consento l'utilizzo di metodi
compressione standard, che tipicamente sono studiati per gestire immagini rettangolari, a meno di
apportare delle modifiche per questo metodo specifico.
Il metodo di classificazione a blocchi rappresenta una buona scelta quando si vogliano costruire dei
compressori, per immagini composite, a bassa complessità.
Approccio ibrido
I metodi di classificazione basati sull'uso congiunto del metodo a blocchi e di quello a layer
risultano relativamente recenti.
Un esempio di approccio ibrido è quello proposto in [2]. Il metodo consiste in un primo passo di
classificazione dell'immagine secondo l'approccio a blocchi, in particolare i blocchi vengono
classificati in:
Sfondo
33
Progetto 3D CloudWiz | ATI NICE - DIEE
Testo
Grafica
Immagini pittoriche
Contenuto misto (overlap)
I blocchi con contenuto misto subiscono un processamento secondo il modello a layer. La sfida
maggiore è ovviamente quella derivante dal blocco di sovrapposizione per il fatto che contiene
contenuti differenti e, quindi, risulta più complessa la gestione in fase di compressione. In
definitiva, tale metodo accomuna le caratteristiche salienti dei metodi di classificazione che lo
compongono e di fatto può rappresentare un miglioramento rispetto a singoli approcci.
Algoritmi proposti in letteratura
In questa sezione verranno mostrate delle applicazioni in relazione ai metodi di segmentazione
analizzati nella precedente sezione, in particolare si cercherà di dare una valutazione di ciascun
metodo in modo da collocarlo in uno specifico ambito applicativo.
Metodi a blocchi
Per prima cosa analizzeremo i metodi proposti in [3], [4] e [5] nei quali viene applicata la
classificazione a blocchi. L’approccio consiste nella suddivisione dell’immagine in un elevato
numero di blocchi rettangolari, i quali verranno quindi singolarmente valutati e classificati come
blocchi di testo, blocchi grafici o blocchi contenenti un’immagine naturale. Il processo di
classificazione dei blocchi viene generalmente svolto utilizzando tre metodi:
Conteggio dei colori
DCT (Discrete cosine transform)
Istogramma
Shape primitive extraction and coding
L'approccio proposto nel 2005 da Tony Lin et al. [3] sfrutta l'analisi a blocchi ed un nuovo
algoritmo chiamato SPEC (Shape primitive extraction and coding). In particolar modo il sistema
ottiene una segmentazione iniziale effettuando il conteggio dei colori in blocchi di 16x16 pixel, e
classificando preliminarmente i blocchi come blocchi di testo o grafici nel caso in cui il numero dei
34
Progetto 3D CloudWiz | ATI NICE - DIEE
colori sia minore di una soglia T1 (gli autori utilizzano 32 come soglia), in caso contrario, il blocco
verrà classificato come blocco fotografico. Viene quindi generato un indice di un byte che viene
associato ai blocchi di testo o grafici. Questa classificazione preliminare risulta essere
estremamente rapida, nonostante alcuni blocchi pittorici siano talvolta catalogati come blocchi
grafici e viceversa. Per questo motivo viene effettuata una seconda segmentazione di rifinitura, in
cui verranno separati i blocchi testuali o grafici erroneamente classificati come blocchi pittorici.
Non viene effettuata la rifinitura per blocchi pittorici classificati come testi, poiché essi non sono
normalmente numerosi, e si tratterebbe solo di una perdita di prezioso tempo computazionale. I
blocchi di tipo testuale/grafico vengono quindi analizzati tramite lo SPEC, algoritmo che consente
di rilevare forme caratterizzate dallo stesso colore. Queste forme verranno analizzate in termini di
grandezza e colore per rilevare possibili elementi testuali o grafici e spostarli quindi fra i blocchi
appositi.
Il seguente schema a blocchi riassume il funzionamento dell’algoritmo SPEC.
35
Progetto 3D CloudWiz | ATI NICE - DIEE
I risultati ottenuti da questo algoritmo sono interessanti, sia in termini di tempo impiegato a
comprimere e decomprimere le immagini, sia in termini di grandezza del file compresso e di
qualità secondo quanto riportato nell’articolo. Due tabelle sono riportate per illustrare i risultati
ottenuti su dieci “Compound Image”.
Per dimostrare la qualità visiva ottenuta dall’algoritmo SPEC viene inoltre riportato nella prossima
figura un paragone fra un’immagine compressa tramite lo SPEC e diversi altri algoritmi.
36
Progetto 3D CloudWiz | ATI NICE - DIEE
Porzione dell'immagine originale (a), compressa tramite JPEG (b), JPEG-2000 (c), DjVu (d), SPEC (e). [3]
Improved block based segmentation and compression techniques for Compound Images
L'approccio presentato in [4] esegue un'analisi a blocchi basata sulla DCT. In particolare una volta
divisa l’immagine in blocchi, viene effettuata la trasformata su ogni blocco singolarmente, e viene
calcolata una variabile chiamata energia dei coefficienti AC (alternate current) nel seguente modo:
37
Progetto 3D CloudWiz | ATI NICE - DIEE
Dove Ys,i è il coefficiente AC del blocco i-esimo. Una volta calcolato tale valore, se esso dovesse
essere minore di una certa soglia, il blocco viene classificato come blocco “regolare”, ovvero un
blocco in cui è presente lo sfondo dell’immagine. Viceversa, il blocco sarà considerato “non
regolare”, e tramite un seguente procedimento di clustering può essere classificato come blocco di
testo/grafico o blocco immagine.
Block-based fast compression for Compound Images
Un metodo, basato su istogramma, è stato proposto da WenpengDing et al. [5] e viene definito BFC
(Block-based fast compression). Anche in questo metodo l’immagine viene suddivisa in blocchi da
16x16 pixel, i quali vengono poi processati per fornire un istogramma raffigurante il gradiente dei
pixel del blocco. In particolar modo, i gradienti vengono suddivisi in base al loro modulo fra “lowgradient”, “mid-gradient” e “high-gradient”.
Un esempio è illustrato nella seguente figura:
Esempio di istogramma di blocco di testo[sinistra], blocco immagine [centro] e blocco ibrido [destra].
Una volta calcolati gli istogrammi, i blocchi potranno essere suddivisi in quattro categorie: blocchi
“regolari”, blocchi di testo, blocchi immagine e blocchi ibridi. Nel caso dei blocchi “regolari”,
l’istogramma sarà caratterizzato principalmente da “low-gradient”. I blocchi di testo avranno dei
picchi nel “low-gradient” e nel “high-gradient”, quelli immagine avranno alti valori di “mediumgradient” e “low-gradient”, mentre i blocchi ibridi avranno entrambe le caratteristiche dei blocchi
di testo e dei blocchi immagine. Una volta classificati i blocchi, essi vengono compressi tramite un
algoritmo specifico asseconda del tipo di blocco. Per quanto riguarda i blocchi “regolari”, essi sono
caratterizzati normalmente da un colore che compare con maggior frequenza, il quale viene
38
Progetto 3D CloudWiz | ATI NICE - DIEE
codificato aritmeticamente, e che riempirà il blocco. Nei blocchi di testo vengono invece rilevati i
quattro colori più frequenti, ed allo stesso modo vengono codificati aritmeticamente, riportando
gli altri pixel con simile colore ad essi. I blocchi immagine vengono compressi tramite JPEG, mentre
quelli ibridi richiedono un algoritmo specifico basato sulla wavelet di Haar, i cui coefficienti
vengono poi compressi algoritmicamente. I rapporti di compressione ottenuti da questo metodo
sono molto elevati, e decisamente migliori di altri algoritmi tradizionali, non adatti alle “Compound
image”. Nella seguente tabella sono riportati i risultati ottenuti dagli autori in termini di fattore di
compressione.
Paragone fra il metodo proposto ed altri metodi di compressione tradizionali. [5]
Metodi a layer
Il metodo proposto in [6], A Layer-based Segmentation Method for Compound Images , si basa
sull'applicazione di filtri per immagini e di operatori morfologici con lo scopo di estrarre il testo
contenuto in immagini composite, in particolare il metodo è concepito per estrarre il testo da
scansioni o riviste.
A tale scopo viene impiegato il metodo MRC (MixedContentRaster), descritto nei paragrafi
introduttivi di questa relazione, che estrae il testo contenuto nell'immagine di partenza
separandola in tre layer: background, foreground e text mask.
I passaggi essenziali effettuati dal metodo per estrarre i tre layer sono i seguenti:
1. L'immagine di partenza viene convertita in scala di grigi.
2. Viene applicato un filtro di Wiener per eliminare rumore di fondo (caso tipico delle
scansioni).
3. Applicazione all'immagine di partenza del binarizzatore di Sauvola che mette in risalto il
39
Progetto 3D CloudWiz | ATI NICE - DIEE
testo.
4. Applicazione all'immagine di partenza dell'operatore di Prewitt che cattura i bordi delle
lettere per ottenere le regioni in cui si trova il testo.
5. Viene applicata un'operazione di dilatazione per aumentare le dimensioni delle aree nel
quale è situato il testo.
6. Vengono applicate delle regole tese ad eliminare aree erroneamente classificate come
testo.
7. Si svolge un'operazione di AND tra l'immagine al punto 3 e quella al punto 6 per estrarre
la maschera di testo.
8. L'immagine ottenuta al punto 7 subisce una closing.
9. L'immagine al punto 8 subisce un ulteriore processo di filtraggio analogo a quello eseguito
al punto 6.
10. L'immagine al punto 9 viene posta in AND con quella del punto 3 per riestrarre il testo.
11. Viene infine applicato un algoritmo di riempimento.
In viene mostrato lo schema di principio dell'algoritmo.
Le capacità di classificazione dell’algoritmo sono state valutate in [6] in termini di recall e precision:
Il primo indice (recall rate) rappresenta il tasso di testo rilevato correttamente fra quello presente
40
Progetto 3D CloudWiz | ATI NICE - DIEE
nelle immagine. Il secondo indice (precision rate) invece rappresenta il tasso di testo rilevato
correttamente fra tutto il testo identificato dall’algoritmo . In tabella viene mostrato un estratto
delle prestazioni dell'algoritmo proposto comparato col metodo DjVu in relazione agli indici
qualitativi.
L'algoritmo mostra delle prestazioni paragonabili al metodo allo stato dell'arte DjVu. Il metodo
proposto può essere collocato probabilmente in ambiti applicativi dove non risulta stringente la
specifica sulla velocità di calcolo e dove possa comunque essere gestita una complessità
computazionale elevata derivante dai numerosi passi che l'algoritmo compie per effettuare la
classificazione.
Metodi ibridi
Come esempio di metodo imbrido viene di seguito riportato l'approccio proposto in [2]: Enhanced
Hybrid Compound Image Compression Algorithm Combining Block and Layerbased segmentation.
Il metodo può essere descritto in due passi fondamentali. Nel primo passo i blocchi di immagini
vengono classificati in cinque classi fondamentali secondo l'approccio a blocchi.
Le cinque classi sono le seguenti:
Sfondo
Testo
Grafica
Immagini pittoriche
Contenuto misto (overlap)
Lo schema di segmentazione può essere rappresentato attraverso il seguente schema a blocchi.
41
Progetto 3D CloudWiz | ATI NICE - DIEE
Il blocco di overlap che presenta caratteristiche ibride, ossia contiene testo e immagini che la
segmentazione non ha separato, viene a sua volta processato attraverso il metodo di
classificazione a layer impiegando lo schema classico a tre livelli proposto in [1].
Lo schema di segmentazione applicato per i blocchi di overlap può essere rappresentato dal
seguente schema.
Il metodo ibrido è stato valutato in base alle seguenti metriche di prestazione:
Rapporto di compressione
Tempo di compressione /decompressione
Rapporto segnale rumore di picco
Di seguito mostriamo un estratto dei risultati ottenuti dall'algoritmo proposto.
Nella prima tabella viene mostrata la prestazione in termini di rapporto di compressione.
42
Progetto 3D CloudWiz | ATI NICE - DIEE
Si nota come il metodo proposto (Model 2) abbia prestazioni paragonabili se non superiori agli altri
metodi.
Nella seguente tabella viene mostrata la prestazione del metodo in relazione al rapporto segnale
rumore di picco. I valori ottenuti sono decisamente in linea con quelli degli altri algoritmi.
Nella seguente tabella viene mostrata la valutazione dell'algoritmo in termini di tempi di
compressione e decompressione. E' evidente che il metodo di compressione proposto presenta dei
tempi di compressione/decompressione paragonabili agli altri metodi presi in considerazione.
Tali valori vanno analizzati in relazione alla qualità visiva e in particolare possiamo notare che a
parità di tempi di calcolo il metodo proposto produce dei buoni risultati soprattutto in termini di
rapporto segnale rumore di picco.
43
Progetto 3D CloudWiz | ATI NICE - DIEE
In definitiva possiamo dire che il metodo presenta delle prestazioni significative che gli consentono
di essere impiegata efficacemente nell'ambito della compressione delle immagini composite.
Conclusioni
In questa sezione sono stati analizzati i principali metodi presenti in letteratura inerenti la
compressione delle compound image.
Risulta impossibile effettuare una comparativa accurata di tutti i metodi dato che ogni
implementazione è stata testata dai rispettivi autori su piattaforme di calcolo diverse e su dataset
non omogenei, nonostante ciò si possono fare alcune considerazioni.
I metodi basati sulla classificazione a blocchi presentano probabilmente le prestazioni migliori in
termini di velocità di calcolo e di flessibilità in relazione all'utilizzo di svariati schemi di codifica.
I metodi basati sulla classificazione a layer presentano buone prestazioni dal punto
di vista della qualità complessiva dell'immagine compressa ma soffrono di un'elevata complessità e
dello scarso adattamento tra metodo di compressione e tipo di contenuto gestito.
I metodi ibridi rappresentano un valido compromesso dei due approcci appena descritti.
Bibliografia
1. de Queiroz, R., Buckley, R., Xu, M., “Mixed Raster Content (MRC) model for compound
image compression”, Corporate Research& Technology, Xerox Corp., 1999.
2. Maheswari, D., Radha, V., “Enhanced Hybrid Compound Image Compression algorithm
44
Progetto 3D CloudWiz | ATI NICE - DIEE
combining block and layer-basedsegmentation”, Springer, 2011.
3. Lin, T., Hao, P., “Compound Image compression for real-time computer screen image
transmission”, IEEE Transactions on Image Processing, Vol. 14, No. 8, 2005.
4. Maheswari, D., Radha, V., “Improved block based segmentation and compression
techniques for Compound Images”, International Journal of Computer Science &Engineering
Technology, 2010.
5. Ding, W., Liu, D., He, Y., Wu, F.,“Block-based fast compression for Compound Images”, IEEE
International Conference on Multimedia and Expo, 2006.
6. Mtimet, J., Amiri, H., “A layer-based segmentation method for compound images”, IEEE
10th International Multi-Conference on Systems, Signals&Devices (SSD), 2013.
7. Yang, H., Fang, Y., Yuan, Y., Lin W., “Subjective quality evaluation of compressed digital
compound images”,Elsevier, 2014.
8. Wang, Z., Bovik, A., C., Sheikh, H., R., Simoncelli, E., P., “Image quality assessment: from
error visibility to structural similarity”, IEEE Transactions on Image Processing, Vol. 13, No.
4, 2004.
9. Said, A. (2004) Compression of compound images and video for enabling rich media in
embedded systems, PIE/IS&T Visual Communications and Image Processing Conference,
SPIE Proc. Vol. 5308, Pp. 69-82. (2004).
10. Wong, T.S., Bouman, C.A. and Pollak, I. Improved JPEG decompression of document images
based on image segmentation, Proceedings of the 2007 IEEE/SP 14th Workshop on
Statistical Signal Processing, IEEE Computer Society, Pp. 488-492. (2007)
11. Li, X. and Lei, S Block-based segmentation and adaptive coding for visually lossless
compression of scanned documents, Proc. ICIP, VOL. III, PP. 450-453 (2001).
12. Amir Said and Alex Drukarev, Simplified Segmentation for Compound Image Compression,
1999
13. Ricardo L. de Queiroz, Zhigang Fan, and Trac D. Tran, Optimizing Block-Thresholding
Segmentation for Multilayer Compression of Compound Images,IEEE TRANSACTIONS ON
45
Progetto 3D CloudWiz | ATI NICE - DIEE
IMAGE PROCESSING, VOL. 9, NO. 9, SEPTEMBER 2000
14. Wenpeng Ding,Yan Lu Feng Wu, ENABLE EFFICIENT COMPOUND IMAGE COMPRESSION IN
H.264/AVC INTRA CODING, IEEE 2007
15. Alexandre Zaghetto and Ricardo L. de Queiroz, Segmentation-Driven Compound Document
Coding Based on H.264/AVC-INTRA, IEEE TRANSACTIONS ON IMAGE PROCESSING, VOL. 16,
NO. 7, JULY 2007
16. Amir Said, Compression of Compound Images and Video for Enabling Rich Media in
Embedded Systems, Hewlett-Packard Laboratories, 2004
17. B.-F. Wu, C.-C. Chiu and Y.-L. Chen, Algorithms for compressing compound document
images with large text/background overlap, IEE Proc.-Vis. Image Signal Process., Vol. 151,
No. 6, 2004
18. Masashi Nakao, Masaki Kita, Haifeng Chen, Masayuki Miyama, An 8 ms Delay Real-time
Image Transmission System for Remote Desktop, SID 2008
19. D.Maheswari , V.Radha, Comparison of Layer and Block Based Classification in Compound
Image Compression, (IJCSIT) International Journal of Computer Science and Information
Technologies, Vol. 2 (2) , 2011, 888-890
20. V.Radha, D.Maheswari, Secured Compound Image Compression Using Encryption
Techniques, Proceedings of the World Congress on Engineering and Computer Science 2011
Vol I, WCECS 2011, October 19-21, 2011
46
Progetto 3D CloudWiz | ATI NICE - DIEE
Metriche per il confronto fra algoritmi di compressione di immagini
Per valutare in maniera adeguata gli algoritmi di compressione che saranno analizzati si farà
riferimento ad alcuni parametri specifici.
In letteratura sono presenti alcuni parametri universalmente riconosciuti ed accettati che sono:
•
rapporto di compressione (Compression Ratio);
•
tempo di compressione e decompressione (Compression and Decompression Time);
•
errore quadratico medio (Mean Squared Error – MSE);
•
picco del rapporto tra segnale e rumore (Peak Signal to Noise Ratio – PSNR);
•
indice di similarità strutturale (Structural Similarity Index – SSIM).
Non tutti questi parametri sono universalmente applicabili: in particolare MSE, PSNR e SSIM
misurando l’alterazione apportata all’immagine originale dall’algoritmo di compressione sono
ovviamente utilizzati unicamente per le codifiche di tipo lossy o near lossless, mentre non hanno
applicabilità per le codifiche di tipo puramente lossless.
Compression ratio
Il rapporto di compressione misura la quantità (dimensione) dei dati compressi rispetto alla
quantità (dimensione) dei dati originali. Viene quindi definito come:
Compression Ratio = Lunghezza dei dati originali / Lunghezza dei dati compressi
come ovvio dalla formula precedente si può notare che il rapporto di compressione aumenta alla
riduzione dei dati compressi.
Tempo di compressione e decompressione
I tempi di compressione e decompressione dell'informazione (solitamente misurati in secondi)
sono l'unità di misura e confronto base al fine di valutare un sistema di compressione
dell'immagine. Questi parametri mettono in evidenza il tempo richiesto dall'algoritmo / algoritmi
implementati in un sistema per effettuare le operazioni di codifica e decodifica delle immagini in
ingresso.
47
Progetto 3D CloudWiz | ATI NICE - DIEE
Mean Squared Error – MSE
L'MSE viene definito in statistica come la misura che indica la discrepanza quadratica media fra i
valori dei dati osservati ed i valori dei dati stimati. Questo concetto viene declinato all'analisi delle
immagini come la misura della differenza quadratica media, pixel per pixel, di due immagini di
medesime dimensioni. Siano I e K due immagini di pari dimensioni, M x N, l'MSE tra le due
immagini può essere definito come:
Peak Signal to Noise Ratio – PSNR
Il PSNR viene utilizzato per valutare la qualità dell'immagine compressa rispetto all'originale, per
questo viene solitamente preso in considerazione prevalentemente per la misurazione delle
prestazioni di algoritmi di compressione di tipo lossy (es. JPG).
Esso, espresso in scala logaritmica di decibel, viene definito come il rapporto tra la massima
potenza di un segnale e la potenza di rumore che può invalidare la fedeltà della sua
rappresentazione compressa: è quindi la misura della distorsione introdotta comprimendo
l'immagine originale.
All'aumentare del valore di PSNR si aumenta il grado di somiglianza percepito, dal livello visivo
umano, rispetto all'immagine originale.
Tenendo in considerazione la formulazione dell'MSE precedentemente descritta, possiamo definire
il PSNR di un'immagine come segue:
Dove abbiamo indicato con R il massimo valore rappresentabile del pixel dell'immagine. Per
un'immagine binaria il numeratore varrà sempre 1, per un'immagine in scala di grigi il numeratore
assumerà invece il valore 255. Per immagini a colori tale definizione vale per un'unica componente.
48
Progetto 3D CloudWiz | ATI NICE - DIEE
Si può quindi estendere la formulazione del PSNR ad immagini a colori come segue:
Structural Similarity Index – SSIM
Lo Structural Similarity Index (SSIM) è un indice utilizzato per misurare la somiglianza tra
l'immagine originale e quella compressa. Viene spesso utilizzato al posto del PSNR o del MSE in
quanto questi ultimi due non tengono strettamente conto della percezione dell'occhio umano.
La differenza sta nel fatto che mentre PSNR e MSE stimano errori di tipo “fisico”, la brutale
differenza tra i pixel delle due immagini, il SSIM valuta la degradazione dell'immagine dal punto di
vista delle informazioni strutturali nel senso delle interdipendenze presenti tra pixel spazialmente
vicini.
SSIM viene calcolato per aree quadrate di un'immagine ed è possibile definirla, date due aree X e Y,
come:
dove abbiamo che σ2 è la varianza delle aree, μ è la media dei valori, σ xy è la covarianza tra i valori
delle due aree ed infine C1 e C2 sono due variabili utilizzate per evitare forme indeterminate della
funzione quando gli altri valori (μ2 e σ2) sono prossimi allo 0. In particolare essi sono definiti come:
C1=(K1L)2
C2=(K2L)2
dove abbiamo che K1 e K2 sono due variabili avente valore molto minore di 1, tipicamente si ha il
caso di K1 = 0.01 e K2 = 0.03, mentre L è il valore massimo che possono assumere i pixel (es. 255
per un'immagine in scala di grigi a 8 bit) ed è definibile quindi come:
L = 2Numero di bit per pixel – 1
49
Progetto 3D CloudWiz | ATI NICE - DIEE
Bibliografia
1. A. Mood, F. Graybill e D. Boes, Introduction to the Theory of Statistics.
2. Q. Huynh-Thu e M. Ghanbari, «Scope of validity of PSNR in image/video quality
assessment».
3. AA.VV., «Image Quality Assessment: From Error Visibility to Structural Similarity».
50
Pattern Recognition and Applications Lab
DIEE - Università di Cagliari
R2.2
RELAZIONE TEST COMPARATIVO SULLE PERFORMANCE REALI
DEGLI ALGORITMI DI COMPRESSIONE IN CONTESTI OPERATIVI
GENERICI E PER CATEGORIE SPECIFICHE DI CONTENUTO
Progetto 3D CloudWiz
Progetto 3D CloudWiz | ATI NICE - DIEE
Sommario
Sommario..............................................................................................................................................i
Obiettivo del documento......................................................................................................................1
Descrizione dell'organizzazione dei test...............................................................................................1
Test sui codec lossless..........................................................................................................................3
Codec lossless utilizzati....................................................................................................................3
Risultati degli esperimenti................................................................................................................4
Conclusioni.......................................................................................................................................9
Test sui codec lossy............................................................................................................................10
Codec lossy utilizzati......................................................................................................................10
Risultati degli esperimenti..............................................................................................................10
Analisi preliminare video con testo............................................................................................11
Analisi comparativa....................................................................................................................13
Analisi preliminare video con immagini naturali.......................................................................21
Analisi comparativa....................................................................................................................23
Analisi preliminare video composito..........................................................................................31
Analisi comparativa....................................................................................................................33
Conclusioni.....................................................................................................................................40
Test sui codec compound....................................................................................................................41
Codec compound............................................................................................................................41
Setup degli esperimenti..................................................................................................................41
Risultati degli esperimenti..............................................................................................................42
Conclusioni.........................................................................................................................................44
i
Progetto 3D CloudWiz | ATI NICE - DIEE
Obiettivo del documento
In questo documento si illustrano i test comparativi degli algoritmi di compressione. Si partirà dai
risultati del R2.1 selezionando alcune codifiche risultate maggiormente interessanti per il caso
oggetto del progetto e verranno anche aggiunti anche una serie di codec lossy in quanto le reali
condizioni operative, soprattutto in termini di banda, richiedono una riduzione maggiore dei byte
inviabili attraverso la rete per frame inviato.
In particolare come “classificatori” verranno testate le metodologie delle compound image
descritte in R.2.1. Sono stati effettuati ulteriori test utilizzando classificatori specifici per la text
detection oppure per l'individuazione di specifiche caratteristiche dell'imamgine con tecniche
mutuate dalla scene analysis per guidare la scelta del codec a seconda del contenuto del
frame/immagine. Si è scelto di non utilizzare poi questi approcci nei test estensivi riportati in
questo documento in quanto le tempistiche di questi algoritmi non consentirebbero la
realizzazione di un sistema il più vicino possibile al real-time dato che andrebbero ad introdurre un
ritardo significativo che andrebbe ad aggiungersi alle tempistiche che saranno riportate di seguito.
I test sono stati condotti esplorando la configurabilità degli algoritmi di compressione ed il loro
comportamento in termini delle misure di qualità individuate nel R2.1 al variare del contesto
operativo testato.
1
Progetto 3D CloudWiz | ATI NICE - DIEE
Descrizione dell'organizzazione dei test
Sono stati effettuati test indipendenti sulle seguenti tipologie di codec:
Codec lossy
Codec lossless
Codec compound
Gli aspetti principali considerati per la valutazione dei codec e dei metodi compositi sono:
Qualità di codifica in termini di : MSSIM e PSNR
Tempo di codifica, decodifica e totale
Capacità di compressione
I codec lossless e lossy sono stati testati sulle seguenti tipologie di contenuti:
Video contenenti soltanto testo
Video contenenti soltanto immagini
Video compositi contenenti sia testo che immagini
La valutazione dei metodi compositi è stata condotta soltanto col video composito.
Le immagini impiegate per effettuare i test sono nel formato a tre canali BGR.
In alcuni casi particolari è stato necessario convertire tale formato per assecondare le
caratteristiche intrinseche di specifici codec.
Setup degli esperimenti
Tutti i metodi di codifica descritti nella precedente sezione sono stati testati su video con le
seguenti caratteristiche tecniche (report R.2.3 per ulteriori dettagli):
Video Testo
Numero Frames
Grandezza Frame
Video Immagini
Video Composito
700
700
700
1366 x 682
1366 x 682
1366 x 682
Tabella 1: Caratteristiche tecniche dei video
Come indicato nella sezione introduttiva i fattori considerati per la valutazione sono:
Tempo di codifica, decodifica e totale misurato come media sui fotogrammi che
compongono ciascun video.
Capacità di compressione o numero medio di volte in cui viene compressa l'immagine.
Per quest'ultimo fattore si è tenuto conto della presenza di fotogrammi completamente neri
1
Progetto 3D CloudWiz | ATI NICE - DIEE
derivanti da transizioni nei video. Tale caratteristica può rendere i risultati non veritieri e pertanto
si è tenuto conto di ciò eliminandoli dai risultati.
Tutti i test sono stati svolti in parallelo, avviando tre simulazioni per volta, su una macchina non
dedicata, fornita di un processore Intel Core i7-3517U, su macchina virtuale Debian 7.
2
Progetto 3D CloudWiz | ATI NICE - DIEE
Test sui codec lossless
In questa sezione si descriveranno le prestazioni dei codec in grado di effettuare codifica senza
perdita. L'analisi sarà incentrata sulla valutazione dei tempi di codifica, decodifica e totali nonchè
sulla capacità di compressione. Verrà invece omessa la valutazione rispetto alla qualità di codifica
data la natura dei codec in esame.
Codec lossless utilizzati
I codec lossless testati sono i seguenti:
•
Jpeg_LS: Lo schema di compressione dello standard JpegLS si basa su quello di Jpeg
Lossless. La compressione in tal caso viene effettuata essenzialmente tramite un primo
passo di predizione basato sulla codifica DPCM e da un passo costituito da una codifica
entropica. In particolare lo scopo di Jpeg_LS è quella di ridurre la complessità della codifica
entropica attraverso l'impiego dell'algoritmo LOCO-I .
•
Jpeg 2000: Jpeg2000 è un sistema di codifica lossless e lossy basato sulla tecnologia
wavelet. Attualmente lo standard è composto da 14 punti. Il codec viene principalmente
impiegato nella compressione di immagini e video nonchè per la compressione di
informazioni volumetriche come definito nel punto 10 dello standard.
•
Jpeg XR: Il codec JpegXR (abbreviazione di Jpeg extendedrange) è un codec che permette di
effettuare la compressione di immagini con codifica lossless o lossy. Introdotto nel 2006
dalla Microsoft, la codifica JpegXR si basa completamente sulla codifica Jpeg, ma con alcuni
miglioramenti quali: compressione lossless, supporto alla codifica per tile, supporto del
canale trasparenza.
•
LZO: Il codec LZO (Lempel – Ziv – Oberhumer), non si tratta di un codec per immagini, ma di
un codec di compressione dati che permette di ottenere bassi livelli di compressione in
tempi estremamente ridotti. La compressione avviene a blocchi, i quali vengono compressi
grazie ad un dizionario scorrevole, utilizzando un algoritmo simile a quello della “sliding
window”. Verrà utilizzato per valutare la capacità di un algoritmo pensato solo per la
compressione dati in un contesto di compressione lossless di immagini.
•
Zrle: Il codec Zrle è un codec lossless basato sul principio di RLE (run length encoding),
ovvero la compressione di sequenze di dati simili fra loro e sull’algoritmo di compressione
“deflate”. La fase di compressione RLE si basa sull’individuazione di sequenze di pixel
identici fra loro, che possono quindi essere compressi come il numero di pixel consecutivi
ed il colore degli stessi. Per aumentare la compressione viene quindi applicato un algoritmo
costituito dalla combinazione dell’algoritmo LZ77 e della codifica di Huffman.
•
RLE_LZO: Il codec RLE_LZO integra i codec RLE e LZO con lo scopo di migliorare la capacita
complessiva di compressione.
•
WebP: Il codec è basato su un sistema predittivo con caratteristiche analoghe a quella
utilizzata dal codec VP8 per codificare i fotogrammi chiave nei video. In fase di
compressione il codec condivide alcune caratteristiche dell'algoritmo di compressione
3
Progetto 3D CloudWiz | ATI NICE - DIEE
LZ77.
Si è deciso di non includere i risultati del codec VP9 per i seguenti motivi:
In seguito alla perdita di conversione introdotta dalla trasformazione dal formato BGR a
quello YUV e viceversa, non è stato possibile riscontrare la caratteristica lossless tramite la
misura delle metriche di qualità.
Il codec non ha mostrato dei vantaggi rispetto ai concorrenti e pertanto non si sarebbe
ottenuta alcuna indicazione significativa dall'introduzione della sua valutazione.
Risultati degli esperimenti
I risultati sperimentali verranno mostrati in forma tabellare, indicando i parametri di valutazione
descritti nelle sezioni precedenti.
Nel ambito del progetto è stato scelto di impostare la qualità di codifica di ciascun codec
costruendo una mappatura (relativa) su una scala che varia da 0 a 100 come mostrato di seguito:
Mappatura
Qualità
0
Minima
...
...
...
...
100
Massima
Ad ogni modo a parità di valore di mappatura i codec non mostrano la medesima qualità
rispetto alle metriche MSSIM e PSNR, in quanto la variazione del parametro di qualità non è
omogenea fra tutti i codec.
Per i codec in esame la mappatura di qualità assume il seguente significato:
•
I codec: Jpeg_LS, Jpeg2000, JpegXR e WebP sono in grado in grado di effettuare sia codifica
lossy che lossless. In questa sezione tali codec sono stati settati con la mappatura 100 che
identifica la codifica senza perdita.
•
I codec: LZO, RLE_LZO e Zrle possono eseguire, ovviamente, soltanto codifiche lossless. In
questo caso è possibile esprimere un grado di compressione da 0 a 100 che segue ha un
significato diverso a seconda dell'algoritmo di compressione usato:
LZO
Mappatura
Compressione
Zip
Mappatura
Compressione
0
Minima
0
Massima
50
Intermedia
20
...
40
...
100
Massima
60
...
80
...
100
Minima
Consideriamo in primo luogo i risultati relativi al test sul video contenente soltanto testo.
La quarta colonna della tabella 2 indica il livello di compressione valutato rimuovendo i dati sul
livello di compressione introdotto dai fotogrammi di transizione contenuti nel video in modo tale
da avere dei valori medi di compressione più realistici. In grigio vengono indicati i codec con
performance migliori, in verde le prestazioni migliori e in rosso le peggiori riscontrate.
4
Progetto 3D CloudWiz | ATI NICE - DIEE
5
Progetto 3D CloudWiz | ATI NICE - DIEE
Encode
Testo
(ms)
Codec_Jpeg_LS_100
156,897
codec_Jpeg2000_100 2030,661
codec_JpegXR_100
237,0315
codec_LZO_000
5,83376
codec_LZO_050
6,350296
codec_LZO_100
480,7578
codec_RLE_LZO_000 12,55072
codec_RLE_LZO_050 13,41644
codec_RLE_LZO_100 286,7269
codec_Webp_100
3429,253
codec_Zrle_000
181,8607
codec_Zrle_020
83,73205
codec_Zrle_040
54,82203
codec_Zrle_060
46,90518
codec_Zrle_080
36,04393
codec_Zrle_100
33,34371
Decode
(ms)
144,4842
1478,033
209,7319
4,446056
4,399927
3,891319
5,148521
5,711399
5,786614
23,88109
8,683911
8,874047
8,910395
8,981062
9,179927
9,101639
Total_tim
e (ms)
301,3812
3508,694
446,7634
10,27982
10,75022
484,6491
17,69924
19,12784
292,5136
3453,134
190,5447
92,60609
63,73242
55,88624
45,22385
42,44535
No Transitions
Compression
ratio
2,386901
4,489849
3,907942
6,20584
6,336709
8,216147
6,594978
7,081695
9,742093
16,49622
9,934391
9,881994
9,771124
9,628881
9,760488
9,556155
Tabella 2: Tabella riassuntiva codec lossles video testo
Compress
ratio
mean
2,372665
4,466364
3,892301
6,202875
6,335569
8,223243
6,592389
7,06701
9,69826
16,48757
9,88897
9,835799
9,722819
9,582114
9,730503
9,531419
Il codec più performante dal punto di vista del tempo totale di codifica/decodifica è
rappresentato da: codec_LZO_000
Come è naturale attendersi il codec LZO ottiene le sue migliori prestazioni dal punto di vista del
tempo di codifica/decodifica imponendo il valore minimo di compressione essendo ottimizzato per
la compressione dati e non facendo alcuna analisi sull'immagine stessa.
In generale richiedere un livello di compressione maggiore comporta un aumento del tempo
impiegato per effettuarla.
Per quanto riguarda il codec LZO non risulta vantaggioso imporre il massimo livello di
compressione dato che questo comporta un lieve miglioramento della compressione stessa a
fronte di un aumento di un ordine di grandezza del tempo speso per effettuarla. Considerando la
risoluzione del video e supponendo di inviare 25 fotogrammi al secondo sarebbe necessaria una
risorsa di banda pari a circa:
BW= 90Mbit/sec
Il codec che ha mostrato le migliori prestazioni in termini di capacità di compressione é:
codec_Webp_100
col livello di compressione misurato si potrebbe inviare il video con una banda pari a:
BW=33.87 Mbit/sec
quindi circa 1/3 di quella richiesta dal codec LZO.
6
Progetto 3D CloudWiz | ATI NICE - DIEE
A fronte di tale capacità di compressione si riscontra un tempo totale di codifica/decodifica molto
elevato e secondo solo a quello del codec Jpeg2000. Considerando che il tempo di decodifica
mostrato da WebP è abbastanza contenuto esso si può collocare tra i codec adatti ad effettuare
codifiche "offline" e che di fatto spostano la complessità della catena di
compressione/decompressione verso il fornitore del servizio di streaming.
Per concludere si può dire che l'integrazione di algoritmi Run Lenght Encoding con altri algoritmi
di compressione non apportano migliorie significative in termini di compressione e tempo speso
per effettuarla se non nel caso della combinazione codec_Zrle_100 per il quale si ha un livello di
compressione maggiore di LZO_000 con tempi totali di codifica/decodifica abbastanza contenuti.
Consideriamo i risultati relativi al test sul video contenente soltanto immagini naturali.
Nella seguente tabella sono riportati i dati principali.
Video
codec_CharLS_100
codec_Jpeg2000_100
codec_JpegXR_100
codec_LZO_000
codec_LZO_050
codec_LZO_100
codec_RLE_LZO_000
codec_RLE_LZO_050
codec_RLE_LZO_100
codec_Webp_100
codec_Zrle_000
codec_Zrle_020
codec_Zrle_040
codec_Zrle_060
codec_Zrle_080
codec_Zrle_100
Encode
(ms)
115,654
1096,165
275,6238
7,537492
8,025755
342,4183
13,12161
13,90665
236,1612
2433,795
99,19528
88,24164
79,67845
71,85119
57,80858
57,42856
Decode Total_time
(ms)
(ms)
100,6059 216,2599
860,3662 1956,531
213,5992 489,223
5,670801 13,20829
5,78367 13,80942
7,751754 350,1701
5,09813 18,21974
5,544662 19,45131
8,626229 244,7874
49,33965 2483,135
14,32377 113,519
13,5882 101,8298
13,62247 93,30093
13,79136 85,64255
14,22535 72,03393
14,75461 72,18317
No transitions
Compression
ratio
2,302684
10,97189
8,249279
3,697706
3,851162
6,671999
5,013473
5,258637
7,598651
15,59999
8,815354
8,747914
8,536808
8,21431
7,656403
7,503815
Tabella 3: Riassunto prestazioni test immagini naturali
Compress
ratio
mean
69,69423
368,1858
142,7041
43,99502
44,1122
44,57947
968,51
966,848
1101,923
1412,437
1524,555
1479,565
1299,074
1073,56
774,5377
738,5948
Il codec più performante dal punto di vista del tempo totale di codifica/decodifica è
rappresentato da:
codec_LZO_000
Come nel caso precedente il codec LZO ottiene le sue migliori prestazioni dal punto di vista del
tempo di codifica/decodifica imponendo il valore minimo di compressione. Analogamente imporre
il massimo livello di compressione comporta un tempo totale di codifica/decodifica piuttosto
elevato e pari a circa: 350 msec.
Considerando la risoluzione del video e supponendo di inviare 25 fotogrammi al secondo
sarebbe necessaria mediamente una risorsa di banda pari a :
7
Progetto 3D CloudWiz | ATI NICE - DIEE
BW= 151 Mbit/sec
Quindi il codec LZO comprime meno se il contenuto del video è caratterizzato da transizioni
poco nette tipiche dei video privi di testo.
Come per la compressione del video con solo testo il miglior codec in termini di capacità di
compressione è :
Webp_100
in tal caso si otterrebbe un'occupazione di banda pari a:
BW= 36 Mbit/sec
valore decisamente inferiore rispetto a quello mostrato da LZO seppur piuttosto elevato.
Analogamente al caso descritto precedentemente WebP impiega molto tempo per effettuare la
codifica rispetto alla decodifica, ma in tal caso mostra anche un tempo di decodifica non
propriamente limitato. Anche in questo caso l'integrazione di differenti metodi di compressione
non ha portato vantaggi significativi. Per concludere è necessario evidenziare come la capacità di
compressione media valutata con e senza le transizioni sia decisamente diversa come indicato
dalle ultime due colonne della Tabella 3.
Consideriamo infine i risultati relativi al test sul video composito, in Tabella 4 sono state
riportate le informazioni principali.
Encode
Compound
(ms)
codec_CharLS_100
151,2023
codec_Jpeg2000_100 1828,029
codec_JpegXR_100
257,3069
codec_LZO_000
5,966675
codec_LZO_050
6,353451
codec_LZO_100
370,0537
codec_RLE_LZO_000 12,41577
codec_RLE_LZO_050 13,44856
codec_RLE_LZO_100 178,511
codec_Webp_100
4543,755
codec_Zrle_000
84,73863
codec_Zrle_020
69,09967
codec_Zrle_040
60,05692
codec_Zrle_060
51,92939
codec_Zrle_080
43,29128
codec_Zrle_100
41,65115
Decode
(ms)
136,598
1353,497
212,7063
4,410306
4,575433
4,795172
4,654704
5,232057
6,386386
44,97143
10,39744
10,33161
10,36764
10,22724
10,69557
10,70906
Total_tim
No transitions
e (ms) Compression ratio
287,8003
1,918267
3181,526
5,906544
470,0131
5,20892
10,37698
4,81994
10,92888
4,94203
374,8489
6,138201
17,07048
4,985602
18,68062
5,248601
184,8974
6,729704
4588,726
13,1683
95,13608
7,227404
79,43128
7,219542
70,42457
7,186295
62,15664
7,119092
53,98685
7,030804
52,3602
6,95526
Tabella 4: Dati riassuntivi video composito
Compress
ratio
mean
1,922266
5,860537
5,16017
4,848007
4,969573
6,180175
5,031443
5,296671
6,79717
13,17223
7,29423
7,285679
7,25013
7,179905
7,082596
7,003254
Ancora una volta la combinazione LZO_000 rappresenta la migliore soluzione per quanto
riguarda il tempo totale di codifica/decodifica. Il livello di compressione medio misurato si attesta
8
Progetto 3D CloudWiz | ATI NICE - DIEE
su un valore intermedio rispetto a quelli misurati nei casi precedenti. L'occupazione di banda
risulta piuttosto elevato in seguito alla bassa compressione introdotta:
BW= 116 Mbit/sec
Il codec WebP come nei casi precedenti mostra la migliore capacità di compressione che
comporterebbe un'occupazione di banda pari a:
BW= 42.4 Mbit/sec
in tal caso si ottiene un valore più elevato rispetto al caso di video con solo testo o solo immagini.
Conclusioni
Come atteso, i codec lossless sono caratterizzati da livelli di compressione poco elevati. I codec
che mostrano la migliore capacità di compressione spesso sono caratterizzati da tempi complessivi
di codifica/decodifica molto elevati. In relazione ai contenuti testati non è emersa la possibilità di
selezionare configurazioni particolari dato che per i tre casi considerati i codec migliori sono
risultati sempre WebP e LZO.
9
Progetto 3D CloudWiz | ATI NICE - DIEE
Test sui codec lossy
In questa sezione si descriveranno le prestazioni dei codec che effettuano codifiche con perdita.
Alcuni di essi sono anche in grado di effettuare codifiche lossless. L'analisi sarà incentrata sulla
valutazione dei tempi di codifica, decodifica e totali nonchè sulla capacità di compressione. Si
valuterà inoltre la qualità di codifica in relazione alle metriche PSNR e MSSIM.
Codec lossy utilizzati
I codec lossy testati sono i seguenti:
•
Jpeg_LS, Jpeg 2000, Jpeg XR e WebP descritti nella sezione lossless.
•
H264: L'H.264/MPEG-4 Part 10 o AVC (da Advanced Video Coding, termine inglese che
tradotto letteralmente significa "codifica video avanzata"), designazione formale ISO/IEC
14496-10 o ITU-T H.264, è un formato standard di compressione video digitale con perdita
creato dal Moving Picture Experts Group. Nel maggio 2003 è stata completata la stesura
finale della prima versione dello standard, mentre nelle edizioni successive sono state
aggiunte varie estensioni alle sue funzionalità.
•
TurboJpeg: è un’implementazione del codec Jpeg pensata per effettuare codifica e
decodifica in tempi più rapidi, mantenendo le caratteristiche del Jpeg-lossy.
•
Vp8: Il 19 maggio 2010 Google, che ha acquistato On2 nel 2010, ha rilasciato VP8 come
codec open source (sotto una licenza BSD-like) durante la conferenza Google I/O. Questo ha
reso VP8 il secondo prodotto di On2 Technologies ad essere donato alla comunità del
software libero dopo che nel 2002 rilasciò il codec VP3 (sempre sotto licenza BSD) alla
Xiph.Org Foundation come codec Theora; la richiesta che ha sollecitato di più Google a
rilasciare il codice sorgente di VP8 è venuta dalla Free Software Foundation, che il 12 marzo
2010 ha pubblicato una lettera aperta chiedendo a Google di rimpiazzare gradualmente
l'uso di Adobe Flash Player e H.264 su YouTube con HTML5 e VP8.
•
Vp9: Conosciuto in precedenza come Next Gen Open Video (NGOV) o VP-Next è uno
standard di compressione video aperto e libero da royalty in sviluppo da Google. Ideato
come il successore di VP8, è in competizione con il codec HEVC (o anche H.265) del
consorzio MPEG (parzialmente con royalty).
Risultati degli esperimenti
Nella presente sezione si analizzeranno i risultati degli esperimenti relativi ai codec lossy. Per
ciascun tipo di video descritto nel setup degli esperimenti verrà condotta:
Un'analisi preliminare: volta a dare una rappresentazione d'insieme delle prestazioni
assolute di ciascun codec in relazione ai fattori di valutazione indicati nella sezione
introduttiva;
Un'analisi comparativa: volta ad indicare quali codec mostrano le migliori prestazioni in
termini di capacità di compressione e tempo totale di codifica/decodifica.
10
Progetto 3D CloudWiz | ATI NICE - DIEE
Si cercherà anche di dare un'indicazione delle prestazioni in termini di occupazione di banda.
Nella sezione conclusiva viene elaborata una valutazione complessiva dei codec
contestualmente al contenuto di ciascun video testato.
La qualità di codifica verrà espressa in due modi differenti:
1. Metriche di qualità: MSSIM, PSNR;
2. Mappatura della qualità .
Nel ambito del progetto è stato scelto di impostare la qualità di codifica di ciascun codec
costruendo una mappatura su una scala che varia da 0 a 100 come mostrato di seguito:
Mappatura
0
...
...
100
Qualità
Minima
...
...
Massima
Ad ogni modo a parità di valore di mappatura i codec non mostrano la medesima qualità
rispetto alle metriche MSSIM e PSNR, quindi la mappatura indicata al punto 2 fornisce delle
informazioni su come regolare ciascun codificatore per ottenere certe prestazioni, ma non
consente di effettuare delle comparazioni in termini di prestazioni dal punto di vista della qualità
visiva. In tal senso è necessario impiegare le metriche di qualità indicate al punto 1.
Tutti i codec sono valutati al variare della qualità di codifica espressa attraverso la scala appena
descritta. La qualità di codifica così configurata è stata impostata con un passo di 20 ottenendo
quindi 6 campioni. Per quanto riguarda JpegLS nei grafici e nelle tabelle viene indicato col nome
CharLS in riferimento all'implementazione utilizzata.
Analisi preliminare video con testo
Si consideri come punto di partenza l'analisi dei codec rispetto alle prestazioni migliori e
peggiori in termini di: tempo di codifica, decodifica e totale, PSNR, MSSIM, capacità di
compressione in funzione della mappatura di qualità indicata nella sezione introduttiva.
La tabella seguente mostra un quadro riassuntivo.
11
Progetto 3D CloudWiz | ATI NICE - DIEE
TESTO
Q=0
WORST_ENC_TIME [msec] Vp9
4866,197468
BEST_ENC_TIME [msec]
TurboJpeg
15,46341917
WORST_DEC_TIME [msec]
Jpeg2000
572,571372
BEST_DEC_TIME [msec]
TurboJpeg
9,740526466
BEST_PSNR (dB)
CharLS
TurboJpeg
19,2155304
BEST_MSSIM
Openh264
0,983138498
WORST_MSSIM
TurboJpeg
0,743321721
BEST_COMP_RATE
WebP
CharLS
Vp9
Q=100
Vp9
Vp9
Vp9
Vp9
WebP
4910,889399
5008,5984
TurboJpeg
TurboJpeg
16,86053934
18,4164263
Jpeg2000
Jpeg2000
677,0910572
795,357588
TurboJpeg
TurboJpeg
11,14854793
12,5223906
Jpeg2000
35,67017253
40,0025075
TurboJpeg
TurboJpeg
24,80058591
28,101319
Openh264
Jpeg2000
0,983138498
0,99250614
TurboJpeg
TurboJpeg
0,898443585
0,94084579
Vp8
51,90428284
30,842491
CharLS
8,005624283
6,71234348
Vp9
4998,078751
BEST_TOTAL_TIME
Q=80
CharLS
8,828946343
WORST_TOTAL_TIME
Q=60
Vp8
99,40040071
WORST_COMP_RATE
Q=40
CharLS
34,13907686
WORST_PSNR (dB)
Q=20
TurboJpeg
25,20394564
Vp9
5043,258524
5160,63894
TurboJpeg
TurboJpeg
28,00908727
30,9388169
4937,385036
TurboJpeg
19,60868813
Jpeg2000
832,5779013
TurboJpeg
13,42586409
Jpeg2000
45,83970795
TurboJpeg
30,81686116
Jpeg2000
0,997370143
TurboJpeg
0,96095406
WebP
26,28594018
CharLS
5,655961289
Vp9
5097,612516
TurboJpeg
33,03455222
Tabella 5: Tabella analisi preliminare video testo
3565,457496
TurboJpeg
20,8637897
Jpeg2000
1018,379933
TurboJpeg
14,41834764
JpegXR
3429,25319
TurboJpeg
34,85969099
Jpeg2000
1478,032734
WebP
23,88109299
WebP
51,7316392
Openh264
34,33945173
JpegXR
99
Openh264
35,51106391
WebP
0,999201624
TurboJpeg
0,980998609
Openh264
24,36084954
CharLS
4,193758036
Vp9
3672,841376
TurboJpeg
35,28213734
1
Openh264
0,990455471
Openh264
22,02074147
CharLS
2,372665328
Jpeg2000
3508,693979
TurboJpeg
60,73680687
Alcuni codec come indicato nella penultima riga della tabella sono caratterizzati da tempi di
codifica/decodifica estremamente elevati e dell'ordine delle migliaia di msec.
I codec che mostrano tali caratteristiche sono:
Vp9: Il codec è progettato per spostare la complessità computazionale verso il fornitore del
servizio di streaming e di fatto mostra una velocità di decodifica molto maggiore rispetto a
quella di codifica.
Jpeg2000: Il codec mostra in generale dei tempi di codifica e decodifica molto alti
probabilmente imputabili all'implementazione OpenJpeg.
Il codec WebP mostra dei tempi dei codifica e decodifica in linea con quella degli altri codec.
Però impostando il massimo livello di qualità si misurano tempi di codifica elevati accompagnati da
tempi di decodifica contenuti. Tale comportamento non stupisce se si considera che WebP è
strettamente imparentato col codec video Vp8 e che in generale tali soluzioni tendono a
prediligere la velocità in decodifica piuttosto che quella in codifica.
12
Progetto 3D CloudWiz | ATI NICE - DIEE
I seguenti grafici pongono in evidenza le considerazioni preliminari appena fatte, si nota che i
codec Vp9 e Jpeg2000 non possono essere inseriti agevolmente all'interno dei grafici dato i tempi
elevati di codifica e decodifica.
Anche il codec JpegXR mostra dei tempi elevati che si attestano in valori intermedi tra i codec
più lenti descritti in precedenza e i restanti codec.
Figura 1: Tempo di codifica e di decodifica
Figura 2: Tempo complessivo di codifica/decodifica
Analisi comparativa
Per definire quale soluzione può risultare più performante rispetto ad uno specifico ambito di
utilizzo è necessario definire la prestazione congiunta in relazione alla qualità di codifica, la
capacità di compressione e il tempo totale di codifica/decodifica.
Si considera come qualità visiva accettabile quella contraddistinta da valori di MSSIM pari o
superiori a 0,85.
Consideriamo come primo elemento di valutazione la capacità di compressione. La figura 3
rappresenta la qualità di codifica misurata tramite la metrica MSSIM in funzione della
compressione.
13
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 3: MSSIM in funzione della compressione
La prima considerazione evidente è che tutti i codec tranne TurboJpeg sono caratterizzati da una
qualità di codifica sempre accettabile. Risulta inoltre che la qualità di codifica cresce al decrescere
della compressione, inoltre dal punto di vista puramente qualitativo risulta che alcuni codec come
TurboJpeg e JpegLS avrebbero la necessità di inviare un volume di informazione maggiore a parità
di qualità di codifca rispetto agli altri codec. Un altro aspetto strettamente legato alla capacità di
compressione è il tempo speso per effettuarla. Tipicamente maggiore è il tempo di codifica e
maggiore risulta il livello di compressione ottenuto. Tale assunzione non è sempre valida e possono
verificarsi comportamenti singolari. In figura 4 viene riportato il tempo di codifica in funzione
della compressione.
14
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 4: Tempo di codifica e compressione
In particolare i codec Vp9, Jpeg2000 mostrano dei livelli di compressione in linea con gli altri
codec ma con tempi di codifica molto elevati risultando poco efficienti sotto questo aspetto.
Risulta inoltre molto evidente la massima capacità di compressione del codec WebP.
Per rimarcare che non sempre un elevato livello di compressione coincide con elevati tempi di
compressione si consideri il seguente grafico che mostra i codec in grado di mantenere il tempo
complessivo di codifica sotto i 350 msec.
Figura 5: Tempo di codifica/decodifica sotto i 150 msec
15
Progetto 3D CloudWiz | ATI NICE - DIEE
Il codec H264 è caratterizzato da un tempo di codifica limitato associato ad una capacità di
compressione interessante in relazione agli altri codec.
La capacità di compressione massima di TurboJpeg seppur superiore a quella di H264 non
garantisce un'adeguata qualità di codifica (perchè ottenuta alla qualità minima) e perciò
nonostante rappresenti la migliore soluzione in termini di tempo totale di codifica/decodifca non
garantisce le stesse prestazioni di H264 in relazione al livello di compressione associato ad una
qualità visiva accettabile.
Dal grafico precedente spicca infine il basso livello di compressione del codificatore JpegLS (nel
grafico è indicato il nome dell'implementazione CharLS).
In linea generale si è constatato un certo bilanciamento tra i tempi di codifica e decodifica,
risulta tuttavia in alcuni codec recenti come Vp9 che il tempo di codifica sia nettamente superiore
al tempo di decodifica. Tale caratteristica è volta a sbilanciare il carico computazionale verso il
fornitore del servizio di streaming. Tale considerazioni risultano più evidenti grazie alla figura 7 in
cui Vp9 mostra un tempo di decodifica di un ordine di grandezza inferiore rispetto a quello di
codifica mostrato in figura 4. Per comodità il grafico del codec Jpeg2000 non è stato inserito dato
che per esso si rileva un tempo di decodifica sopra i 350 msec.
Figura 6:Tempo di decodifica
Si consideri ora come fattore di valutazione il Tempo complessivo di codifica/decodifica in
funzione della qualità di codifica espressa con la metrica MSSIM e rispetto alla capacità di
compressione.
Consideriamo in primo luogo la metrica MSSIM in funzione del tempo complessivo.
16
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 7: MSSIM in funzione del tempo complessivo
Il grafico pone in evidenza l'elevato tempo complessivo dei codec: Jpeg2000, Vp9 e WebP alla
massima qualità indicando quindi che il bilancio tra tempo di codifica e decodifica li rende poco
efficienti a parità di qualità rispetto agli altri codec.
Spicca inoltre la buona prestazione dei codec TurboJpeg e H264. Il codec TurboJpeg va
comunque tarato opportunamente per evitare di essere impiegato sotto la soglia di 0.85 della
metrica MSSIM.
L'analisi del tempo complessivo di codifica/decodifica in funzione della compressione non porta
alcuna indicazione ulteriore rispetto a quelle ottenute dall'analisi dei tempi di codifica e decodifica
studiati indipendentemente. In figura viene comunque riportato il tempo complessivo di
codifica/decodifica in funzione della compressione
17
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 8: Tempo complessivo in funzione della compressione
Per identificare quali codec consentano il miglior compromesso in termini di compressione e
tempo complessivo di codifica/decodifica si è scelto di analizzare i dati considerando quelle
impostazioni dei codec che consentono di avere una qualità di codifica sempre accettabile.
In tal senso per semplificare l'analisi i dati riportati nella tabella 6 si riferiscono ai valori: 60,80 e
100 della mappatura di qualità.
In verde si indica la prestazione migliore, in giallo la seconda migliore prestazione e in rosso la
peggiore tutte valutate al medesimo livello qualitativo impostato in ingresso.
La prima considerazione che risulta evidente è che tutti i codec codificano con un livello di
qualità più che accettabile e ciò deriva dal fatto che sono stati selezionati i dati relativi a settaggi
della qualità di codifica medio alti.
18
Progetto 3D CloudWiz | ATI NICE - DIEE
CODEC
MSSIM
WebP
0,988276011
0,992711963
1
Jpeg_LS 0,979449333
0,993013031
1
Turbo_Jpeg 0,96095406
0,980998609
0,999738575
Jpeg_2000 0,997370143
0,999067921
1
H264
0,987807024
0,987807024
0,990455471
Jpeg_XR 0,996610609
0,999201624
1
Vp8
0,989731445
0,994232086
0,99864824
Vp9
0,996348166
0,997994029
0,999200104
COMPRESSION
T_enc (msec)
T_dec (msec)
Total_time (msec)
26,43783405
21,69090183
16,49622481
5,68915664
4,222444622
2,386900564
15,48237537
11,41161849
3,349650985
9,333726264
6,386746736
4,489849363
24,46221517
24,46221517
22,10713679
8,650114298
5,409043506
3,907941942
23,76972032
19,54269948
11,05812993
19,4338347
15,0409803
9,060775479
287,483691
296,3066881
3429,25319
134,577887
169,3775122
156,8970143
19,60868813
20,8637897
34,85969099
1752,139099
1741,090072
2030,661245
46,06544778
46,87347496
46,65348498
350,7531559
383,0818455
237,0314664
117,5140544
119,6816123
183,2582947
4937,385036
3565,457496
1529,878196
34,06504864
38,21110014
23,88109299
78,53231474
100,4376981
144,4842203
13,42586409
14,41834764
25,87711588
832,5779013
1018,379933
1478,032734
54,34180973
54,82239485
54,78134335
285,0714306
316,0900644
209,7319413
57,85012303
60,80127754
106,0947296
160,2274807
107,3838798
94,62571102
321,5487396
334,5177883
3453,134283
213,1102017
269,8152103
301,3812346
33,03455222
35,28213734
60,73680687
2584,717
2759,470004
3508,693979
100,4072575
101,6958698
101,4348283
635,8245866
699,1719099
446,7634077
175,3641774
180,4828898
289,3530243
5097,612516
3672,841376
1624,503907
Tabella 6: Riassunto prestazioni
Analizzando i dati il miglior livello di compressione misurato è ottenuto dal codec:
WebP
Un livello di compressione analogo si ottiene col codec H264 che risulta più vantaggioso dato
che mostra un tempo totale di codifica e decodifica nettamente inferiore.
In tabella si riporta il confronto tra il codec WebP e H264.
Codec
Compressione
T_enc (msec)
T_dec (msec)
T_tot (msec)
WebP
26.4378
287.4836
34.0650
321.548
H264
24.462
46.065
54.341
100.407
Tabella 7: Comparativa WebP, H264
WebP risulta più prestazionale rispetto a H264 soltanto per il tempo di decodifica ma
complessivamente H264 è più veloce e mostra dei livelli di compressione e di qualità percepita in
linea con WebP.
19
Progetto 3D CloudWiz | ATI NICE - DIEE
Il codec più prestazionale dal punto di vista del tempo di codifica/decodifica è:
TurboJpeg
Il secondo codec più veloce è H264 che risulta comunque tre volte più lento rispetto a
TurboJpeg.
In tabella si riporta un breve confronto tra i due codec.
Codec
Compressione
T_enc (msec)
T_dec (msec)
T_tot (msec)
TurboJpeg
15.482
19.608
13.425
33.04
H264
24.464
46.065
54.341
100.407
Tabella 8: Comparativa TurboJpeg, H264
TurboJpeg risulta più vantaggioso se si predilige una maggiore velocità di codifica/decodifica. Il
livello di compressione medio seppur inferiore a quello mostrato da H264 risulta comunque
interessante. Dal punto di vista della qualità percepita entrambi i codec mostrano un MSSIM ben al
di sopra di 0.85 al quale corrisponde una qualità visiva più che soddisfacente.
Per completare l'analisi si considerino i valori medi minimi e massimi del bitrate di ciascun
codec mediati su tutti i possibili valori di qualità impostabili.
La tabella seguente riassume i risultati ottenuti.
Codec
WebP
Jpeg_LS
Turbo_Jpeg
Jpeg_2000
H264
Jpeg_XR
Vp8
Vp9
Bitrate_min
(Mbit/sec)
5,56482226
62,72643029
9,244235956
12,81654758
20,58411649
20,58804006
10,68014459
13,31146339
Bitrate_max
(Mbit/sec)
33,88455276
234,181184
166,8732661
124,495758
25,28446833
143,03365
50,54807669
61,69087859
Bitrate_mean
(Mbit/sec)
14,34863827
93,07028927
24,48116847
32,65835467
21,99253125
44,76339511
17,64293967
21,72860718
Tabella 9: Stima dell'occupazione di banda per tutte le qualità impostabili
La tabella da un'indicazione generale dell'allocazione di banda per ciascun codec in esame.
Ad ogni modo dato che per questa analisi si stanno considerando tutti i possibili valori di qualità
impostabili risulta che tali valori si riferiscono anche a qualità di codifica percepite non accettabili.
Per qualità percepite che vanno da livelli accettabili al massimo disponibile otteniamo i seguenti
risultati:
20
Progetto 3D CloudWiz | ATI NICE - DIEE
Codec
WebP
Jpeg_LS
Turbo_Jpeg
Jpeg_2000
H264
Jpeg_XR
Vp8
Vp9
Bitrate_min
(Mbit/sec)
18,46260308
82,7641117
29,19617288
36,97539988
20,58411649
43,08464106
18,00298697
20,83270081
Bitrate_max
(Mbit/sec)
33,88455276
234,181184
166,8732661
124,495758
25,28446833
143,03365
50,54807669
61,69087859
Bitrate_mean
(Mbit/sec)
23,56011118
117,3546373
45,27070492
63,28958429
22,77157418
72,26279965
26,17526987
31,77447069
Tabella 10: Stima dell'occupazione di banda per qualità di codifica medio alte
Come si nota i valori minimi sono aumentati è ciò sta ad indicare che per ottenere una qualità
percepita sufficiente è necessario spedire una quantità maggiore di informazione.
In definitiva se lo scopo è ottenere dei forti valori di compressione è consigliabile l'utilizzo del
codec H264, se invece è necessario codificare e decodificare un video ad elevata velocità è
consigliabile l'utilizzo del codec TurboJpeg.
Analisi preliminare video con immagini naturali
Si considerino i dati preliminari mostrati nella seguente tabella riassuntiva.
I medesimi codec, che nel caso di codifica di video con testo hanno mostrato tempi di
codifica/decodifica elevati , mostrano lo stesso comportamento anche per il contenuto video con
immagini naturali.
VIDEO
WORST_ENC_TIME [msec]
BEST_ENC_TIME [msec]
WORST_DEC_TIME [msec]
BEST_DEC_TIME [msec]
BEST_PSNR (dB)
WORST_PSNR (dB)
BEST_MSSIM
WORST_MSSIM
BEST_COMP_RATE
Q=0
Q=20
Q=40
Q=60
Q=80
Q=100
Vp9
Vp9
Vp9
Vp9
Vp9
Vp9
2672,641185
3007,92423
3346,342851
3751,653657
4142,033323
3195,400976
TurboJpeg
TurboJpeg
TurboJpeg
TurboJpeg
TurboJpeg
TurboJpeg
15,74966524
15,35433476
15,52912589
15,37437053
15,96541917
27,79412303
Jpeg2000
Jpeg2000
Jpeg2000
Jpeg2000
Jpeg2000
Jpeg2000
399,9048541
408,9278441
430,8044592
496,686289
614,1991574
860,3661831
TurboJpeg
TurboJpeg
TurboJpeg
TurboJpeg
TurboJpeg
TurboJpeg
9,367221745
9,394606581
9,757404864
9,872788269
10,49788841
17,73095708
Openh264
Openh264
Vp9
JpegXR
JpegXR
WebP
43,6484677
43,6484677
46,02464432
51,96718945
56,75624662
99
Jpeg2000
Jpeg2000
Jpeg2000
CharLS
Openh264
Openh264
23,44511458
30,20765771
37,15785421
40,31535894
44,89831222
45,4600948
Openh264
JpegXR
JpegXR
JpegXR
JpegXR
WebP
0,958276824
0,963646627
0,980521771
0,991885608
0,996723066
1
Jpeg2000
CharLS
CharLS
CharLS
CharLS
Openh264
0,615877452
0,726387179
0,771552977
0,823444509
0,929148383
0,972007908
Jpeg2000
Jpeg2000
Jpeg2000
Jpeg2000
Jpeg2000
WebP
11643,67248
7140,652411
4571,602682
3735,00235
2772,697849
1412,437439
21
Progetto 3D CloudWiz | ATI NICE - DIEE
WORST_COMP_RATE
WORST_TOTAL_TIME
BEST_TOTAL_TIME
TurboJpeg
TurboJpeg
TurboJpeg
TurboJpeg
TurboJpeg
TurboJpeg
102,8933092
82,77233872
72,32501731
65,17482235
54,62475047
27,29451626
Vp9
Vp9
Vp9
Vp9
Vp9
Vp9
2747,966906
3095,228422
3439,849584
3849,857227
4250,259044
3367,759897
TurboJpeg
TurboJpeg
TurboJpeg
TurboJpeg
TurboJpeg
TurboJpeg
25,11688698
24,74894134
25,28653076
25,2471588
26,46330758
45,52508011
Tabella 11: Tabella analisi preliminare video immagini naturali
Analogamente al caso considerato nella sezione precedente i codec Vp9 e Jpeg2000 risultano
difficili da inserire nei grafici relativi al tempo di codifica e decodifica come mostrato dalle figure 9
e 10. Anche il codec JpegXR mostra dei tempi di codifica e decodifica elevati che si attestano in
valori intermedi tra i codec più lenti appena descritti e i restanti codec. Il codec WebP mostra dei
tempi di codifica/decodifica molto elevati e paragonabili a quelli di vp9 e Jpeg2000 quando si
imposta la massima qualità di codifica.
Figura 9: Tempo di codifica e decodifica
22
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 10: Tempo complessivo di codifica/decodifica
Analisi comparativa
Per definire quale soluzione può risultare più performante rispetto ad uno specifico ambito di
utilizzo è necessario definire la prestazione congiunta in relazione alla qualità di codifica, la
capacità di compressione e il tempo totale di codifica/decodifica. Si considera come qualità visiva
accettabile quella contraddistinta da valori di MSSIM pari o superiori a 0.85.
Consideriamo come primo elemento di valutazione la capacità di compressione. Il seguente
grafico rappresenta la qualità di codifica misurata tramite la metrica MSSIM in funzione della
compressione.
23
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 11: MSSIM e Compressione
Risulta piuttosto evidente che per il contenuto video con immagini naturali Jpeg2000 mostra
una capacità di compressione molto alta rispetto agli altri codec per il quale non risulta agevole la
visualizzazione. Per un analisi più semplice si può considerare il seguente grafico che riporta una
porzione del grafico precedente.
Un altra informazione che risulta evidente dalla figura 11 è data dal fatto che alcuni codec
mostrano una qualità di codifica non sempre accettabile.
I codec con tale caratteristica sono : Jpeg2000, Turbojpeg, e JpegLS. Nel caso di compressione di
video con testo soltanto TurboJpeg mostrava un MSSIM sotto la soglia di 0,85.
24
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 12: Compressione[0-600] & MSSIM [0.85-1]
In generale l'andamento qualitativo dei codec mostrati è molto simile. Soltanto JpegLS e
TurboJpeg mostrano a parità di MSSIM rispetto agli altri codec un capacità di compressione
inferiore. Un altro aspetto strettamente legato alla capacità di compressione è il tempo speso ad
effettuarla. In figura viene riportato il livello di compressione in funzione del tempo di codifica.
Figura 13: Tempo di codifica e compressione
25
Progetto 3D CloudWiz | ATI NICE - DIEE
L'analisi risulta più agevole considerando i codec più veloci riportati nella seguente figura.
Figura 14: Tempo di codifica [0-350 msec] & Compressione [0-600]
I codec H264 e Vp8 sono caratterizzati da un tempo di codifica limitato, se paragonato ad altri
codec, ma sono in grado di comprimere in maniera significativa. Sia il codec Vp8 che H264
comprimono maggiormente rispetto a TurboJpeg sia dal punto di vista della compressione media
sia dal punto di vista della compressione massima. Tale risultato non è stato riscontrato col
contenuto video con testo nel quale TurboJpeg alla qualità minima comprimeva in misura
superiore rispetto ad H264. Spicca anche per il contenuto video con immagini naturali la scarsa
capacità di compressione del codec JpegLS.
In linea generale si è constatato un certo bilanciamento tra i tempi di codifica e decodifica,
risulta tuttavia in alcuni codec come Vp9 che il tempo di codifica sia nettamente superiore al
tempo di decodifica. Tale considerazioni risultano più evidenti grazie alla figura15 in cui il codec
Vp9 mostra un tempo di decodifica di un ordine di grandezza inferiore rispetto al tempo di codifica.
Per comodità il grafico non riporta il codec Jpeg2000 dato che per esso si rileva un tempo di
decodifica sopra i 350 msec.
26
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 15: Tempo di decodifica
Si consideri ora come fattore di valutazione il Tempo complessivo di codifica/decodifica in
funzione della qualità di codifica espressa con la metrica MSSIM e rispetto alla capacità di
compressione.
Consideriamo in primo luogo la metrica MSSIM in funzione del tempo complessivo.
Figura 16: Tempo complessivo in funzione del MSSIM
27
Progetto 3D CloudWiz | ATI NICE - DIEE
Il grafico pone in evidenza l'elevato tempo complessivo dei codec: Jpeg2000, Vp9 e WebP alla
massima qualità indicando quindi che il bilancio tra tempo di codifica e decodifica li rende poco
efficienti a parità di qualità rispetto agli altri codec.
Spicca inoltre la buona prestazione dei codec TurboJpeg e H264. Il codec TurboJpeg va
comunque regolato opportunamente per evitare di codificare con una qualità visiva non
accettabile.
L'analisi del tempo complessivo di codifica/decodifica in funzione della compressione non porta
alcuna indicazione ulteriore rispetto a quelle ottenute dall'analisi dei tempi di codifica e decodifica
studiati indipendentemente. In figura 18 viene comunque riportato il tempo complessivo di
codifica/decodifica in funzione della compressione.
Figura 17:Tempo complessivo in funzione della compressione
Per identificare quali codec consentano il miglior compromesso in termini di compressione e
tempo complessivo di codifica/decodifica si è scelto di analizzare i dati considerando quelle
impostazioni dei codec che consentono di avere una qualità di codifica sempre accettabile.
In tal senso per semplificare l'analisi i dati riportati nella tabella 12 si riferiscono ai valori: 60,80
e 100 della mappatura di qualità. In verde si indica la prestazione migliore, in giallo la seconda
migliore prestazione e in rosso la peggiore tutte valutate al medesimo livello qualitativo impostato
in ingresso. La prima considerazione che risulta evidente è che tutti i codec codificano con un
livello di qualità più che accettabile e ciò deriva dal fatto che sono stati selezionati i dati relativi a
settaggi della qualità di codifica medio alti.
28
Progetto 3D CloudWiz | ATI NICE - DIEE
CODEC
WebP
MSSIM
0,969428811
0,977946285
1
Jpeg_LS 0,823444509
0,929148383
1
0,978931843
Turbo 0,988691991
Jpeg 0,997888046
0,926083172
Jpeg 0,986520629
2000
1
H264 0,966607142
0,966607142
0,972007908
Jpeg 0,991885608
XR
0,996723066
1
Vp8
0,97018269
0,977893429
0,992740937
Vp9
0,985859923
0,990487099
0,996725629
COMPRESSION
T_enc (msec)
T_dec (msec)
240,042572
172,2829443
15,59999377
14,11480207
5,061866524
2,302683955
52,95227304
39,45889184
8,74276877
436,7932399
104,858828
10,97188575
223,7185104
223,7185104
193,141088
80,21428136
29,39326674
8,249279081
208,3921707
147,1105031
34,53414559
190,1418479
94,56274684
19,72864439
200,6831731
217,4238798
2433,795332
147,5273591
165,8584678
115,6539757
15,37437053
15,96541917
27,79412303
1138,917382
1152,880263
1096,165106
35,03406724
36,63472103
33,44926323
274,6776738
301,285681
275,6238026
95,77055937
93,5961774
102,0817396
3751,653657
4142,033323
3195,400976
18,85086266
20,84014306
49,33964807
79,74548069
90,06125894
100,605877
9,872788269
10,49788841
17,73095708
496,686289
614,1991574
860,3661831
46,96930472
47,95190844
46,17413162
191,964133
218,4234363
213,5992446
42,24031044
43,5302804
51,76111588
98,20357082
108,225721
172,3589213
Total_time(msec)
219,5340358
238,2640229
2483,13498
227,2728398
255,9197268
216,2598526
25,2471588
26,46330758
45,52508011
1635,603671
1767,079421
1956,531289
82,00337196
84,58662947
79,62339485
466,6418069
519,7091173
489,2230472
138,0108698
137,1264578
153,8428555
3849,857227
4250,259044
3367,759897
Tabella 12: Riassunto prestazioni video immagini naturali
il miglior livello di compressione misurato è ottenuto dal codec:
Jpeg2000
La seconda migliore prestazione si riscontra col codec WebP, mentre il codec che comprime
meno risulta essere Jpeg_LS. Come indicato nell'analisi preliminare il codec Jpeg2000 risulta essere
troppo lento sia in fase di codifica che di decodifica.
In base a tali considerazioni si possono considerare altri codec che comprimono in misura
inferiore, ma che possono garantire una migliore prestazione dal punto di vista del tempo di
codifica decodifica.
I codec che più si avvicinano in termini di capacità di compressione a WebP e Jpeg2000 sono:
H264 e Vp8
I due codec e le rispettive capacità di compressione sono indicati in grigio nella tabella 14.
Nella seguente tabella si riportano le prestazioni dei codec WebP, H264 e Vp8.
29
Progetto 3D CloudWiz | ATI NICE - DIEE
Codec
Compressione
T_enc (msec)
T_dec (msec)
T_tot (msec)
Webp
240.042
200.683
18.850
227.272
H264
223.718
35.034
46.969
82.003
Vp8
208.39
95.770
42.240
138.010
Tabella 13: Comparativa WebP,H264 e Vp8
Risulta evidente come H264 sia il compromesso migliore tra capacità di compressione e tempo
totale di codifica/decodifica. Ancora una volta WebP mostra un tempo di decodifica molto
contenuto se paragonato a quello di codifica. Dal punto di vista della compressione tutti i codec
mostrati nella precedente tabella sono comunque caratterizzati da livelli simili.
Per quanto riguarda il tempo complessivo di codifica/decodifica il codec più prestazionale è:
TurboJpeg
La seconda prestazione è relativa al codec H264 come indicato dalla seguente tabella riassuntiva.
Codec
Compressione
T_enc (msec)
T_dec (msec)
T_tot (msec)
TurboJpeg
52.952
15.374
9.872
25.247
H264
223.718
35.034
46.969
82.003
Tabella 14: Comparativa TurboJpeg, H264
Il codec TurboJpeg è complessivamente più veloce rispetto ad H264 ma comprime molto meno
e con un divario maggiore rispetto a quello riscontrato sul video con testo indicando quindi che
H264 rappresenta una buona soluzione per comprimere efficacemente immagini naturali.
Per completare i risultati ottenuti consideriamo i valori medi minimi e massimi del bitrate di
ciascun codec mediati su tutti i possibili valori di qualità impostabili. La tabella riassume i risultati
ottenuti considerando di inviare il filmato di prova con una frequenza di 25 fotogrammi al secondo.
Codec
Bitrate_min(Mbit/sec) Bitrate_max(Mbit/sec) Bitrate_mean(Mbit/sec)
WebP
0,814354676
35,83124509
1,87755913
Jpeg_LS
5,9842365
242,7459482
16,14733677
Turbo_Jpeg
5,484011784
63,93480312
9,843200368
Jpeg_2000
0,062812793
50,94540837
0,234057724
H264
2,153215433
2,894087456
2,362885518
Jpeg_XR
1,558889132
67,75952111
3,812251763
Vp8
1,130930742
16,18592817
1,980661352
Vp9
0,713086437
28,33277284
1,485962905
Tabella 15: Stima dell'occupazione di banda per tutte le qualità impostabili
30
Progetto 3D CloudWiz | ATI NICE - DIEE
Per garantire un livello di qualità percepita sempre accettabile è necessario che il bitrate sia
contenuto negli estremi indicati nella seguente tabella.
Codec
Bitrate_min(Mbit/sec) Bitrate_max(Mbit/sec) Bitrate_mean(Mbit/sec)
WebP
1,915761278
35,83124509
3,106674695
Jpeg_LS
15,93481422
242,7459482
39,53251598
Turbo_Jpeg
9,008722642
63,93480312
13,70007027
Jpeg_2000
0,399618459
50,94540837
1,145790776
H264
2,153215433
2,894087456
2,483816769
Jpeg_XR
3,29094402
67,75952111
7,771341321
Vp8
1,776025178
16,18592817
3,172497469
Vp9
1,452556168
28,33277284
3,243918022
Tabella 16: Stima dell'occupazione di banda per qualità medio alte
Risulta in definitiva che il codec H264 rappresenta il miglior compromesso nel caso in cui
l'obbiettivo della codifica sia comprimere a livelli elevati. Se invece l'obbiettivo finale della
compressione è mantenere il tempo totale di codifica/decodifica a livelli contenuti è consigliabile
l'impiego del codec TurboJpeg.
Analisi preliminare video composito
L'analisi preliminare suggerisce le medesime indicazioni ottenute nelle sezioni precedenti, i
codec Vp9 e Jpeg2000 mostrano tempi di codifica/decodifica inoltre il codec WebP , come nel caso
di video contenente solo testo, registra il tempo di codifica più elevato.
D
COMPOUN
WORST_ENC_TIME [msec]
BEST_ENC_TIME [msec]
WORST_DEC_TIME [msec]
BEST_DEC_TIME [msec]
BEST_PSNR (dB)
WORST_PSNR (dB)
BEST_MSSIM
WORST_MSSIM
BEST_COMP_RATE
Q=0
Q=20
Q=40
Q=60
Q=80
Q=100
Vp9
Vp9
Vp9
Vp9
Vp9
WebP
4164,203934
4152,475207
4404,46671
4626,886681
4151,385994
4543,754564
TurboJpeg
TurboJpeg
TurboJpeg
TurboJpeg
TurboJpeg
TurboJpeg
15,22715737
16,44491416
16,93326037
17,19088984
19,13022461
30,46492561
Jpeg2000
Jpeg2000
Jpeg2000
Jpeg2000
Jpeg2000
Jpeg2000
478,7967797
585,3875894
707,9317253
725,8288798
874,1931674
1353,496748
TurboJpeg
TurboJpeg
TurboJpeg
TurboJpeg
TurboJpeg
TurboJpeg
9,507157368
10,84386409
11,45883405
12,05192704
13,6654907
22,29439771
Openh264
JpegXR
JpegXR
JpegXR
JpegXR
WebP
34,26231436
35,84257248
39,27740487
45,26520834
52,13435601
99
TurboJpeg
TurboJpeg
TurboJpeg
TurboJpeg
Openh264
Openh264
20,82187696
27,36776404
30,7273999
33,28083371
35,63908562
36,89740004
Openh264
JpegXR
JpegXR
JpegXR
JpegXR
WebP
0,94216124
0,963396159
0,978483511
0,993709823
0,998286612
1
TurboJpeg
CharLS
CharLS
CharLS
Openh264
Openh264
0,707071259
0,850154133
0,886638542
0,930836129
0,952847515
0,970806456
WebP
Vp8
Vp8
WebP
Openh264
Openh264
164,6118849
87,9713508
51,75419733
43,55505855
42,22227124
37,6143176
31
Progetto 3D CloudWiz | ATI NICE - DIEE
WORST_COMP_RATE
WORST_TOTAL_TIME
BEST_TOTAL_TIME
CharLS
CharLS
CharLS
CharLS
CharLS
CharLS
5,479461607
4,999615256
4,364925185
3,724219648
3,016232186
1,922265907
Vp9
Vp9
Vp9
Vp9
Vp9
WebP
4277,341393
4266,763754
4524,229979
4762,119122
4269,475076
4588,725991
TurboJpeg
TurboJpeg
TurboJpeg
TurboJpeg
TurboJpeg
TurboJpeg
24,73431474
27,28877825
28,39209442
29,24281688
32,79571531
52,75932332
Tabella 17: Tabella analisi preliminare video composito
Le considerazioni preliminari risultano efficacemente espresse dai seguenti grafici riassuntivi.
Figura 18: Tempo di codifca e decodifica
Figura 19: Tempo complessivo di codifica e decodifica
32
Progetto 3D CloudWiz | ATI NICE - DIEE
Analisi comparativa
Per definire quale soluzione può risultare più performante rispetto ad uno specifico ambito di
utilizzo è necessario definire la prestazione congiunta in relazione alla qualità di codifica, la
capacità di compressione e il tempo totale di codifica/decodifica. Si considera come qualità visiva
accettabile quella contraddistinta da valori di MSSIM pari o superiori a 0.85. Consideriamo come
primo elemento di valutazione la capacità di compressione. Il seguente grafico rappresenta la
qualità di codifica misurata tramite la metrica MSSIM in funzione della compressione.
Figura 20: MSSIM e Compressione
Il primo aspetto evidente è che qualitativamente si rileva un comportamento dei codec che può
attestarsi in una via di mezzo tra ciò che è stato riscontrato con il video contenente testo e quello
riscontrato con immagini naturali. Risulta evidente inoltre come Jpeg2000 a causa della presenza di
testo comprime in misura nettamente inferiore a ciò che si è riscontrato con le immagini naturali.
Per quanto riguarda invece JpegLS e TurboJpeg si riscontra ancora una capacità di compressione
inferiore a parità di qualità di codifica rispetto agli altri codec. Tale considerazione risulta
maggiormente chiara analizzando il grafico seguente.
33
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 21: MSSIM e Compressione
Per quanto riguarda il tempo di codifica e il livello di compressione otteniamo i risultati riportati
nella figura seguente.
Figura 22: Tempo di codifica e compressione
Le indicazioni generali che si ottengono sono in buona sostanza le medesime ottenute con gli
altri contenuti video. Ancora una volta Vp9 e Jpeg2000 registrano i tempi di codifica più alti e a
parità di compressione risultano svantaggiosi rispetto agli altri codec. I codec più veloci sono
riportati nella seguente figura.
34
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 23: Tempo di codifica in funzione del livello di compressione
Risulta come nei casi precedenti che TurboJpeg e H264 rappresentano un ottimo compromesso
in termini di capacità di compressione in funzione del tempo speso per effettuarla. Per quanto
riguarda il tempo di decodifica non si riscontrano risultati significativi rispetto ai contenuti video
già analizzati e continua a risultare che Vp9 mostra un forte sbilanciamento del tempo di codifica
rispetto a quello di decodifica. Nella figura seguente è riportato il tempo di decodifica in funzione
della compressione e per comodità non viene riportato il risultato conseguito da Jpeg2000 dato
l'elevato tempo di decompressione.
Figura 24: Tempo di decodifica e compressione
Di seguito si riporta il tempo complessivo di codifica/decodifica che comunque non fornisce
indicazioni aggiuntive rispetto ai contenuti video già analizzati.
35
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 25: Tempo complessivo e compressione
Si consideri ora come fattore di valutazione il Tempo complessivo di codifica/decodifica in
funzione della qualità di codifica espressa con la metrica MSSIM e rispetto alla capacità di
compressione. Consideriamo in primo luogo la metrica MSSIM in funzione del tempo complessivo.
Figura 26: Tempo complessivo in funzione del MSSIM
Ancora una volta risulta evidente la forte separazione in termini di tempo complessivo tra
Vp9,Jpeg2000 e WebP alla qualità massima e gli altri codec.
Emerge anche che TurboJpeg,WebP e JpegLS non sempre mostrano una qualità di codifica
accettabile. Questa caratteristica è imputabile alla presenza di variazioni continue di colore tipiche
delle immagini naturali, infatti tale comportamento non è stato riscontrato con il video contenente
36
Progetto 3D CloudWiz | ATI NICE - DIEE
soltanto testo. Ad ogni modo risulta evidente il vantaggio nell'impiegare TurboJpeg e H264 quando
si voglia che la catena di compressione/decompressione venga eseguita velocemente.
Quindi regolando opportunamente la qualità di codifica soprattutto di TurboJpeg è possibile
ottenere dei tempi complessivi molto contenuti. Per H264 invece non è stato possibile configurare
una mappatura della qualità come risulta evidente dalla figura 26. Tale caratteristica può risultare
più naturale considerando che è un codec specifico per la compressione di video, per il quale la
caratteristica fondamentale è la capacità di compressione (o il bitrate).
L'analisi del tempo complessivo di codifica/decodifica in funzione della compressione non porta
alcuna indicazione ulteriore rispetto a quelle ottenute dall'analisi dei tempi di codifica e decodifica
studiati indipendentemente. In figura viene comunque riportato il tempo complessivo di
codifica/decodifica in funzione della compressione.
Figura 27: Tempo complessivo in funzione della compressione
37
Progetto 3D CloudWiz | ATI NICE - DIEE
Per identificare quali codec consentano il miglior compromesso in termini di compressione e
tempo complessivo di codifica/decodifica si è scelto di analizzare i dati considerando quelle
impostazioni dei codec che consentono di avere una qualità di codifica sempre accettabile. In tal
senso per semplificare l'analisi i dati riportati nella tabella 18 si riferiscono ai valori: 60,80 e 100
della mappatura di qualità. In verde si indica la prestazione migliore, in giallo la seconda migliore
prestazione e in rosso la peggiore tutte valutate al medesimo livello qualitativo impostato in
ingresso. La prima considerazione che risulta evidente è che tutti i codec codificano con un livello
di qualità più che accettabile e ciò deriva dal fatto che sono stati selezionati i dati relativi a settaggi
della qualità di codifica medio alti.
CODEC
WebP
MSSIM
0,95365333
0,960627767
1
Jpeg_LS 0,930836129
0,974149372
1
Turbo_Jpeg 0,962127674
0,979514539
0,999074867
Jpeg_2000 0,991932326
0,996797602
1
H264
0,952847515
0,952847515
0,970806456
Jpeg_XR 0,993709823
0,998286612
1
Vp8
0,948732562
0,969351887
0,996088258
Vp9
0,987610462
0,994470619
0,998396223
COMPRESSION
T_enc (msec)
T_dec (msec)
Total_time(msec)
44,38240201
35,43517951
13,16830143
3,713455073
3,008407257
1,918267165
20,63188285
15,29219481
4,582414483
15,50323449
9,615098861
5,906544444
43,03029573
43,03029573
38,32297274
13,79115296
8,064184996
5,208919753
39,16167566
31,53971388
15,16684625
32,70041026
23,750875
11,76980364
245,2928655
253,6789056
4543,754564
204,8634506
215,0426037
151,202309
17,19088984
19,13022461
30,46492561
1610,779399
1553,037102
1828,029428
42,22667096
42,0497897
41,99806152
314,5512518
345,3601531
257,3068555
107,2364521
113,3128326
153,2143877
4626,886681
4151,385994
2105,564564
26,42888412
29,16226896
44,97142775
116,3462604
122,361475
136,5979742
12,05192704
13,6654907
22,29439771
725,8288798
874,1931674
1353,496748
51,14334621
50,64510443
51,13049499
239,8181989
271,3197783
212,706289
50,40015451
53,59950358
83,07090272
135,2324406
118,0890815
111,1083648
271,7217496
282,8411745
4588,725991
321,209711
337,4040787
287,8002833
29,24281688
32,79571531
52,75932332
2336,608279
2427,230269
3181,526176
93,37001717
92,69489413
93,12855651
554,3694506
616,6799313
470,0131445
157,6366066
166,9123362
236,2852904
4762,119122
4269,475076
2216,672928
Tabella 18: riassunto delle prestazioni
Il miglior livello di compressione misurato è ottenuto dal codec:
WebP
La seconda prestazione migliore appartiene al codec H264 e analogamente ai casi visti in
precedenza Jpeg_LS è il codec che comprime meno.
La tabella seguente riassume le prestazioni dei codec H264 e WebP.
38
Progetto 3D CloudWiz | ATI NICE - DIEE
Codec
Compressione
T_enc (msec)
T_dec (msec)
T_tot (msec)
WebP
44.382
245.292
26.428
271.721
H264
43.030
42.226
51.143
93.370
Tabella 19: Comparativa WebP, H264
In questo caso risulta facile asserire che H264 risulta maggiormente vantaggioso rispetto a
WebP dato che mostra un livello di compressione praticamente identico ma con un tempo
complessivo di codifica/decodifica nettamente migliore. Risulta ad ogni modo che WebP mostra il
miglior tempo in fase di decodifica.
Il codec più prestazionale dal punto di vista del tempo complessivo di codifica/decodifica è:
TurboJpeg
Mentre il secondo codec più veloce è H264, la tabella seguente pone in relazione le prestazioni
dei due codec.
Codec
Compressione
T_enc (msec)
T_dec (msec)
T_tot (msec)
TurboJpeg
20.631
17.190
12.051
29.24
H264
43.030
42.226
51.143
93.37
Tabella 20: Comparativa TurboJpeg, H264
Il codec H264 comprime all'incirca il doppio rispetto a TurboJpeg ma con un tempo complessivo
di codifica/decodifica circa tre volte maggiore rispetto a TurboJpeg.
Per concludere l'analisi si considerino i risultati rispetto ai valori medi minimi e massimi del
bitrate di ciascun codec mediati su tutti i possibili valori di qualità impostabili. La tabella riassume i
risultati ottenuti considerando di inviare il filmato di prova con una frequenza di 25 fotogrammi al
secondo.
Codec
WebP
Jpeg_LS
Turbo_Jpeg
Jpeg_2000
H264
Jpeg_XR
Vp8
Vp9
Bitrate_min(Mbit/sec)
3,335725628
102,4783621
7,870063785
5,535648095
11,58491283
12,38217829
6,234323006
7,248075994
Bitrate_max(Mbit/sec) Bitrate_mean(Mbit/sec)
42,44793475
8,837537099
291,3917364
143,1859957
121,9809343
19,5651484
94,63523136
16,45643864
14,58569521
12,46154058
107,3096201
27,59269454
36,85454384
10,54931118
47,49163342
12,41248096
Tabella 19: Stima dell'occupazione di banda per tutte le qualità impostabili
39
Progetto 3D CloudWiz | ATI NICE - DIEE
Volendo garantire una qualità percepita accettabile il bitrate minimo dovrà essere incrementato
come indicato dalla seguente tabella.
Codec
Bitrate_min(Mbit/sec) Bitrate_max(Mbit/sec) Bitrate_mean(Mbit/sec)
WebP
10,79589286
42,44793475
15,44515802
Jpeg_LS
128,5089574
291,3917364
172,1254155
Turbo_Jpeg
22,17953321
121,9809343
34,02712295
Jpeg_2000
21,3831863
94,63523136
39,1122888
H264
11,58491283
14,58569521
12,95156145
Jpeg_XR
26,33815531
107,3096201
46,30376706
Vp8
10,60070151
36,85454384
16,1321004
Vp9
11,70951066
47,49163342
19,28183546
Tabella 20: Stima dell'occupazione di banda per qualità medio alte
In definitiva il codec H264 è la soluzione migliore in termini di compressione mentre TurboJpeg
risulta il codec migliore per quanto riguarda il tempo complessivo impiegato per la codifica e
decodifica.
Conclusioni
Per tutti i contenuti video testati è emerso che i codec con performance migliori sono:
TurboJpeg e H264. Il primo garantisce la migliore prestazione in termini di tempo di
codifica/decodifica complessivi mostrando ad ogni modo dei livelli di compressione comunque in
linea con gli altri codec. Il secondo rappresenta certamente il miglior compromesso tra tempo
totale di codifica/decodifica e capacità di compressione.
40
Progetto 3D CloudWiz | ATI NICE - DIEE
Test sui codec compound
In questa sezione si descriveranno le prestazioni dei metodi di compressione compositi. L'analisi
sarà incentrata sulla valutazione dei tempi di codifica, decodifica e totali nonché sulla capacità di
compressione. Si valuterà inoltre la qualità di codifica in relazione alle metriche PSNR e MSSIM.
Codec compound
I tre metodi di classificazione e codifica per compound image utilizzati sono i seguenti:
Metodo a blocchi
Metodo a strati
Metodo ibrido
Si rimanda al documento di descrizione dei suddetti metodi per la descrizione delle fasi di
classificazione, mentre i codec singoli utilizzati per le aree di testo e di immagini sono i seguenti:
CharLS
H.264
Jpeg2000
JpegXR
LZO
RLE + LZO
TurboJpeg
Vp8
Vp9
WebP
Zrle
Alcuni di questi codec sono stati scartati a priori dopo essere stati testati singolarmente, poiché
non adatti al caso studiato. In particolar modo CharLS, Jpeg2000, JpegXR, Vp9 e WebP non sono
codec pensati per effettuare codifica e decodifica di immagini in real time, e presentano quindi
tempi di elaborazione eccessivamente elevati. I codec rimanenti sono stati selezionati in base ai
risultati ottenuti testando le performance dei singoli codec su immagini di tipo composito,
immagini contenenti prevalentemente testo o immagini naturali.
Setup degli esperimenti
Al fine di valutare i metodi compound è stato utilizzato un video composto da zone di immagini
naturali e zone di testo. Per una descrizione più dettagliata del video si rimanda al documento
specifico in cui viene descritto il dataset utilizzato negli esperimenti. I test sono stati svolti in
parallelo, avviando tre simulazioni per volta, su una macchina non dedicata, fornita di un
41
Progetto 3D CloudWiz | ATI NICE - DIEE
processore Intel Core i7-3517U, su macchina virtuale Debian 7.
Risultati degli esperimenti
Al fine di gestire i risultati, è stato necessario compiere una prima scrematura, eliminando i
risultati non accettabili. Sono stati quindi tracciati due grafici scatter dei risultati ottenuti sul video
composito, che è il caso più significativo,riducendo gli assi del tempo e della qualità a valori
significativi per il caso d'uso definito nel progetto. In questo modo, i metodi che impiegano un
tempo totale di codifica e decodifica eccessivo, oppure che mostrano una qualità troppo bassa,
non vengono neanche considerati. Nella figura seguente sono riportati i grafici:
Figura 28: Capacità di compressione, MSSIM e tempo totale di codifica/decodifica
Il primo grafico indica il rapporto di compressione ottenuto al variare del tempo totale di
codifica e decodifica dei metodi compound, mentre nel secondo è indicata la qualità visiva
misurata tramite l’MSSIM. Poiché i due assi del tempo coincidono, è possibile notare che i risultati
di uno stesso codec risultano allineati. I casi più interessanti sono stati evidenziati.
Il metodo che ottiene il rapporto di compressione maggiore è evidenziato in rosso, e indica il
metodo a strati applicato utilizzando Zrle come codec per le aree di testo e H264 per le aree di
immagini. Questo metodo permette di codificare in maniera lossless le zone di testo, che
tipicamente sono le zone in cui è richiesta una qualità maggiore, mantenendo comunque alta la
qualità su immagini naturali e zone a gradiente continuo grazie al codec H264, il quale permette
oltretutto di comprimere notevolmente l’immagine composita. Tali risultati si accompagnano però
ad un tempo di compressione e decompressione di circa 180 ms, troppo elevato per
42
Progetto 3D CloudWiz | ATI NICE - DIEE
un’applicazione di remote desktop.
In verde è indicato il metodo ibrido applicato usando il codec H264 per il testo e TurboJpeg per
le immagini. Questo metodo ottiene dei tempi meno elevati del metodo precedentemente
descritto grazie alle prestazioni del codec TurboJpeg, ed una qualità superiore, al prezzo di una
notevole riduzione del rapporto di compressione.
Sono invece evidenziate in giallo diverse combinazioni di qualità del metodo a blocchi applicato
utilizzando LZO per le aree di testo e TurboJpeg per le aree contenenti immagini. Come nel caso
precedente, le aree di testo vengono codificate in maniera lossless, mentre le aree a gradiente più
continuo sono codificate tramite il TurboJpeg. Questo metodo, sebbene offra un tempo di codifica
e decodifica estremamente rapido e una qualità altissima, non permette di comprimere
sufficientemente l’immagine. Questo metodo è quindi adatto a situazioni in cui la banda
disponibile è estremamente elevata.
Infine in verde è indicato il metodo che offre il compromesso migliore: ovvero il metodo a strati
che utilizza i codec Zrle e TurboJpeg. Questo metodo offre una qualità nettamente inferiore agli
altri metodi, seppur sufficiente dal punto di vista percettivo, ma permette di ottenere un buon
rapporto di compressione in un tempo accettabile di compressione e decompressione.
43
Progetto 3D CloudWiz | ATI NICE - DIEE
Conclusioni
In conclusione, può essere detto che i metodi compound offrono la possibilità di comprimere
selettivamente determinate aree di un’immagine, permettendo quindi l’utilizzo di un codec rapido
per le zone in cui la qualità visiva risulta essere meno importante, e un codec più preciso in zone in
cui è determinante mantenere alta la qualità. Essi vanno però paragonati con i risultati ottenuti
dall’analisi dei codec singoli. Nella seguente figura sono riportati due grafici contenenti alcuni
risultati ottenuti dai codec standard sul medesimo video in cui sono stati testati i metodi
compound.
Figura 29: Capacità di compressione, MSSIM e tempo totale di codifica/decodifica
44
Progetto 3D CloudWiz | ATI NICE - DIEE
Nei grafici sono indicati il rapporto di compressione e la qualità misurata tramite l’MSSIM
rispetto al tempo impiegato per compiere la codifica e decodifica. Sono riportati solo i codec che
rientrano in un tempo minore di 100 msec che consentono di ottenere un parametro di qualità
maggiore dell’80% se misurato tramite MSSIM.
Si può notare che i codec TurboJpeg e H264 presentano delle performance generalmente
migliori dei metodi compound. Il codec H264 permette infatti di effettuare una codifica e
decodifica in tempi minori di 100 ms, mantenendo un livello di compressione fra le 40 e 50 volte
ed una qualità elevata, corrispondente a un risultato di 95% di MSSIM. Il codec TurboJpeg invece
permette di ottenere dei tempi di compressione e decompressione estremamente rapidi e una
qualità elevata al prezzo di una minore capacità di compressione.
Utilizzare un metodo di classificazione e compressione compound porta conseguentemente ai
seguenti svantaggi:
Tempi di codifica e decodifica appesantiti a causa del tempo di classificazione ed eventuale
ricostruzione dell’immagine
Rapporto di compressione diminuito a causa della necessità di effettuare diverse
compressioni per aree contenenti testo ed aree contenenti immagini naturali
45
Pattern Recognition and Applications Lab
DIEE - Università di Cagliari
R2.3
DATASET PER LA VALIDAZIONE DEGLI ALGORITMI DI
COMPRESSIONE
Progetto 3D CloudWiz
Progetto 3D CloudWiz | ATI NICE - DIEE
Sommario
Sommario..............................................................................................................................................i
Obiettivo del documento......................................................................................................................1
Descrizione dei dataset.........................................................................................................................1
i
Progetto 3D CloudWiz | ATI NICE - DIEE
Obiettivo del documento
In questo documento verranno descritti i dataset che sono stati generati per rappresentare il
contesto operativo e che sono stati utilizzati nella fase di test degli algoritmi.
Descrizione dei dataset
Per testare le performance dei codec e dei metodi di compressione specifici per immagini
composite è stato realizzato un dataset composto da video diversi fra loro rappresentanti contesti
operativi differenti.
I contesti operativi individuati rappresentano una possibile modalità di interazione di un utente
durante una sessione desktop e sono stati suddivisi in tre categorie per ciascuna delle quali è stato
creato un video specifico:
•
Testo: In questo caso il contesto operativo è quello di un utilizzo del sistema principalmente
per text editing e/o lettura di documenti prettamente testuale;
•
Immagini: In questo caso il contesto operativo è quello di visualizzazione di immagini
naturali;
•
Compound: In questo caso il contesto operativo è quello di un utilizzo del sistema nel quale
vengono visualizzati sia immagini/video che documenti testuali.
Il primo video mostra due documenti di testo. La motivazione della creazione di un simile video è
la necessità di valutare i singoli codec ed i metodi compound su immagini composte
prevalentemente da testo. Nel caso in cui i risultati forniti evidenziassero la presenza di un codec o
un metodo performante in maniera eccezionale su immagini simili, sarebbe possibile effettuare un
controllo della percentuale dello schermo occupata da testo, e nel caso in cui essa fosse maggiore
di una certa soglia, si potrebbe utilizzare direttamente il suddetto codec o metodo. Nel video,
inoltre, i due documenti di testo vengono rapidamente scorsi al fine di testare le capacità dei codec
su testi in movimento, che presentano quindi sfocature temporanee.
Il secondo video realizzato è invece composto nella sua totalità da immagini naturali, trattandosi di
un trailer cinematografico. Tale video è stato utilizzato per testare le capacità dei codec su
1
Progetto 3D CloudWiz | ATI NICE - DIEE
immagini composte da un gran numero di colori a variazione prevalentemente continua. I risultati
ottenuti dai codec su questo filmato possono essere utilizzati per definire il codec di scelta per le
sezioni contenenti immagini naturali in un’immagine composita.
A differenza dei primi due video, il terzo presenta sia aree di testo che aree contenenti immagini
naturali o immagini grafiche, ovvero un video composito. Il video composito utilizzato è suddiviso
principalmente in tre aree:
•
una zona in cui viene riprodotto un video;
•
una zona dove è presente un editor di testo;
•
una zona dove è presente un terminale dei comandi nel quale viene simulato l'inserimento
di comandi e viene effettuato lo scroll in modo da testare la codifica di testi in movimento
come nel caso del primo video.
Ciò permetterà principalmente di testare i metodi compound su delle immagini molto vicine al
caso di studio richiesto in base ai tempi, il rapporto di compressione e la qualità dell’immagine in
uscita, ma anche sul tempo necessario affinché avvenga la classificazione dei blocchi o degli strati e
sulla precisione stessa della classificazione, misurabile grazie ad un’immagine precedentemente
etichettata. Tali risultati sono riportati nella sezione in cui vengono descritti i metodi compound
applicati.
In conclusione, i risultati ottenuti dai primi due video sono particolarmente utili al fine di
selezionare i codec più adatti a codificare aree contenenti una tipologia specifica di immagini,
mentre il terzo video permette di testare più a fondo i metodi compound, su immagini tipiche del
caso di studio.
Nella seguente tabella sono riportate le caratteristiche dei video utilizzati:
Video Testo
Numero Frames
Grandezza Frame
Video Immagini
Video Composito
700
700
700
1366 x 682
1366 x 682
1366 x 682
2
Progetto 3D CloudWiz | ATI NICE - DIEE
Tabella 1 - Caratteristiche dei video.
Nella seguente figura sono riportati tre frame dei video utilizzati come dataset:
3
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 1 - In alto una snapshot del video contenente testo, al centro una snapshot del video contenente immagini
naturali e in basso una snapshot del video composito.
4
Pattern Recognition and Applications Lab
DIEE - Università di Cagliari
R2.4
MODELLO ARCHITETTURALE DI UN SISTEMA DI
COMPRESSIONE ADATTATIVA, SISTEMA DI DECISIONE PER
LA SELEZIONE DINAMICA DELL'ALGORITMO DI
COMPRESSIONE E PROTOCOLLO DI COMUNICAZIONE TRA
CLIENT E SERVER
Progetto 3D CloudWiz
Progetto 3D CloudWiz | ATI NICE - DIEE
Sommario
Sommario..............................................................................................................................................i
Obiettivo del documento......................................................................................................................1
Stato dell'arte sulla stima della banda disponibile in una connessione punto-punto............................2
Alcune definizioni fondamentali......................................................................................................3
Un secondo più accurato modello del sistema di trasmissione........................................................4
Alcune considerazioni preliminari e nuove definizioni....................................................................6
Capacità........................................................................................................................................7
Banda disponibile.......................................................................................................................10
Tipologie di traffico sulla rete....................................................................................................12
Tecniche di stima della banda.........................................................................................................12
Tecniche attive............................................................................................................................13
Tools...............................................................................................................................................24
Tool per la stima della capacità degli hop..................................................................................24
Tool per la stima della capacità di un collegamento punto-punto..............................................25
Tool per la stima della banda disponibile...................................................................................25
Qualche25 confronto..................................................................................................................26
Conclusioni.....................................................................................................................................28
Appendice A: Problematiche legate alle reti wireless....................................................................28
Rilevamento delle collisioni (CSMA/CD vs CSMA/CA)..........................................................28
MAC layer retries.......................................................................................................................30
Algoritmi di controllo della frequenza.......................................................................................30
Bibliografia.....................................................................................................................................31
Progettazione dell'architettura del sistema adattativo.........................................................................38
Specifiche implementative.............................................................................................................40
i
Progetto 3D CloudWiz | ATI NICE - DIEE
Obiettivo del documento
Scopo di questo documento è quello di delineare un modello architetturale di un sistema di
compressione adattativa, ovvero un sistema di decisione per la selezione dinamica dell'algoritmo di
compressione e protocollo di comunicazione tra client e server.
Per fare questo nel documento si procederà da prima ad illustrare lo stato dell'arte relativo alla
stima della banda disponibile in una connessione punto-punto. In base all'analisi di questo stato
dell'arte ed ai risultati illustrati nella relazione R2.2 si procederà alla progettazione di un sistema di
decisione adattativo che consenta di adattarsi al contesto operativo anche in funzione di un
protocollo di comunicazione fra client e server.
1
Progetto 3D CloudWiz | ATI NICE - DIEE
Stato dell'arte sulla stima della banda disponibile in una connessione
punto-punto
Le reti a commutazione di pacchetto1 (Packet Switching Networks), sono strutture molto complesse e
raramente sono interamente sotto il controllo di un'unica organizzazione; più spesso sono
costituite dall'insieme di tante sottoreti gestite da organizzazioni ed aziende diverse 2. Per
mascherare e rendere gestibile tale complessità vengono spesso caratterizzate attraverso pochi
indicatori, i più comuni dei quali sono banda, latenza e capacità di trasmissione (throughput).
Sin dalla loro nascita si è sentita l'esigenza di misurare la velocità di trasferimento delle
informazioni da un punto ad un altro della rete e di stimare i limiti della rete in tal senso imposti
dagli apparati fisici e/o dalle condizioni operative.
Da un lato gli utenti (intesi come sviluppatori software) sentivano l'esigenza di poter stimare la
banda disponibile per ottimizzare il trasferimento dei dati, dall'altro i gestori delle reti sentivano
tale esigenza per poter ottimizzare l'organizzazione del traffico sulla rete ( network routing planning) e
migliorare la qualità del servizio offerto ai propri clienti. Ed anche in ambito di ricerca questa
esigenza era ed è fortemente sentita sia da parte degli ingegneri che devono progettare i protocolli
di comunicazione (network protocols design), sia da quelli che devono progettare e dimensionare gli
apparati fisici che costituiscono le reti (capacity planning).
Questa varietà di soggetti si traduce in una molteplicità di obiettivi e di approcci al problema,
ognuno con un proprio punto di vista e spesso con un gergo specifico che porta ad un'ambiguità
nel linguaggio utilizzato per descriverne le carattersitiche.
Consideriamo ad esempio il termine banda :
•
se riferito ad apparati fisici prende il suo significato dall'elettromagnetismo ed indica un
intervallo di frequenze nello spettro elettromagnetico;
•
se riferito alla teoria dell'informazione diventa sinonimo di bitrate, ed indica il numero di bit
che un canale può trasportare per unità di tempo;
•
se riferito alle reti a commutazione di pacchetto indica la capacità di trasferire senza
1
Delle quali Internet è la più nota.
Ad esempio un Internet Service Provider.
2
2
Progetto 3D CloudWiz | ATI NICE - DIEE
alterazioni una determinata quantità di dati per unità di tempo 3.
E' dunque fondamentale definire con precisione
•
il punto di vista da cui si osserva il problema;
•
l'obiettivo che ci si prefigge;
•
ed il significato che si attribuisce ai termini di utilizzo comune:
in questo documento si analizzerà il problema della stima della banda disponibile
dal punto di vista di un utilizzatore della rete che vede la rete come una scatola nera,
che non ha accesso ai dettagli, alle configurazioni e ai protocolli presenti negli apparati interni,
e che può solo osservarne il comportamento ai morsetti d'ingresso e di uscita .
Nella prima parte del documento, attraverso l'illustrazione di alcuni semplici modelli teorici,
verranno definiti con buona precisione i significati dei termini che verranno utilizzati, e verranno
illustrati alcuni assunti di base necessari per capire il funzionamento degli tecniche presentate.
Verranno tuttavia omesse tutte le tecniche che prevedono interventi sugli apparati fisici 4,
modifiche ai protocolli esistenti5, l'introduzione di nuovi protocolli o modifiche all'organizzazione
della infrastruttura di distribuzione (Internet Service Provider) perché risulterebbero al di fuori delle
possibilità di intervento dell'utente finale.
Come anticipato cerchiamo di dare una definizione più precisa ed utile di alcuni termini come
connessione, canale, capacità, banda disponibile e via dicendo.
Per farlo partiremo da un modello teorico molto semplice che ci consentirà di introdurre
facilmente ed in maniera intuitiva alcune importanti nozioni, successivamente usemo un modello
lievemente più complesso per poter essere più precisi in alcune definizioni.
Alcune definizioni fondamentali
In prima approssimazione possiamo rappresentare una connessione punto-punto come un sistema
composto da tre elementi
3
Spesso indicato anche come bitrate, ovvero numero di bit al secondo.
Ad esempio sull'organizzazione delle antenne di una rete wireless, o su particolari soluzioni hardware da installare
negli apparati di un internet service provider o sulle schede di rete di un dispositivo.
5
Ad esempio l'introduzione di nuovi campi negli header di un protocollo, o di nuovi messaggi in un protocollo esistente
o delle variazioni nella sequenza e nella frequenza con cui due host si scambiano dei messaggi sia a livello fisico che di
protocollo (es. modifiche dello standard IEEE 82.11 WiFi ).
4
3
Progetto 3D CloudWiz | ATI NICE - DIEE
•
una sorgente che trasmette dei dati
•
un canale che li trasporta
•
una destinazione che li riceve
La semplicità di questo modello ci consente di concentrarci sulla definizione di alcuni concetti
fondamentali come il concetto di canale e di alcune delle sue principali caratteristiche.
Nella teoria dell'informazione, e nella conseguente teoria delle telecomunicazioni, con canale6 si
indica un mezzo di trasmissione in grado di far propagare delle onde di energia da un punto dello spazio ad
un altro punto7.
Ogni canale è caratterizzato da una certa capacità, che indica il limite superiore alla quantità di
informazioni che possono essere trasmesse su di esso e che, in base alla teoria dell'informazione, può
anche definirsi come il numero di bit che possono essere trasmessi per unità di tempo.
Nel seguito del documento ci atterremo a questa seconda definizione e indicheremo la banda
disponibile come la differenza tra la capacità del canale e la banda occupata in un dato istante , ovvero il
numero ulteriore di bit che possono essere trasmessi sul canale per unità di tempo senza saturarne la
capacità.
Fatte queste precisazioni possiamo definire con più esattezza l'obiettivo di questo documento
dicendo che stimare la banda disponibile significa stimare la quantità di ulteriori informazioni che si
possono trasmettere efficacemente sul canale senza degradare le comunicazioni esistenti .
Un secondo più accurato modello del sistema di trasmissione
In realtà possiamo rilassare alcuni assunti sul modello adottato e considerare il canale non come
ad una black-box ma come ad una gray-box, ovvero una scatola all'interno della quale possiamo
sbirciare per vedere alcune componenti (ma non tutte).
6
Secondo questo modello e secondo il punto di vista adottato, il canale rappresenta infatti la connessione punto-punto
tra client e server, ovvero l'intera infrastruttura hardware e software che inizia nell'interfaccia di rete del server e finisce
sull'interfaccia di rete del client (internet compresa).
7
Nel caso di onde elettromagnetiche, anche il vuoto (ovvero l'assenza di un mezzo fisico) consente la propagazione delle
onde e dunque costituisce un canale valido.
4
Progetto 3D CloudWiz | ATI NICE - DIEE
Sappiamo infatti che la gray-box è una rete a commutazione di pacchetto quindi, pur non potendo
alterarne la struttura e/o le impostazioni, possiamo definire meglio il modello di riferimento ed
essere più precisi nella definizione dei concetti fondamentali.
Questo
La prima osservazione che si può fare è legata alla suddivisione dell'infrastruttura di networking in
diversi livelli funzionali (layer), ognuno dei quali con compiti e scopi ben precisi.
Gli obiettivi di questo documento ci consentono di concentrarci sui livelli 8 più bassi di questa
infrastruttura, ed in particolare :
•
il livello 1 (physical layer) in cui troviamo i mezzi fisici di connessione tra apparati, e che
comprende inoltre tutte le procedure ed i protocolli necessari a garantire che un
segnale elettromagnetico possa arrivare da un apparato ad un altro;
•
il livello 2 (data-link layer) che aggiunge al precedente tutti i sistemi di controllo del
flusso di segnale e di correzione dell'errore necessari a garantire una connessione
affidabile; la connessione è indicata con il termine di link, i suoi capi prendono il nome
di nodi;
•
il livello 3 (network layer) che introduce il concetto di rete come insieme di nodi
interconnessi da mezzi fisici, fornisce ad ogni nodo un indirizzo univoco e tutte le
funzionalità necessarie per trovare il percorso migliore 9 (routing) per arrivare da un
nodo all'altro e per trasferire sequenze di dati di lunghezza variabile ( datagrams); a
questo livello il trasporto dei dati è considerato ancora inaffidabile;
•
il livello 4 (transport layer) che introduce i principali protocolli di trasporto10 che
definiscono le regole per un trasporto affidabile dei pacchetti da un nodo ad un altro.
Sfruttando questa suddivisione in livelli e focalizzando l'attenzione sul livello 3, possiamo pensare
ad una connessione punto-punto come ad una sequenza di nodi collegati tra loro , in cui ogni
8
Nella numerazione dei livelli si farà riferimento al modello ISO/OSI perché suddivide i livelli in base ad alle
funzionalità logiche. Tuttavia nella pratica si fa spesso riferimento al modello detto TCP/IP (che deve il suo nome ai
principali protocolli utilizzati) perché suddivide i livelli in base alle funzionalità implementative. I due modelli sono di
fatto equivalenti.
9
Il protocollo IP (Internet Protocol).
10
I due principali protocolli di trasporto sono il TCP (Transmission Control Protocol) che instaura una connessione
stabile tra i due capi (connection-oriented) e l'UDP (User Datagram Protocol) che invece non necessita di una
connessione stabile (connectionless).
5
Progetto 3D CloudWiz | ATI NICE - DIEE
collegamento viene indicato con il termine hop e rappresenta un collegamento logico, ovvero un
numero arbitrario di link tra apparati di livello 2.
HOP
Node
Node
Node
Link
Alcune considerazioni preliminari e nuove definizioni
Per definizione nelle reti a commutazione di pacchetto i dati non vengono inviati come un unico
blocco monolitico, bensì che vengano suddivisi in piccoli blocchi inviati singolarmente 11 e solo a
destinazione questi vengono ricombinati per ricostruire i dati originali.
Nel suo percorso ciascun pacchetto deve inoltre attraversare i livelli logici illustrati
precedentemente, dall'alto verso il basso in uscita dalla sorgente e dal basso verso l'alto in ingresso
verso la destinazione. Ad ogni passaggio di livello verso il basso ai dati provenienti dal livello
superiore viene aggiunto un header all'inizio e, opzionalmente, un footer in coda contenenti
informazioni necessarie al protocollo in uso e per l'adempimento delle funzionalità previste dal
livello che si sta attraversando.
Ad esempio al livello 3 verranno aggiunti gli indirizzi IP della macchina sorgente e di quella di
destinazione mentre al livello 2 i MAC-Address delle schede di rete e i codici per il controllo
dell'errore. Tali informazioni verranno utilizzate dall'infrastruttura di network (la gray-box) per
poter instradare e consegnare il pacchetto a destinazione, dove verranno estratte durante la
risalita dei livelli consegnando all'applicazione di destinazione i soli dati inviati dalla sorgente.
11
Ogni pacchetto può seguire un percorso diverso da quello degli altri.
6
Progetto 3D CloudWiz | ATI NICE - DIEE
Questo processo di incapsulamento dei pacchetti è quello che garantisce la grande flessibilità delle
reti a commutazione di pacchetto ma ha delle conseguenze dirette su alcune delle grandezze di
interesse per il problema in esame.
Capacità
La banda di un link (livello 1) è legata alla capacità tipica del mezzo fisico che lo costituisce (cavi in
rame, fibre ottiche, aria, vuoto, ....) e/o alle caratteristiche hardware dei trasmettitori/ricevitori
elettronici o ottici e come tale non può essre modificata.
Il processo di incapsulamento prevede, ad ogni attraversamento di livello, l'aggiunta di un header e
di un footer ai dati provenienti dai livelli superiori; riportiamo di seguito la struttura degli header IP
ed Ethernet II aggiunti rispettivamente nell'attraversamento dei livelli 3 e 2:
Illustrazione 1: Incapsulamento al livello 3 - Header IP
Illustrazione 2: Incaspsulamento al livello 2: Header Ethernet II
E' quindi naturale che, essendo fissato il numero massimo di bit per secondo che può attraversare
link fisico, l'aggiunta di nuovi bit si traduca in una riduzione del numero di bit utili12 per secondo che
possono attraversare il link e della banda apparente vista dai livelli superiori.
12
I bit di interesse per l'applicazione e l'utente.
7
Progetto 3D CloudWiz | ATI NICE - DIEE
Dunque, salendo di un livello logico 13, la banda di un hop risulta inferiore rispetto a quella
nominale dei link che lo compongono. Inoltre le dimensioni degli header e dei footer sono
determinate dai particolari protocolli in uso e dunque fuori dal controllo di un utente che vede
l'infrastruttura di rete come una gray-box.
Proviamo a stimare la differenza di capacità percepita al livello 3 rispetto alla capacità nominale di
un link fisico dovuta all'utilizzo dell'incapsulamento di tipico del frame Ethernet II.
Se indichiamo con
•
L3
la lunghezza di un pacchetto proveniente dal livello 3;
•
H2
la dimensione dell'header introdotto al livello 2;
•
C2
la capacità al livello 2
possiamo stimare che il tempo necessario per trasmettere il pacchetto proveniente dal livello 3
tenuto conto dell'overhead dovuto all'incapsulamento sarà:
T L3=
L L3 + H L2
C L2
e dunque la capacità percepita al livello 3 sarà :
C L3=C L2
1
H
1+ L2
L L3
che evidenzia come la “riduzione” di capacità sia proporzionale al rapporto tra la dimensione
dell'header e la dimensione dei dati provenienti dal livello superiore( nel nostro caso la lunghezza 14
del pacchetto IP).
Facciamo qualche esempio numerico.
L'overhead del framing di tipo Ethernet II è di 26 byte. Se consideriamo un link da 10 Mb/sec e
pacchetti IP di dimensione di 100 bytes otteniamo :
13
Al livello 2 un blocco di dati viene indicato con il termine frame mentre al livello 3 si usa il termine packet.
Tale lunghezza non è fissata a priori da nessuno standard, ma viene solitamente concordata tra gli apparati per
ottimizzare l'utilizzo del link. Il protocollo IP ha un parametro, detto maximum transmission unit o MTU che
definisce la dimensione massima dei pacchetti che possono essere inviati in un dato link. Il valore minimo di questo
valore è intorno ai 100 byte, mentre il valore massimo dipende dal tipo di mezzo che costituisce il link fisico, il valore
di default di questo valore è pari a 1500 bytes.
14
8
Progetto 3D CloudWiz | ATI NICE - DIEE
C100b =10∗
1
Mb / s=7,94 Mb/ s
26
1+
100
con una perdita netta superiore al 20%; tuttavia utilizzando il valore tipico della dimensione dei
pacchetti IP pari a 1500 bytes, otteniamo
C1500b=10∗
1
Mb/ s=9,83 Mb / s
26
1+
1500
con una riduzione della capacità inferiore al 2%.
Sulla base di queste osservazioni possiamo dare una definizione operativa della capacità C di un
hop come
il bit-rate, misurato al livello IP15, con cui un hop
può trasferire dei pacchetti IP di dimensione pari al MTU.
In una connessione punto-punto ogni hop avrà una sua capacità
Ci , dunque l'hop con la
capacità minima costituirà un collo di bottiglia e determinerà la capacità dell'intera connessione :
C path = min Ci
i=1,…,H
In altri termini
stimare la capacità di una connessione punto-punto significa
stimare la capacità dell'hop che opera da collo di bottiglia,
ovvero quello a capacità minima.
15
E' importante ricordarsi che questa misura è fatta a livello IP e dunque tiene conto solo dell'overhead del framing
Ethernet II (o comunque di livello 2), salendo di un ulteriore livello logico (ad esempio a livello TCP) dovremmo
considerare anche l'overhead legato all'incapsulamento di protocollo IP.
9
Progetto 3D CloudWiz | ATI NICE - DIEE
Banda disponibile
Inizialmente abbiamo definito la banda disponibile come la misura della porzione di capacità di un link
non ancora utilizzata. Una prima conseguenza di questa definizione è che la banda disponibile
dipende dalla quantità di pacchetti che attraversano il link istante per istante e dunque è un
parametro che varia nel tempo.
Per illustrare meglio questo aspetto facciamo alcune osservazioni assiomatiche.
Oss. 1: Il link è un mezzo fisico.
E' bene ricordare che un link è un mezzo fisico (filo di rame, fibra ottica, aria) che collega due
apparati e come tale in ogni istante può trovarsi solo in uno di due stati (che per praticità possiamo
modellare con i valori binari 0 e 1 ):
•
inattivo : nessun segnale fisico lo attraversa;
•
in trasmissione : un segnalo lo attraversa alla massima velocità possibile consentita dalla
natura del mezzo.
In altri termini, a livello fisico e in un particolare istante, la banda disponibile è pari alla capacità del
mezzo fisico oppure è nulla.
E' naturale che senza ulteriori precisazioni la banda disponibile risulta un parametro di scarso
interesse; per renderla più interessante ed utile occorre ragionare in termini statistici e
considerarla
la differenza tra la capacità e l'utilizzo medio del canale in un intervallo di tempo significativo :
1
ū (t−τ ,t ) = τ
1,2
lato che riporta un utilizzo ipotetico per un
1
Utilizzo
calcolo del tempo medio di utilizzo risulta
u(x )dx
Utilizzo di un link in un periodo T
Ad esempio, facendo riferimento al grafico a
intervallo T pari a 20 istanti di tempo, il
t
∫t− τ
ū i =0.4 → BD=1−0.4=0.6
0,8
0,6
0,4
0,2
0
Tempo
10
Progetto 3D CloudWiz | ATI NICE - DIEE
Estendendo questo ragionamento ad un Hop (sequenza di link) e ad un collegamento (sequenza di
Hop) avremo che la banda disponibile per l'intero collegamento sarà determinata dal link con
banda disponibile minore (ovvero il collo di bottiglia dell'intero collegamento)
BD i =(1−u i )C i
BD path= min BD i
→
1, …, H
Oss. 2: il collo di bottiglia di un collegamento può variare istante per istante
Ovvero, poiché la banda disponibile su ciascun link dipende dal traffico presente in un dato
periodo sul link stesso e poiché tale traffico non è costante, anche la posizione del collo di bottiglia
sul collegamento può variare nel tempo16.
Per illustrare meglio questo concetto possiamo paragonare il collegamento punto-punto ad una
sequenza di tubi di una condotta idrica:
C1
A1
C2
A2
C3
A3
Disegno 1: Capacità Nominale e Banda Disponibile: Non esiste una correlazione diretta tra queste due grandezze,
bensì la banda disponibile è una quantità che varia nel tempo in funzione del traffico sui singoli hop. Nel grafico il
tratto 1 è quello a capacità nominale minore, ma il collo di bottiglia corrisponde al tratto 3 a causa del maggior
traffico che lo attraversa.
Questa estrema variabilità renderebbe il problema della stima della banda disponibile
impraticabile, per tale ragione tutti gli algoritmi partono dall'assunto che
il traffico si mantenga stazionario sui singoli link/hop almeno per tutta la durata della misura .
Dunque l'attendibilità della stima fornita dai vari algoritmi sarà tanto maggiore quanto minore sarà
il tempo di stima. L'ipotesi di stazionarietà del traffico è infatti ragionevole per brevi intervalli di
tempo (nell'ordine di qualche secondo) ma perde progressivamente di validità all'estendersi
dell'intervallo di osservazione.
16
In linea teorica il link che costituisce il collo di bottiglia di un collegamento potrebbe variare ad ogni intervallo T.
11
Progetto 3D CloudWiz | ATI NICE - DIEE
Tipologie di traffico sulla rete
E' importante suddividere il traffico presente sulla rete in diverse tipologie perché, come vedremo
in seguito, alcune tipologie di traffico possono avere un impatto diretto e significativo sulle misure
e quindi sull'affidabilità delle tecniche che verranno illustrate.
In particolare sono tre le principali tipologie di traffico di interesse per la stima della banda
disponibile:
•
probing traffic : i pacchetti inviati sulla connessione per stimarne le caratteristiche
fondamentali;
•
crossing traffic : i pacchetti che attraversano uno o più link nella stessa direzione del probing
traffic;
•
contending traffic : i pacchetti che attraversano uno o più link in direzione opposta a quella
del probing traffic.
Queste tipologie di traffico sono illustrate nella figura seguente
Tecniche di stima della banda
Le tecniche attualmente disponibili per la stima della banda sono tutte accomunate dal fatto di
inviare sulla rete dei pacchetti di dati nella rete per sondarne le caratteristiche.
Tuttavia l'avvento delle reti wireless ha evidenziato alcuni limiti di queste tecniche e del modello su
cui si basavano ed ha dato vita ad un nuovo filone di ricerca.
Questo a sua volta ha portato ad una prima suddivisione logica delle teorie di misura in due grandi
famiglie:
•
le tecniche attive, caratterizzate dall'immissione di pacchetti nel collegamento e basate
su un modello teorico creato per le reti cablate (e che si sta cercando di adattare alle
12
Progetto 3D CloudWiz | ATI NICE - DIEE
reti wireless e mobile);
•
le tecniche passive, che si limitano a monitorare il traffico in ingresso/uscita su uno o
più nodi e che sono alla ricerca di un nuovo modello che ben si adatti anche alle nuove
tipologie di rete .
Al momento, la ricerca sulle tecniche passive di misura non è ancora arrivata al punto di avere un
unico ed efficace modello di riferimento e, conseguentemente, ad avere almeno un algoritmo di
riferimento. Sono diverse le idee promettenti legate, ad esempio, a modifiche sull'infrastruttura
fisica, a modifiche dei protocolli esistenti e/o all'introduzione di nuovi protocolli; ma nessuna ha
ancora raggiunto una maturità ed un'affidabilità tale da diventare un punto di riferimento17.
Quindi non essendo disponibili soluzioni passive implementabili ed utilizzabili dall'utente finale,
concentreremo la nostra attenzione sulle tecniche attive di misura.
Tecniche attive
Le tecniche attive si basano sull'invio di pacchetti da un estremo all'altro del collegamento e si
differenziano tra loro sia per il numero di pacchetti che per la modalità con cui questi vengono
inviati.
Le prime tecniche attive sono nate con la nascita di internet e si sono evolute in simbiosi con
l'evoluzione degli apparati fisici che ne costituivano l'infrastruttura. E' accaduto spesso che le
misure evidenziate da una tecnica suggerissero migliorie sull'hardware o sui protocolli e che,
successivamente, l'attuazione di tali migliorie abbia richiesto un'evoluzione delle tecniche di
misura o l'introduzione di una nuove tipologie di misura.
Per tale ragione nel proporre le principali tecniche cercheremo di seguire un'ordine
logico/cronologico che evidenzi le evoluzioni che ciascuna di esse ha introdotto.
Ricordiamo che alla base di tutte le tecniche c'è l'assunto che:
17
La maggior parte di esse è stata sviluppata solo attraverso simulazioni teoriche ma non è stata testata su apparati reali
o su larga scala, ad esempio una di esse (iBE = intelligent Bandwidth Estimation) si basa sulla coppia di messaggi
RTS/CTS (Ready to Send, Clear To Send) previsti dallo standard IEEE 802.11. Secondo quanto previsto ciascun
apparato prima di mandare un pacchetto dovrebbe segnalare la sua intenzione con un messaggio RTS, cui deve seguire
una conferma da parte della destinazione attraverso il messaggio CTS. Nel frattempo tutti gli altri dispositivi
dovrebbero interrompere le trasmissioni per evitare conflitti. Tuttavia è stato dimostrato che l'uso di questi messaggi
degrada le performance dell'intero sistema e dunque sono stati declassati a “configurazione opzionale” e disabilitati per
default in tutti i dispositivi. Questo rende di fatto inutilizzabile l'algoritmo citato. In un altro caso l'algoritmo si basa su
una modifica ad un driver open-source per una scheda di rete wireless il cui utilizzo e funzionamento non mai andato
oltre il semplice test effettuato per la pubblicazione esaminata.
13
Progetto 3D CloudWiz | ATI NICE - DIEE
durante il tempo di misura la capacità fisica, il traffico (e dunque la banda disponibile)
in tutti i link del collegamento si mantengano costanti.
Invio di pacchetti di lunghezza variabile (VPS)
Questa fu una delle prime tecniche 18 per la misura della capacità e della latenza di ogni hop lungo
tutto il collegamento. Sfruttando una profonda conoscenza dei protocolli, utilizza in modo originale
il campo TTL (Time To Live) dell'header di un pacchetto IP per acquisire le informazioni desiderate.
Il campo TTL indica il numero massimo di hop che un pacchetto può attraversare e ad ogni
attraversamento viene decrementato, quando raggiunge lo zero il pacchetto viene scartato 19. Il
protocollo IP prevede che il router che scarta un pacchetto deve segnalare l'evento al mittente
inviando un messaggio di notifica (ICMP Time-Exceeded).
L'idea è quella di calcolare il RTT ( Round Trip Time) forzando questo meccanismo attraverso l'invio
nella rete di pacchetti con un TTL crescente (da 1 a N); in questo modo l'n-esimo router nel
percorso sarà costretto a scartare il pacchetto e ad indentificarsi mandando il messaggio di
notifica.
Le principali componenti temporali del RTT (in entrambe le direzioni) sono tre:
•
il tempo di serializzazione, cioé il tempo richiesto per trasferire un pacchetto di
lunghezza L da un link di capacità C e può essere indicato con L/C;
•
il tempo di propagazione, è il tempo richiesto ad ogni bit del pacchetto per attraversare
il link ed è indipendente dalle dimensioni del pacchetto;
•
il tempo di attesa in coda, misura il tempo che un pacchetto può restare fermo in un
buffer di un router o di uno switch.
Per stimare questi parametri ad ogni dispositivo di livello 3 (router) lungo il percorso vengono
inviati più pacchetti della stessa dimensione assumendo che almeno uno di essi 20 non subisca alcun
ritardo dovuto a problemi di accodamento.
Con questo assunto nel minimo degli RTT misurati si potranno considerare solo le due componenti
18
Uno tra i primi a proporre questa tecnica ed una sua implementazione (pathchar) fu Van Jacobson autore, tra le altre
cose, della prima versione del tool traceroute,ancora oggi disponibile su tutti i sistemi linux/unix e Windows.
19
Questo campo è stato introdotto nell'header dei pacchetti IP per evitare che se in una rete si dovesse creare un loop un
pacchetto possa restare indefinitamente in circolo, ad esempio per un guasto o un errore di configurazione.
sovraccaricando gli apparati e degradando le performance generali.
20
Si assume inoltre che il pacchetto ICMP di risposta, essendo molto più piccolo degli altri, non subisca alcun ritardo
dovuto a code nel percorso di ritorno.
14
Progetto 3D CloudWiz | ATI NICE - DIEE
di propagazione e serializzazione; di cui
•
la prima indipendente dalla dimensione del pacchetto e legata solo alla velocità di
propagazione dei segnali nei vari link
•
e la seconda proporzionale alla lunghezza del pacchetto e dovuta alla serializzazione
dello stesso nei vari link.
In formule il minimo RTT per un pacchetto di dimensione L all'hop i-esimo può essere espresso
dalla formula:
i
L
= α+βi L
k =1 C k
T i ( L) = α+∑
dove
•
Ck
•
α
è la capacità del k-esimo hop
è la componente di ritardo fino all'hop i-esimo che non dipende dalla dimensione
del pacchetto
•
βi
è la pendenza all'i-esimo hop del rapporto tra il minimo RTT e la dimensione del
pacchetto (vedi figura).
Dunque la misura del minimo RTT per ogni dimensione del pacchetto stima il termine
βi
per
tutti gli hop, da cui si può stimare la capacità dell'i-esimo hop attraverso la formula
1
C i = β −β
i
i−1
Questa tecnica può significativamente sottostimare la capacità del collegamento se lungo il
15
Progetto 3D CloudWiz | ATI NICE - DIEE
percorso i pacchetti devono attraversare dispositivi di tipo store-and-forward21 (ad esempio switch).
Dispersione di coppie/treni di pacchetti (PPTD)
Per superare i limiti legati all'invio di un solo pacchetto, si è passati all'invio di una coppia di
pacchetti, composta da due pacchetti di uguale dimensione leggermente distanziati nel tempo, con
l'obiettivo di misurare la variazione (tra sorgente e destinazione) della distanza temporale tra i due
pacchetti. E successivamente si è passati da una coppia pacchetti ad una serie di pacchetti, detta
treno di pacchetti.
L'idea alla base di questa tecnica è che tale variazione della distanza tra i due pacchetti sia
proporzionale alla capacità del tratto di percorso che opera come collo di bottiglia nel
collegamento. Questo concetto è illustrato qualitativamente nella figura seguente:
Illustrazione 3: Dispersione di una coppia di pacchetti che attraversa un collo di bottiglia
in cui l'asse orizzontale rappresenta il tempo e quello verticale la banda. Nel complesso è
raffigurato un collegamento composto da tre hop, in cui quello centrale ha una banda molto
inferiore agli altri due.
Ogni rettangolo in grigio rappresenta un pacchetto, la cui area (pari al numero di bit) non può
cambiare lungo l'intero percorso.
Durante l'attraversamento dell'hop centrale a banda stretta il pacchetto subirà uno
“schiacciamento” lungo l'asse verticale (banda) e quindi dovrà allargarsi orizzontalmente (nel
tempo) e, dualmente, arrivando nuovamente ad un hop a banda larga verrà “stirato” verticalmente
21
La metodologia store-and-forward è una metologia di instradamento dei pacchetti che prevede che il primo bit di un
pacchetto venga inviato solo dopo che l'ultimo bit sia stato ricevuto. In particolare se il dispositivo è uno switch questa
tecnica prevede che al frame conservato nel buffer venga applicata una verifica d'integrità, cosa che introduce in ogni
caso una latenza che altera le stime VPS. Inoltre se tale verifica fallisce il frame viene scartato e lo switch (essendo un
dispositivo di livello 2) non genera il messaggio di notifica ICMP danneggiando ulteriormente le stime. Per
approfondimenti http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/white_paper_c11-465436.html
16
Progetto 3D CloudWiz | ATI NICE - DIEE
e subirà una compressione lungo l'asse orizzontale.
La spaziatura
Pb
tra i due pacchetti creata nel link a banda più stretta (collo di bottiglia) rimane
invariata22 anche quando i pacchetti raggiungono i link a banda più elevata, perciò la spaziatura tra
i pacchetti in ricezione sarà pari alla distanza nel link a banda più stretta:
P r =P b .
Possiamo schematizzare ciò che accade in ogni apparato in questo modo
ed indicare la dispersione tra due pacchetti di lunghezza L al termine di un link con capacità C
come
(
Δ out = max Δ in ,
L
Ci
)
sotto l'assunto che in quel periodo temporale non ci sia altro traffico sul link.
In definitiva la dispersione della coppia di pacchetti al termine del collegamento sarà:
Δ R = max
i=0,…, H
( )
L
Ci
=
L
L
=
min C i
C
i=0,… , H
→
L
C = Δ
R
Tuttavia l'ipotesi di assenza di altro traffico sull'intero collegamento è piuttosto irrealistica e risulta
particolarmente rilevante la presenza di cross traffic che può condurre a:
•
sottostimare la capacità, se i pacchetti estranei ritardano il secondo pacchetto e non il
primo, aumentando la dispersione di un valore superiore a L/C;
•
sovrastimare la capacità, se i pacchetti estranei ritardano la propagazione, sul link
successivo al collo di bottiglia, del primo pacchetto e non quella del secondo.
22
E' stato dimostrato che in questa situazione la rete “satura” e si comporta in maniera equivalente ad un sistema storeand-forward, ovvero non invia un pacchetto fino a che non sia stato completamente ricevuto.
17
Progetto 3D CloudWiz | ATI NICE - DIEE
Per cercare di limitare questi errori sono state proposte varie metodologie accessorie:
•
l'uso di parametri statistici come la media o la mediana;
•
l'uso di pacchetti di dimensione variabile;
•
l'uso di distanze variabili tra pacchetti;
•
l'uso della varianza tra i ritardi di diverse coppie di pacchetti;
•
l'uso dei valori di picco della distanza tra pacchetti.
Treni di pacchetti
Una delle più naturali estensioni all'uso di una coppia di pacchetti è l'uso di un treno di pacchetti23, la
cui dispersione è definita come
la distanza temporale tra l'ultimo bit del primo pacchetto e l'ultimo bit dell'ultimo pacchetto .
Misurando la dispersione
Δ R (N ) di un treno di N pacchetti di lunghezza L, si può stimare la
banda con la seguente equazione:
B =
(N −1) L
ΔR ( N )
che se non ci fosse cross traffic coinciderebbe con la capacità del canale.
In generale l'uso di un treno di pacchetti dovrebbe rendere più robusta la misura, tuttavia al
crescere della lunghezza del treno di pacchetti aumenta la probabilità che sia presente del cross
traffic durante la misura e quindi la probabilità di sottostima (anche significativa) della capacità del
collegamento.
Per avere una stima più precisa della banda utilizzando un treno di pacchetti è stato introdotto
l'operatore ADR (Asymptotic Dispersion Rate) che nel caso di un collegamento con un singolo hop
P {C 0 ,C 1 } , C 0 >C 1 , assume la seguente forma:
ADR Δ
=
C1
⩽ C1
RC
1−
C0
23
Un treno di pacchetti consente misure statistiche più accurate e si rende addirittura necessario se nel collegamento
sono presenti dei multi-channel link, ovvero quando più link fisici sono accorpati per formare un unico link logico con
una banda maggiore.
18
Progetto 3D CloudWiz | ATI NICE - DIEE
dove
C 0 , C 1 sono le capacità dei due hop e
R C è la quantità di cross-traffic che arriva sul
secondo link. Si possono notare alcune caratteristiche:
•
la lunghezza del treno di pacchetti non influenza l'ADR (tuttavia ne limita la varianza);
•
se
•
l'ADR non è legata alla banda disponibile ed anzi è più ampia:
R C >0
→
ADR < C
ADR > A = C 1−RC
Purtroppo l'ADR richiede la conoscenza del cross-traffic presente su tutti i link.
Stream Periodici (SloPS)
Questa tecnica nasce dall'osservazione che inviando un treno di K pacchetti di lunghezza L con una
frequenza R superiore alla banda disponibile A, a destinazione la distanza tra due pacchetti consecutivi di
uno stesso treno crescerà in maniera lineare.
Osservando la figura seguente possiamo notare facilmente che fintanto che R<A il ritardo rilevato
si mantiene quasi costante, mentre quando R>A i pacchetti continueranno ad accumularsi nella
coda del link a banda più stretta ed il ritardo misurato a destinazione aumenterà
proporzionalmente.
Illustrazione 4: Andamento del ritardo rilevato nei casi in cui R<A o R>A
Per trovare il valore R=A per cui i pacchetti iniziano ad accodarsi l'algoritmo prevede che la
sorgente invii alla destinazione diversi treni di pacchetti a frequenze diverse, aumentando o
diminuendo la frequenza in base alle stime effettuate dal ricevente secondo lo schema di una
ricerca binaria.
19
Progetto 3D CloudWiz | ATI NICE - DIEE
Treni di coppie di pacchetti (TOPP)
Questa tecnica è simile alla SloPS e differisce principalmente per le analisi statistiche sulle misure
raccolte. La tecnica TOPP prevede di inviare delle coppie di pacchetti dalla sorgente alla
destinazione, incrementando progressivamente la frequenza con cui le coppie vengono inviate.
Se la frequenza di invio
R0
dei pacchetti è tale da non saturare la banda disponibile A allora la
frequenza di arrivo, misurata a destinazione,
appena R 0> A
→
R m , sarà uguale a quella di invio. Tuttavia, non
Rm < R 0 .
Consideriamo un percorso di capacità C e banda disponibile A, in presenza di cross-traffic pari a
R C =C−A , se tracciamo l'andamento del rapporto tra frequenza di ricezione e frequenza di
invio
R0 / Rm
certo valore di
al crescere della frequenza di invio, avremo un andamento orizzontale fino ad un
R0
e poi una crescita lineare dovuta all'effetto dell'accodamento dei pacchetti. Il
punto in cui cambia la pendenza coincide con la banda disponibile:
Per capire meglio come funziona osserviamo che non appena
frequenza misurata non sarà più pari a
Rm =
R 0 supera la banda disponibile la
R 0 ma
R0
C
R 0+ R C
→
R0
R +R
= 0 C
Rm
C
TOPP stima la banda disponibile come il valore massimo di
R 0 per il quale
R m ≈ R0 .
L'ultima relazione ci consente di stimare la capacità in funzione della pendenza del rapporto
R 0 / R m , inoltre nel caso di collegamenti con più link è possibile che la curva
R 0 / R m presenti
diverse pendenze dovute alla saturazione di diversi link 24
24
Questo è vero se e solo se i link che hanno via via una banda disponibile superiore si trovano prima del precedente
20
Progetto 3D CloudWiz | ATI NICE - DIEE
Sequenze di coppie di pacchetti e Kalman Filters
Un'altra tecnica simile a TOPP e SloPS prevede l'uso di filtri di Kalman per la stima della banda
disponibile e si basa sulla definizione di una nuova misura: la deformazione della distanza tra due
pacchetti. Vediamo di darne una definizione precisa.
Consideriamo la i-esima coppia di pacchetti di una sequenza ed indichiamo:
•
con τ i1 , τi2 i tempi di arrivo dei due pacchetti ad un generico hop;
•
con τ *i1 , τ*i2 i loro tempi di arrivo all'hop successivo.
Non siamo interessati tanto al loro valore assoluto quanto alla differenza del tempo di arrivo tra i
due pacchetti
t i = τ i2 −τ i1
t *i = τ *i2 −τ *i1
e alla differenza tra questi due valori
δ = t *i −t i
che ci consente di definire la deformazione della distanza tra due pacchetti come
1+εi =
t *i
ti
→
εi =
Indicando infatti
•
con s la dimensione dei pacchetti;
•
con u= t la frequenza di invio dei pacchetti;
i
•
e con r =
s
s
t *i
quella di ricezione;
possiamo ricavare la relazione
collo di bottiglia (altrimenti non potrebbero giungere a saturazione).
21
δi
ti
Progetto 3D CloudWiz | ATI NICE - DIEE
s / ti
t *i
u
= 1+εi
=
=
r
ti
s / t *i
La deviazione di questo rapporto dall'unità è pari alla deviazione di ε dallo zero.
Tracciando il grafico di
ε in funzione della frequenza di invio dei pacchetti si nota subito
l'analogia con la tecnica TOPP:
L'idea è dunque quella di utilizzare i filtri di Kalman per stimare a quale frequenza di invio ε inizia
a discostarsi dallo zero.
Per farlo si considera il collegamento come una black-box descritta da un vettore di stato x, si
indica con u la frequenza di invio dei pacchetti, con z la deformazione della distanza tra i pacchetti,
con w il rumore presente nel sistema e con v il rumore di misura. In questo modo si possono
indicare l'evoluzione nel tempo del sistema e delle misure rispettivamente con
x k +1 = g (x k , u k , w k ) = x +w
zk
{
= f (x k , u k , v k ) = v + 0
α u +β
Un filtro è una procedura che prende in ingresso
x̂k e produce una stima del prossimo stato
stimare la banda con la relazione
}
(u⩽B)
(u> B)
u k , z k ed una stima dello stato del sistema
x ̂k +1 . Ottenendo delle stime
α̂ , β̂ è possibile
β̂ .
̂
B=−
α̂
Dunque a partire da una stima iniziale il modello viene via via aggiornato e dopo un tempo iniziale
di convergenza è in grado di fornire una stima in tempo reale della banda disponibile.
22
Progetto 3D CloudWiz | ATI NICE - DIEE
Treni di pacchetti esponenzialmente distanziati (chirp)
L'ultima variante al treno di pacchetti prevede l'uso di pacchetti con spaziatura esponenzialmente
decrescente (denominati chirp):
In maniera simile a TOPP, l'idea è di raggiungere progressivamente la saturazione della rete e
verificare a quale frequenza di invio dei pacchetti la distanza di ricezione di discosta da quella in
invio. Tuttavia in questo caso si può sfruttare la spaziatura esponenziale per ottenere lo stesso
risultato con un numero molto inferiore di pacchetti, riducendo così sia l'intrusività dell'algoritmo
che i tempi di convergenza.
La sorgente invia m treni di pacchetti (chirp) composti ognuno da N pacchetti di dimensione P. I
pacchetti hanno tutti la stessa dimensione e la stessa spaziatura all'interno dei vari chirp, per cui i
valori associati ad ogni pacchetto sono calcolati come media dei valori rilevati sugli m chirp
ricevuti. Possiamo indicare
•
con
γ
il fattore di distanza tra pacchetti;
•
con
qk
quello dovuto alle code per il pacchetto k-esimo;
•
con Δ k la distanza temporale tra pacchetto consecutivi;
•
con R k = Δ
k
P
la frequenza istantanea del chirp al pacchetto k-esimo.
Assumendo che il cross-traffic sia stazionario abbiamo che
23
Progetto 3D CloudWiz | ATI NICE - DIEE
q k =0
q k >q k −1 0
da cui si può stimare la banda disponibile
se
se
R k ⩽B
Rk > B
̂
B=R k * dove
k*
è il pacchetto in cui inizia la
crescita del fattore di accodamento.
Illustrazione 5: Tipica traccia dei ritardi di accodamento
dei pacchetti di un chirp
Osservando l'illustrazione 3 si può notare come ad un certo punto il fattore di accodamento cresca
per un breve periodo per poi ritornare allo zero; questo fenomeno, detto escursione, è legato
all'insorgere in un link del collegamento di un traffico extra di tipo burst (cioè intenso ma di breve
durata). Tuttavia essendo ancora il rate di invio inferiore alla banda disponibile, dopo un breve
periodo le code si svuotano e i valori di accodamento ritornano alla normalità.
Per individuare la banda disponibile il client tiene dunque conto di questa eventualità e non si
limita a considerare il primo valore per cui
q k <q k −1 (che potrebbe corrispondere ad una
escursione) ma cerca quel valore di k a partire dal quale il valore di q k non decresce più.
Tools
Originariamente ad ogni tecnica corrispondeva un tool che la implementava tale e quale.
Con il passare del tempo sempre più spesso sono stati sviluppati tool che implementavano più di
una delle tecniche disponibili e/o le fondevano assieme per cercare di superare i limiti di ciascuna.
Riportiamo di seguito un breve resoconto dei principali tool disponibili per la stima della banda
disponibile attraverso tecniche attive.
Tool per la stima della capacità degli hop
Sono sostanzialmente tool che utilizzano la tecnica VPS. Il primo tool ad implementarla fu
pathchar, scritto dallo stesso Van Jacobson (ideatore di questa tecnica) nel 1997. Altri tool ad
implementare questa tecnica sono Clink e Pchar che tuttavia non introdussero sostanziali
24
Progetto 3D CloudWiz | ATI NICE - DIEE
innovazioni.
Tool per la stima della capacità di un collegamento punto-punto
Questi tool tentano di stimare la capacità del collo di bottiglia dell'intero collegamento; la maggior
parte di essi utilizza la dispersione di una coppia di pacchetti.
Bprobe usa coppie di pacchetti di dimensione variabile per cercare di aumentare la precisione e
applica dei filtri per cercare di rigettare i pacchetti le cui misure presentano un'elevata probabilità
di esser state influenzate da cross-traffic.
Nettimer utilizza una sofisticata tecnica statistica, denominata kernel density estimation, per
stimare il modo dominante nella distribuzione delle misure dei pacchetti e cercare di superare i
limiti tipici delle tecniche basate su istogrammi.
Pathrate usa diverse misure, ottenute mediante coppie di pacchetti di diversa dimensione, per
stimare tutti i modi locali (uno dei quali corrisponde alla capacità del collegamento).
Successivamente utilizza dei lunghi treni di pacchetti per stimare la frequenza media di dispersione
(Average Dispersion Rate ADR) che risulta sempre inferiore o uguale alla capacità e quindi può
essere considerato un limite inferiore della capacità del collegamento.
Sprobe sfrutta le caratteristiche del protocollo TCP per stimare la banda. La sorgente invia alcune
coppie di pacchetti TCP SYN (cui aggiunge un payload superiore al MTU, per aumentare la
probabilità di accodamento). Il protocollo TCP prevede che la destinazione che risponda ai
pacchetti SYN con dei pacchetti TCP RST (che occupano 40 bytes ed hanno una bassa probabilità di
essere accodati nel cammino di rientro). In questo modo la sorgente riesce a stimare la dispersione
sul collegamento e dunque la capacità. In alcuni casi può stimare anche la banda in direzione
inversa (dalla destinazione alla sorgente) attraverso l'invio di un piccolo file.
AdHoc Probe è una variante del tool CapProbe (vedi sotto) orientato alla stima della massima
velocità di trasferimento in un collegamento punto-punto che includa componenti wireless, ma in
assenza di competing-traffic. A differenza di CapProbe è unidirezionale e i pacchetti vengono inviati
dalla sorgente alla destinazione e qui vengono effettuate le stime.
Tool per la stima della banda disponibile
Il primo tool a cercare di stimare la banda disponibile è stato Cprobe che utilizza un treno di 8
pacchetti di dimensione pari al MTU. Tuttavia è stato dimostrato che questo approccio misura la
25
Progetto 3D CloudWiz | ATI NICE - DIEE
frequenza di dispersione che è diversa dalla banda disponibile in quanto la prima dipende
dall'intero collegamento e dalla frequenza iniziale del treno di pacchetti, mentre la banda
disponibile è legata solo al link più “stretto”.
CapProbe utilizza delle coppie di pacchetti inviati dalla sorgente alla destinazione e poi rimandati
indietro (round-trip), ma oltre a considerare la dispersione dei pacchetti utilizza anche i ritardi
complessivi per identificare (e scartare) i pacchetti che sono stati influenzati da cross-traffic.
Pathload invece utilizza la tecnica SloPS e restituisce un intervallo di valori, il cui centro indica il
valor medio della banda disponibile durante l'intervallo di misura, mentre gli estremi danno una
stima della variabilità di questa misura.
Altri tool come IGI, che usa la tecnica TOPP, o pathchirp, che usa sequenze di chirp, hanno cercato
di modificare la tipologia di pacchetti e la modalità di invio per ottenere la stessa precisione di
Pathload ma con un numero minore di pacchetti e/o un tempo di convergenza inferiore.
BART fa uso dei filtri di Kalman per fornire una stima in tempo reale della banda disponibile sul
collo di bottiglia del collegamento; esiste anche una sua variante, denominata Multi-rate Bart o
MR-BART, che varia la frequenza di invio delle coppie di pacchetti anche all'interno di una stessa
sequenza per aumentare la precisione della stima.
WBest, è un algoritmo suddiviso in due fasi ed ottimizzato per massimizzare l'accuratezza
minimizzando il tempo di convergenza e l'intrusività (cioè il numero di pacchetti da inviare sul
canale). Nella prima fase vengono inviate N coppie di pacchetti per stimare la capacità del canale,
successivamente viene inviato un treno di pacchetti alla massima velocità stimata per calcolare il
trhoughput reale e la banda disponibile.
Qualche25 confronto
Per completare il panorama dei tool presentati riportiamo in alcune tabelle alcuni valori di
confronto tra le stime dei principali algoritmi in diverse condizioni operative.
I valori riportati sono tratti da alcuni degli articoli riportati in bibliografia, in quanto non sarebbe
stato possibile effettuare tutte le necessarie simulazioni (sia per la non disponibilità degli eseguibili
25
Non per tutti gli algoritmi erano disponibili dati utili per un confronto perché in molti casi le pubblicazioni riportavano
risultati di simulazioni effettuate per verificare la capacità di un dato algoritmo di stimare la banda in un ambiente
simulato ma quest'ultimo non veniva testato in un contesto reale e/o confrontato con altri algoritmi che potessero fornire
dei riferimenti. Abbiamo dunque riportato i dati disponibili sugli algoritmi che abbiamo ritenuto più interessanti (perché
citati come modello o termine di paragone in molte pubblicazioni).
26
Progetto 3D CloudWiz | ATI NICE - DIEE
di molti dei tool citati, sia per la difficoltà oggettiva di ricreare un'infrastruttura di test in grado di
riprodurre tutte le condizioni operative richieste per evidenziare le diverse criticità di
funzionamento).
Precisione della stima
Riportiamo di seguito alcuni test effettuati 26 di diversi algoritmi, in condizioni operative diverse
(canale libero, cross-traffic, contending-traffic (UDP/TCP) ), su uno stesso collegamento composto
da reti cablate ed avente come ultimo hop un collegamento wireless. Tutti i valori riportati sono
corrispondono al valor medio su 30 misure.
Banda Reale
IGI/PTR
PathLoad
PatChirp
WBest
1
Idle channel
28.94
8.11
6.78
30.15
28.47
2
Cross traffic
24.39
8.74
6.81
28.89
23.24
3
Contending
traffic
20.52
10.06
6.91
27.59
15.76
4
Saturated
0.0
1.92
1.95
5.00
1.01
5
Rate adapation
15.26
5.99
6.47
16.79
13.99
Intrusività e tempo di convergenza
Riportiamo di seguito i tempi di convergenza (in secondi) e l'intrusività (rapporto tra pacchetti di
misura e pacchetti utili inviati) relativi agli esempi precedenti
IGI/PTR
PathLoad
PatChirp
WBest
intrus.
tempo
intrus.
tempo
intrus.
tempo
intrus.
tempo
1
0.56
1.55
1.18
14.88
0.45
17.43
0.13
0.41
2
0.56
1.42
1.55
20.22
0.45
17.58
0.13
0.42
3
0.47
1.29
1.53
17.04
0.45
17.62
0.13
0.42
4
2.54
17.21
1.22
42.06
0.46
17.24
0.13
0.67
5
0.66
1.86
1.66
23.73
0.45
17.48
0.13
0.42
26
Un algoritmo interessante e promettente era BART (soprattutto nella sua variante MR-BART), purtroppo nelle
pubblicazioni di presentazione degli algoritmi non erano presenti test comparativi che consentissero un facile confronto
con altri algoritmi e non si è trovata un'implementazione da testare per stimarne il reale comportamento.
27
Progetto 3D CloudWiz | ATI NICE - DIEE
Conclusioni
Osservando i dati in tabella si nota subito come sia IGI/PTR che Pathload sottostimino
significativamente l'ampiezza di banda in caso di canale libero, mentre sia Patchirp che Wbest
rescono a dare una stima piuttosto accurata.
Una possibile ragione di questo può essere che l'overhead dovuto all'invio di pacchetti di test su
reti wireless è maggiore rispetto a quello che si ha in reti cablate (a testimonianza delle
problematiche introdotte da questo tipo di reti su algoritmi basati sul modello teorico studiato per
reti cablate); inoltre la dimensione dei pacchetti usata da questi tool è piccola rispetto al MTU (500
bytes IGI, 200 bytes Pathload).
Osservando la seconda tabella si può notare che PathChirp e PathLoad hanno tempi di
convergenza piuttosto lunghi. Questo può causare dei problemi in situazioni come il caso 5 di
banda variabile (ad esempio per disturbi sulla rete wireless). In questo caso Pathchirp tende a
sovrastimare la banda disponibile ed anche se la differenza in valore assoluto è simile a quella di
Wbest l'errore è più grave perché potrebbe portare ad una saturazione del collegamento e ad un
crollo della Quality Of Services.
In base a queste osservazioni, considerando la minore intrusività, i bassi tempi di convergenza e la
disponibilità del codice sorgente riteniamo che Wbest sia il miglior candidato tra i tool disponibili
per l'implementazione di un sistema network-aware con monitoraggio attivo della banda
disponibile.
Appendice A: Problematiche legate alle reti wireless
Le reti wireless hanno un'infrastruttura ed un funzionamento più complessi rispetto alle
tradizionali reti cablate, per cui molte delle idee che costituiscono il fondamento delle tecniche
precedenti possono risultare inadeguate se applicate direttamente, senza opportuni accorgimenti.
Vediamo alcuni problemi legati all'applicazione di queste tecniche alle reti wireless.
Rilevamento delle collisioni (CSMA/CD vs CSMA/CA)
Una generica interfaccia di rete (cablata o wireless) prima di inviare un frame si mette in ascolto sul
canale di trasmissione per capire se questo è libero o meno. Se c'è una trasmissione in corso si
mette in attesa e non appena il canale si libera inizia l'invio del proprio frame.
Questa fase viene indicata dalle lettere CS (Carrier Sense) degli acronimi precedenti ed è comune
28
Progetto 3D CloudWiz | ATI NICE - DIEE
ad entrambe le tipologie di rete.
In una rete complessa dove ci sono più di due macchine collegate è possibile (anzi probabile) che
più dispositivi possano inviare frame e pacchetti sullo stesso canale (MA = Multiple Access).
Questa condizione può dare origine a delle collisioni, infatti quando un'interfaccia di rete, dopo
aver atteso che il canale si liberasse, inizia a trasmettere il proprio frame c'è il rischio che un'altra
interfaccia abbia seguito lo stesso iter ed inizi a sua volta una trasmissione 27.
Quando questo accade si ha una collisione, ovvero i due segnali (elettrici, ottici, elettromagnetici)
si sovrappongono sul mezzo fisico distruggendo le informazioni portate da entrambe i segnali e i
frame andranno ritrasmessi.
Qui le due tipologie di rete si differenziano.
Nelle reti cablate l'interfaccia di rete può mettersi in ascolto sul canale anche durante la
trasmissione, accorgersi di una collisione (che si manifesta con dei picchi di segnale) e intervenire
immediatamente28 (CD = Collision Detection).
In una rete wireless la scheda di rete non è in grado di mettersi in ascolto durante la trasmissione e
quindi non potendo accorgersi di una eventuale collisione può solo cercare di evitarla 29 (CA =
Collision Avoidance).
Questo limite diventa ancora più significativo se si considera che nelle reti cablate il canale è un filo
elettrico isolato dal resto del sistema e quindi le possibilità di collisione sono dovute
esclusivamente ad una trasmissione concorrente; di contro in una rete wireless il canale è
condiviso e conteso da altre reti ed altri sistemi, dunque la probabilità di collisioni dovute anche ad
27
Per minimizzare la probabilità di collisioni lo standard 802.11 prevede l'uso di una coppia di messaggi RTS/CTS
(Ready-To-Send / Clear-To-Send). Quando un terminale è pronto ad inviare sul canale un frame, invia preventivametne
al router un pacchetto RTS. Il router seleziona (in caso di più RTS) un dispositivo e invia una risposta CTS in broadcast
a tutti i dispositivi indicando quale dispositivo è abilitato all'invio. Il dispositivo selezionato invierà il frame mentre gli
altri attenderanno che il canale torni libero. Tuttavia è stato dimostrato che in molti casi l'overhead imposto da questo
protocollo ha un effetto negativo sulle performance del sistema e di conseguenza questo meccanismo è quasi sempre
disabilitato.
28
Il protocollo prevede che venga inviato un segnale con una codifica particolare, detto JAM signal, per avvisare tutte le
reti in ascolto dell'avvenuta collisione. A seguito di un segnale di JA tutte le interfacce di rete iniziano un periodo
backoff (silenzio) la cui durata è determinata casualmente da ogni scheda per minimizzare il rischio di ulteriori
collisioni.
29
In questo caso il protocollo prevede che il ricevente dopo aver ricevuto e verificato il frame invii un segnale di ACK
(acknowledgment) al mittente. In caso di mancato ricevimento dell'ACK il mittente suppone che vi sia stata una
collisione, inizia un periodo di backoff preventivo (la cui durata è stabilita casualmente nell'intervallo [0..CW), CW =
Contention Window ed è una stima del livello di contesa sul canale) e poi reinvia il frame. In caso di collisioni
successive il valore di CW viene raddoppiato e dunque anche la durata del backoff ha una crescita esponenziale.
29
Progetto 3D CloudWiz | ATI NICE - DIEE
interferenze esterne è molto più elevata30.
MAC layer retries
Per mascherare parzialmente questa fragilità delle reti wireless lo standard 802.11 definisce un
meccanismo denominato MAC layer retries che prevede che sia l'hardware stesso ad effettuare un
certo numero di tentativi di ritrasmissione dei frame prima di notificare ai layer superiori il
fallimento dell'invio.
Questo da un lato minimizza il numero di frame persi aumentando l'affidabilità della rete, ma
dall'altro aumenta la varianza associata al ritardo di trasmissione, avvicinando questa grandezza ad
una variabile aleatoria, e rischia di rendere inconsistenti le misure della dispersione su coppie di
pacchetti.
Infatti la dispersione in una coppia di pacchetti, a causa di questo fenomeno, può essere contratta
od espansa durante l'attraversamento di un link wireless anche in assenza di congestione sulla rete
(ad esempio per la presenza momentanea di contending traffic).
Algoritmi di controllo della frequenza
Un ulteriore elemento di aleatorietà delle reti wireless è dovuto al fatto che lo standard 802.11
prevede che i dispositivi siano in grado di negoziare automaticamente la velocità di trasmissione (e
dunque la capacità di un collegamento) tuttavia non definisce un algoritmo RCA ( Rate Control
Algorithm), ovvero non specifica le misure (ad esempio la potenza di segnale, il numero di
ritrasmissioni, il numero di errori di trasmissione o altro) e le regole con cui variarla, lasciando ogni
costruttore libero di implementare il proprio algoritmo31.
Questo aumenta l'aleatorietà delle stime perché non si sa a priori quale algoritmo stia operando e
soprattutto perché viola il presupposto che la capacità del canale rimanga costante per tutto il
30
Le possibili cause di interferenza e disturbo di una rete wireless sono innumerevoli, a partire dal movimento di un
dispositivo (router o PC) che aumentando la distanza può ridurre la potenza del segnale e di conseguenza la capacità del
canale, o equivalentemente al passaggio di persone od oggetti che possono frapporsi tra il trasmittente ed il ricevemente,
all'attivazione di altri router nelle vicinanze che pur appartenendo a reti diverse occupano la stessa porzione dello
spettro elettromagnetico, all'attivazione di oggetti che pur non essendo specificamente pensati per l'invio/ricezione di
segnali sono in grado di generare interferenze elettromagnetiche, e via dicendo. La maggior parte di questi “disturbi”
non sono sotto il nostro controllo e sono pertanto assolutamente imprevedibili.
31
Uno dei più diffusi algoritmi commerciali è l'ARF (Auto Rate Fallback) che in condizioni normali è in grado di
migliorare notevolmente le performance rispetto ad una installazione 802.11 a banda fissa, tuttavia è stato dimostrato
che in caso di link congestionati questo algoritmo ha un impatto negativo sulle performance complessive. Un altro
algoritmo è lo RBAR (Receiver Based Auto Rate) che però si basa sulla coppia di messaggi RTS/CTS e quindi
raramente è applicabile.
30
Progetto 3D CloudWiz | ATI NICE - DIEE
periodo della stima.
Bibliografia
1. V. Jacobson, “Congestion Avoidance And Control”, in SIGCOMM Computer Communication
Review, ACM, 1988
2. K.Bala, I.Cidon, K.Sohraby, “Congestion control for high speed packet switched networks” in
IEEE Proceedings, 9 Annual Conference of the IEEE Computer and Communication Societies
(INFOCOM), 1990
3. S.Shenker, “A theoretical analysis of feedback flow control”, in Proceedings of the ACM
Symposium on Communications Architectures & Protocols (SIGCOMM), 1990
4. S.Keshav, “A control theoretic approach to flow control” in SIGCOMM Computer
Communication Review, ACM, 1991
5. S.Floyd, V.Jacobson, “On Traffic Phase Effects in Packet-switched Gateways”, in
Internetworking Research and Experience, vol.3 pages 115-126, 1992
6. JC Bolot, “Characterizing End-to-End Packet Delay and Loss in the Internet” in Journal of
High Speed Networks, IOS Press, 1993
7. I. Cidom, A. Khamisy, M.Sidi, “Analysis of Packet Loss Processes in High-speed Networks”, in
IEEE Transactions on Information Theory, vol. 39, no.1, 1993
8. V.Paxson, “Empirically derived analytic models of wide-area TCP connections”, IEEE/ACM
Transactions on Networking (TON) vol.2, issue 4, pages 316-336, 1994
9. R.L. Carter, M.E.Crovella, “Measuring bottleneck link speed in packet-switched networks” in
Performance Evaluation Vol 27–28, Pages 297–318, 1996
10. B.P. Crow, “IEEE 802.11 Wireless Local Area Networks” in IEEE Communications Magazine,
vol.35 iss. 9 pag.116, 1997
11. V. Paxson, “Measurements and Analysis of an end-to-end Internet Dynamics”, Phd Thesis in
Computer Science Division of University of California, Berkeley, 1997
12. V. Paxson, “End to End Internet Packet Dynamics”, in SIGCOMM Computer Communication
Review, ACM, 1997
13. V. Jacobson, “Pathchar A Tool to Estimate Internet Link Characteristics”, slides, link, 1997
31
Progetto 3D CloudWiz | ATI NICE - DIEE
14. K.Lai, M.Baker, “Measuring Bandwidth” in Proceedings of IEEE INFOCOM, pages 235-245,
1999
15. R.Rejaie, M.Handley, D. Estrin, “RAP - And end to end Rate-based Congestion Control
Mechanism for Realtime Streams in Internet” in Proceedings of IEEE INFOCOM, vol. 3,
pages 1337-1345, 1999
16. M.Allan, V. Paxson, “On Estimating end-to-end Network Path Characteristics” in ACM
SIGCOMM Computer Communication Review, vol 29, issue 4, 1999
17. K.Lai, M.Baker, “Measuring Link Bandwidth using a Deterministic Model of Packet Delay” in
Proceedings of ACM SIGCOMM, pages 283-294, 2000
18. A.B.Downey, “Using Patchar to estimate Internet Link Characteristics”, in SIGCOMM
Computer Communication Review, ACM, 2000
19. B.Melander, M.Bjorkman, P.Gunningber, “A new end-to-end probing and analysis method
for estimating bandwidth bottlenecks” in Global Internet Symposium, 2000
20. S.Banerjee, A.K.Agrawala, “Estimating available capacity of a network connection” in
Proceedings of IEEE International Conference on Networks(ICON), 2000
21. Y.Zhang, N.Duffield, V.Paxson, S.Shenker, “On the Constancy of Internet Path Properties” in
Proceedings of the ACM SIGCOMM Workshop on Internet Measurement, pages 197-211,
2001
22. K.Lai, M.Baker, “Nettimer: A tool for measuring bottleneck link bandwidth” in Proceedings
of the 3rd USENIX Symposium on Internet Technologies and Systems, 2001
23. S. Alouf, P. Nain, and D. Towsley, “Inferring Network Characteristics via Moment-Based
Estimators” in Proceedings of IEEE INFOCOM, 2001
24. C.Dovrolis, P. Ramanathan, “What Do Packet Dispersion Techniques Measure?” in
Proceedings of IEEE INFOCOM, pages 905-914, 2001
25. M.Jain, C.Dovrolis, “End To End Available Bandwidth: Measurements, Metodology,
Dynamics and Realtion with TCP Throughput” in SIGCOMM Computer Communication
Review, ACM, 2002
26. A. Pasztor, D. Veitch, “The Packet size dependece of packet pair like methods” in IEEE
32
Progetto 3D CloudWiz | ATI NICE - DIEE
International Workshop of Quality Of Service (IWQoS), 2002
27. A.Pasztor, D.Veitch, "On the Scope of End-to-end Probing Methods" in IEEE
Communications Letters, vol.6, issue 11, pages 509-511, 2002
28. B. Melander, M. Bjorkman, and P. Gunningberg, “Regression-Based Available Bandwidth
Measurements,” in International Symposium on Performance Evaluation of Computer and
Telecommunication Systems, 2002
29. M. Jain, C. Dovrolis, “Pathload: A Measurement tool for end-to-end available bandwidth” in
Proceedings of Passive and Active Measurements (PAM) Workshop, pages 14-25, 2002
30. N. Hu, P. Steenkiste, “Estimating available bandwidth using packet pair probing”, [Online],
link, 2002
31. N. Hu, P. Steenkiste, “Evaluation and Characterizaion of Available Bandwidth Probing
Techniques”, in IEEE Journal on Selected Areas In Communications, vol. 21, no.6, 2003
32. R.S.Prasad, C.Dovrolis, B.A.Mah, “The effect of layer-2 store-and-forward devices on perhop capacity estimation” in IEEE Annual Joint Conference of the IEEE Computer and
Communications (INFOCOM), vol.3, pages 2090-2100, 2003
33. K. Harfoush, A. Bestavros, J. Byers, “Measuring Bottleneck Bandwidth of Targeted Path
Segments” in Proceedings of IEEE INFOCOM, 2003
34. V. Ribeiro et al., “pathChirp: Efficient Available Bandwidth Estimation for Network Paths” in
Proceedings of Passive and Active Measurements (PAM) Workshop, 2003
35. R.S.Prasad, M.Murray, C.Dovrolis, K. Claffy, “Bandwidth estimation: metrics, measurement
techniques, and tools,” in IEEE Network,vol. 17, pp. 27–35, 2003
36. J. Strauss, D. Katabi, F. Kaashoek, "A Measurement Study of Available Bandwidth Estimation
Tools" in Proceedings of ACM SIGCOMM Conference on Internet Measurement, 2003
37. J.Navratil, "ABwE: A Practical Approach to Available Bandwidth Estimation" In Proceedings
of the PAM, 2003
38. S.Shah, "
Available bandwidth estimation in IEEE 802.11-based wireless networks"in Final
Report of Bandwidth Estimation ISMA Workshop, 2003
39. S. R. Kang, X. Liu, M. Dai, D. Loguinov, “Packet-pair bandwidth estimation: Stochastic
33
Progetto 3D CloudWiz | ATI NICE - DIEE
analysis of a single congested node,” in Proceedings of IEEE International Conference on
Network Protocols(ICNP), pp. 316–325, 2004
40. M.Jain, C.Dovrolis, “Ten fallacies and pitfalls on end-to-end available bandwidth
estimation,” in Proceedings of the 4th ACM SIGCOMM conference on Internet
measurement, 2004
41. C. Dovrolis, P. Ramanathan, D. Moore, “Packet-dispersion techniques and a capacityestimation methodology” in IEEE/ACMTransactions on Networking, vol. 12, no. 6, pp. 963–
977, 2004
42. X. Liu, K. Ravindran, D. Loguinov, “Evaluating the potential of bandwidth estimators,” in 4th
New York Metro Area Networking Workshop (NYMAN), 2004
43. K.Lakshminarayanan, V.N. Padmanabhan, J. Padhye, “Bandwidth estimation in broadband
access networks.,” in Proceedings of IMC 2004, 2004
44. R.Kapoor, L.J. Chen, Li Lao, M. Gerla, M. Y. Sanadidi, “Capprobe: a simple and accurate
capacity estimation technique,” in SIGCOMM Computer Communication Review, ACM, vol.
34, no. 4, pp. 67–78, 2004
45. D. Kiwior, J. Kingston, A. Spratt, “PATHMON, A Methodology for determining Available
Bandwidth over an Unknown Network,” in IEEE Sarnoff Symposium on Advances in Wired
and Wireless Communications, pp. 27-30, 2004
46. S. Ekelin, M. Nilsson, "Continuous monitoring of available bandwidth over a network path”
in Proceedings of Swedish National Computer Networking Workshop (SNCNW), 2004
47. D.Aguayo, J.P.Bicket, S.Biswas, G.Judd, R.Morris, "Link-level measurements from an 802.11b
mesh network" in ACM/SIGCOMM Computer Communication Review, 2004
48. L.J. Chen, T. Sun, G. Yang, M. Y. Sanadidi, M. Gerla, “Adhoc probe: Path capacity probing in
ad hoc networks”, in International Conference on Wireless Internet, pages 156–163, 2005
49. L.J. Chen, T. Sun, G. Yang, M. Y. Sanadidi, M. Gerla, “End-to-end asymmetric link capacity
estimation” in IFIP Networking, pages 780–791, 2005
50. M. Jain, C. Dovrolis, “End-to-End Estimation of the Available Bandwidth Variation Range,” in
Proceedings of ACM SIGMETRICS International Conference on Measurement and Codeling
34
Progetto 3D CloudWiz | ATI NICE - DIEE
of Computer Systems, pages 265-276, 2005
51. A. Johnsson, B. Melander, and M. Bjorkman, “Bandwidth measurement in wireless
networks” in Proceedings of Mediterranean Ad Hoc Networking Workshop, 2005
52. A. Shriram, M. Murray, Y. Hyun, N. Brownlee, A. Broido, M.Fomenkov, K. Claffy,
“Comparison of public end-to-end bandwidth estimation tools on high-speed links,” in
Proceedings of Passive and Active Measurement Workshop (PAM), 2005
53. Y.Yang, R.Kravets, “Contention Aware Admission Control for Ad Hoc Network” in IEEE
Transactions on Mobile Computing, vol.4, issue 4, pages 363-377, 2005
54. S.Ekelin, M.Nilsson, E. Hartikainen, A. Johnsson, J-E.Mangs, B. Melander, M.Bjorkman,
“Real-Time Measurement of End-to-End Available Bandwidth using Kalman Filtering” in
Proceedings of 10th IEEE/IFIP Network Operations and Management Symposium, NOMS,
pp. 73–84, 2006
55. M. Li, M. Claypool, R. Kinicki, “Modeling and simulating packet dispersion in wireless 802.11
networks,” Technical Report of Computer Science Department at Worcester Polytechnic
Institute, 2006
56. M.Li, M.Claypool, R.Kinicki, “Packet Dispersion in IEEE 802.11 Wireless Networks,” in
Proceedings of Performance and Management of Wireless and Mobile Networks (P2MNet),
2006.
57. I.Rhee, L.Xu, “Limitations of Equation-based Congestion Control” in IEEE/ACM Transactions
on Computer Networking , pages852–865, 2007
58. F.Li, M.Li, R.Lu, H.Wu, M.Claypool, R.Kinicki, “Measuring Queue Capacities of IEEE 802.11
Wireless Access Points,” in Proceedings of the Fourth IEEE International Conference on
Broadband Communications, Networks and Systems (BROADNETS), 2007
59. X. Liu, K. Ravindran, D. Loguinov, “A queuing-theoretic foundation of available bandwidth
estimation: single-hop analysis” IEEE/ACM Transactions on Networking, vol.15, no. 6, pp.
918-931, 2007
60. A.Shriram, J.Kaur, "Empirical Evaluation of Techniques for Measuring Available Bandwidth"
in Proceedings of IEEE International Conference on Computer Communications INFOCOM,
35
Progetto 3D CloudWiz | ATI NICE - DIEE
pp. 2162–2170, 2007
61. J. Liebeherr, M. Fidler, S. Valaee, "Min-plus system interpretation of bandwidth estimation"
in IEEE International Conference on Computer Communications(INFOCOM), 2007
62. M.Sedighizad, B.Seyfe, K.Navaie, “MR-BART: multi-rate available bandwidth estimation in
real-time” in Proceedings of the 3nd ACM workshop on Performance monitoring and
measurement of heterogeneous wireless and wired networks, pp. 1–8, 2008
63. C.Sarr, C.Chaudet, G. Chelius, I.G. Lassous, “Bandwidth Estimation for IEEE 802.11 based Ad
Hoc Networks”, in IEEE Transactions on Mobile Computing vol. 7, no 10, 2008
64. L.J.Chen, T.Sun, B.C.Wang, M.Y. Sanadidi, M.Gerla, “PBProbe: A Capacity Estimation Tool for
High Speed Networks,” in SIGCOMM Computer Communication Review, ACM, vol. 31, no.
17, pp. 3883–3893, 2008
65. M.Li, M.Claypool, R.Kinicki, “WBest: A Bandwidth Estimation Tool for IEEE 802.11 Wireless
Networks”, in IEEE Conference on Local Computer Networks (LCN), 2008
66. T. Nadeem, “Network-aware applications in wireless networks,” in Proceedings of
Workshop on Research Directions in Situational-aware Self-managed Proactive Computing
in Wireless Adhoc Networks, 2009
67. D. Gupta, D. Wu, P. Mohapatra, C.N. Chuah, “Experimental comparison of bandwidth
estimation tools for wireless mesh networks,” in Proceedings of IEEE Conference on
Computer Communications (INFOCOM ’09), pp. 2891–2895, 2009
68. J. Liebeherr, M.Fidler, S. Valaee, “A system theoretic approach to bandwidth estimation” in
IEEE/ACM Transactions on Networking, 2010
69. F.Chen, H.Zhai, Y.Fang, “Available Bandwidth in Multirate and Multihop Wireless adHoc
Networks” in IEEE Journal on Selected Areas in Communications, vol 28, no. 3, 2010
70. C.Guerrero, M.Labrador, "Traceband: A fast, low overhead and accurate tool for available
bandwidth estimation and monitoring" in Computer Networks, vol 54, issue 6, pages 977990, 2010
71. M.F.Ibrahim, M.Jamal, S.Yahya, M.N.Taib “Available Bandwidth Estimation in NetworkAware Applications for Wireless Campus e-Learning System” in Journal of Computer
36
Progetto 3D CloudWiz | ATI NICE - DIEE
Networks and Communications, 2010
72. R.Hou, S.Qu, H.Zeng, KS.Lui, J.Li, “Coding and interference aware path bandwidth
estimation in multi-hop wireless networks” in IEEE Global Telecommunications Conference
(GLOBECOM), p. 1-5, 2011
73. H.Liu, L. Cheng, “Available Bandwidth Estimation Strategy Based on the Network Allocation
Vector” in Journal of Networks, vol.7, no.12, 2012
74. Z.Yuan, H.Venkataraman, and G.M. Muntean, "MBE:Model-based Bandwidth Estimation for
IEEE 802.11 DataTransmissions" in IEEE Transactions on Vehicular Technology, vol. 61, no. 5,
pp. 2158-2171, 2012
75. J.Guerin, S. Glass, P.Hu, W.L.Tan, M. Portmann, “Time-based and low-cost bandwidth
estimation for IEEE 802.11 links” in International Wireless Communications and Mobile
Computing Conference (IWCMC), 2012
76. D.S.Kayange, R.Sinde, A. San, “Available Bandwidth Estimation Techniques (ABETS) For An
Efficient Telemedicine Content Transport Network” in International Journal of Engineering
Research & Technology (IJERT), vol.2, issue 7, 2013
77. P.Zhao X.Yang, W.Yub, C.Dong, S.Yang, S.Bhattarai, “Toward Efficient Estimation Of Available
Bandwidth for IEEE 802.11- based Wireless Networks” in Journal of Network and Computer
Applications, 2013
78. R.Lubben, M.Fidler, J.Liebeherr, “Stochastic Bandwidth Estimation in Networks With
Random Service” in IEEE/ACM Transactions on Networking, vol.22 , issue.2, 2014
37
Progetto 3D CloudWiz | ATI NICE - DIEE
Progettazione dell'architettura del sistema adattativo
Il sistema adattativo è composto da tre moduli principali: un server, un client ed un monitor per la
misurazione della network performance.
Ognuno dei moduli implementa dei comportamenti specifici e ben definiti del sistema adattativo.
Il Server si occuperà di:
•
Catturare il flusso video dell'applicazione da remotizzare (nel caso attuale, l'intero desktop);
•
Selezionare il codec più adatto allo stato della rete per ottenere la qualità migliore (in base
all'input del network performance monitor);
•
Scambiare col client informazioni sui codec da utilizzare;
•
Comprimere ciascun frame in base al codec selezionato;
•
Inviare al client i frame catturati.
38
Progetto 3D CloudWiz | ATI NICE - DIEE
Il Client si occuperà di:
•
Decodificare i dati in arrivo dal server per la loro visualizzazione;
•
Visualizzare i frame decodificati;
•
Inviare al server eventuali informazioni sulla perdita di frame inviati.
Il Network Performance Monitor si occuperà di:
•
Monitorare periodicamente lo stato della rete;
•
Comunicare al server lo stato della rete affinché venga selezionato il codec più adatto.
Grabber
Viewer
Codec-1
Encoder Codec-2
Codec-1
Decoder Codec-2
selector
Network
performance
monitor
Codec-N
selector
Selected
codec ID
Selected
codec ID
Codec-N
Socket
Socket
Server
Client
A seconda della tipologia del monitor che verrà selezionata in fase di realizzazione potrebbero
essere previste interazioni più o meno implicite oltre che col server anche col client.
Come indicato in precedenza il monitor potrà effettuare la verifica della banda con cadenza
39
Progetto 3D CloudWiz | ATI NICE - DIEE
prefissata in modo da evitare di aggiungere un overhead continuo alla trasmissione dati, dovuto
alle operazioni di misurazione. Questa frequenza di verifica dipende sia dalla rete a disposizione
(es. una rete in fibra potrebbe permettere anche una misurazione puntuale dello status della rete)
che dall'algoritmo utilizzato per la realizzazione del monitor.
Ipotizzando che il monitoraggio venga effettuato ogni N frame inviati, quello che segue è lo schema
della sequenza di interazione fra i tre moduli.
Specifiche implementative
Dal punto di vista implementativo, possiamo già proporre una probabile struttura delle classi del
sistema adattativo:
•
CloudVizServer: incapsula tutte le operazioni eseguite dal server. Attende una nuova
connessione. All'arrivo della connessione inizia il ciclo di grabbing, codifica ed invio dei dati
codificati in maniera sincrona. La selezione del codec sarà eseguita tramite il CodecSelector
40
Progetto 3D CloudWiz | ATI NICE - DIEE
sulla base della banda disponibile individuata tramite un NetMonitor. Il controllo della
banda non sarà eseguito ad ogni frame ma periodicamente (es. all'avvio e/o una volta al
secondo). Il ciclo di cattura dovrà garantire un flusso di video con frame rate non superiore
a 25 fps. Il ciclo di cattura del server sarà terminato alla disconnesisone del client. Il server a
quel punto ritornerà nello stato di attesa per una nuova connessione.
•
CloudVizClient: incapsula tutte le operazioni eseguite dal client. Si connette al server
(indicato tramite Ip e Porta) ed attende i dati da visualizzare. Alla ricezione dei dati il client
procederà alla loro decodifica tramite il codec opportuno (identificato dall'ID ricevuto
insieme ai dati) ed alla visualizzazione. Il ciclo di ricezione/visualizzazione terminerà alla
disconnessione del server o alla pressione di un tasto. La visualizzazione dei frame
decodificati avverrà alla massima velocità possibile aggiungendo in sovrimpressione
eventuali informazioni come FPS e codec utilizzato.
•
XGrabberSHM: si occupa di catturare lo schermo restituendo il frame corrispondente al
Server.
•
CodecSelector: sulla di un del bitrate disponibile restituirà un ID univoco associato al codec
(e configurazione) da utilizzare. La codifica da utilizzare sarà fissata in modo preventivo per
diversi intervalli di bitrate. I codec preconfigurati saranno archiviati in un vettore di codec
indicizzato tramite l'id.
•
NetMonitor: fornisce le interfacce per recuperare lo stato della rete.
•
SocketServer e SocketClient: si occupano di gestire la comunicazione tramite semplici
comandi di lettura e scrittura di buffer.
41
