Subsections

Il prototipo unicast

Come primo passo si è deciso di realizzare un prototipo unicast che prevedesse la possibilità di sfruttare appieno la scalabilità offerta dal codec permettendo di variare il bit-rate, come protocollo di trasporto si è scelto di utilizzare RTP su UDP. Mentre UDP e TCP sono implementati direttamente nel sistema operativo e quindi le loro funzioni sono accessibili tramite primitive di sistema (le socket), RTP è un protocollo di livello applicazione e quindi deve essere implementato dall'applicazione che lo vuole utilizzare. Dopo una serie di ricerche in rete si è scelto di utilizzare la libreria JRTPLIB^4.2 per la sua semplicità d'utilizzo, la disponibilità su diverse piattaforme e la comprensibilità del codice di sorgente.

Sono state realizzate due applicazioni, un server ed un client, il primo si occupa di leggere le frame non codificate da disco, codificarle e trasmetterle sulla rete, il client invece riceve queste frame le decodifica e le visualizza in una finestra, riproducendo quindi la sequenza video. Per motivi di semplicità si è deciso di trasmettere ogni frame codificata in un unico pacchetto, mentre le frame di tipo (k - 1)*4 + 1 e (k - 1)*4 + 3 vengono spedite insieme in un unico pacchetto in quanto appartenenti allo stesso layer temporale^4.3.

L'interfaccia grafica

Per il client è stata realizzata l'interfaccia grafica mostrata in figura .

**Figure:** L'interfaccia del client
$\resizebox*{11cm}{!}{\includegraphics{immagini/CAP4/vunpack1.ps}}$

Sulla destra si possono vedere tre menu a scomparsa tramite i quali è possibile impostare i parametri di codifica. Si è deciso, infatti, di scegliere i parametri dal client (che in questo modo può decidere la qualità della sequenza che riceverà). In basso invece è possibile inserire l'indirizzo IP del server (per semplicità il numero di porto sul quale il server si mette in ascolto è fisso) nella classica notazione decimale puntata. Si può notare inoltre una casellina recante la scritta Attiva Zoom, selezionandola le dimensioni dell'immagine visualizzata vengono raddoppiate, senza però richiedere ulteriori layer codificati, in altre parole attivando questa casella si raddoppiano semplicemente le dimensioni dell'immagine (effettuando anche una semplice interpolazione dei pixel) senza modificare il tasso. Nella tabella

sono mostrati i valori che i parametri di codifica possono assumere.

Table: I parametri di codifica

Parametro	Valori	Significato
Numero di bit	8	Vengono trasmessi gli indici completi
	7	Vengono trasmessi solo i primi 7 bit di ogni indice
	6	Vengono trasmessi solo i primi 6 bit di ogni indice
	...	...
Frame Rate	Max	Vengono trasmesse tutte le frame (25 frame/s)
	Med	Viene trasmessa una frame ogni 2
	Min	Viene trasmessa una frame ogni 4
Risoluzione	Base	La risoluzione spaziale è di 180×144 pixel
	Enhanced	La risoluzione spaziale è di 360×288 pixel

Una volta inseriti questi parametri cliccando sul pulsante Start si avvia la comunicazione tra client e server. In un primo momento viene stabilita una connessione TCP grazie la quale il client comunica al server i parametri di codifica, il server inizia a codificare la sequenza assecondando i parametri ricevuti e spedisce le frame codificate al client, questa volta però in pacchetti RTP. Il server quindi costruisce i pacchetti RTP apponendo i giusti timestamp e numeri di sequenza. Il marker bit contenuto nell'header di RTP viene usato per segnare le frame con codifica intra.

Il client riceve questi pacchetti ne decodifica il payload e mostra le frame decodificate in una nuova finestra, mentre nella finestra principale viene diagrammato l'andamento del tasso istantaneo impegnato dalla trasmissione.

**Figure:** Il client in azione.
[La finestra principale] $\resizebox{11cm}{!}{\includegraphics{immagini/CAP4/vunpack2.ps}}$ [La sequenza riprodotta] $\resizebox{7cm}{!}{\includegraphics{immagini/CAP4/8bit.ps}}$

Il tasto Vedi Info, permette di accedere alle informazioni sull'altro host partecipante alla sessione, in particolare sono mostrate tutte le informazioni trasmesse tramite i pacchetti SDES del protocollo RTCP (vedi figura

). Delle informazioni mostrate solo il CNAME è obbligatorio, quindi possono capitare situazioni nelle quali tutti i campi sono vuoti tranne quello del CNAME.

**Figure:** Informazioni SDES
$\resizebox*{9cm}{!}{\includegraphics{immagini/CAP4/info.ps}}$

Alla fine della trasmissione, nelle console in cui si sono stati lanciati gli eseguibili (il client ed il server) appaiono le informazioni riassuntive sulla sessione. I dati sono estratti dai report ottenuti grazie al protocollo RTCP, per cui mentre nel form di info venivano mostrati i dati SDES, in queste schermate vengono mostrati i dati dei sender report e dei receiver report. In particolare, essendo in questo caso ben distinti il ruolo di trasmettitore e ricevitore, si può vedere come dal lato server siano giunti sono receiver report mentre dal lato client solo sender report. Di seguito si mostra ad esempio un report ottenuto dal lato server.

*****************************************

* Informazioni sulla sorgente *

- - - - - - - - - - - - - - - - - - - - -

SSRC :1652890298

Ci sono pacchetti accodati :NO

TimeStamp unit :4e-05

- - - - - - - - - - - - - - - - - - - - -

Non ci sono SenderReport

- - - - - - - - - - - - - - - - - - - - -

Ci sono ReceiverReport

Fract. lost :0

Packet lost :0

Highest sn :41941

Jitter :12967 tsu

Last SR Timestamp :1515784184

SR Delay :63069

- - - - - - - - - - - - - - - - - - - - -

CNAME :ant@Nemesis

- - - - - - - - - - - - - - - - - - - - -

Info locali

Pacchetti ricevuti:0

Base seq. num. :0

Highest seq. num. :0

Jitter :0 tsu

- - - - - - - - - - - - - - - - - - - - -

RoundTripTime :13606.4 ms

*****************************************

Mentre dal lato client si è ottenuto il seguente report:

*****************************************

* Informazioni sulla sorgente *

- - - - - - - - - - - - - - - - - - - - -

SSRC :1788247824

Ci sono pacchetti accodati :NO

TimeStamp unit :4e-05

- - - - - - - - - - - - - - - - - - - - -

Ci sono SenderReport

Last Timestamp :2860123955

Packet Count :541

Byte Count :921959

- - - - - - - - - - - - - - - - - - - - -

Non ci sono ReceiverReport

- - - - - - - - - - - - - - - - - - - - -

CNAME :ant@Nemesis

- - - - - - - - - - - - - - - - - - - - -

Info locali

Pacchetti ricevuti:542

Base seq. num. :41399

Highest seq. num. :41941

Jitter :12967 tsu

*****************************************

Le tecniche utilizzate

Di seguito vengono illustrate le tecniche che sono state impiegate nella progettazione del client e del server per la gestione della sincronizzazione, il recupero dalle perdite, ecc.

La codifica intraframe periodica

Il codec utilizzato prevede due modalità di codifica, la codifica intraframe, secondo la quale l'immagine viene codificata esclusivamente mediante la quantizzazione vettoriale, e la codifica interframe, che si ottiene applicando il conditional replenishment. La prima frame deve necessariamente essere codificata in modo intra, visto che le successive frame codificate in modo inter la usano come riferimento.

Tuttavia non è sufficiente codificare una sola frame in modalità intra, infatti con l'andare del tempo la qualità della sequenza riprodotta tende a decadere a causa del fatto che, ad esempio, le zone in cui i cambiamenti dell'immagine sono ridotti (lo sfondo), in dipendenza dalla soglia del CR, potranno essere non aggiornate per lunghi periodi.

Per questo motivo si è deciso di produrre periodicamente (ogni 4 secondi, ma questo parametro può essere variato in modo semplice) una frame con codifica intra, che ripristini la qualità massima della riproduzione. In particolare la frame con codifica intra ha sempre un indice del tipo $\left(\vphantom{ k-1}\right.$ k - 1 $\left.\vphantom{ k-1}\right)$ *4 + 4 con k = 25, 50, 75.... La scelta è ricaduta sulle frame del tipo $\left(\vphantom{ k-1}\right.$ k - 1 $\left.\vphantom{ k-1}\right)$ *4 + 4 perché sono le uniche ad essere sempre ricevute, indipendentemente dal livello di scalabilità a cui ci si pone.

A tal proposito in figura viene mostrato un esempio dell'andamento del PSNR, dove si può notare come in corrispondenza della ricezione delle frame con codifica intra (sono quelle numerate 50, 100 e 150, in quanto in questo caso il frame rate era quello medio, ovvero la metà di quello massimo) si hanno dei picchi nel valore del PSNR.

**Figure:** Andamento del PSNR.
$\resizebox*{12cm}{!}{\includegraphics{immagini/CAP4/psnr2.eps}}$

Avere delle frame con codifica intra inoltre aiuta nella realizzazione di altri due compiti che sono l'error concealment e la sincronizzazione, che vengono spiegati di seguito. É chiaro che tutto questo ha un costo, ovvero il tasso risulterà incrementato e soprattutto mostrerà una variabilità notevole (come si può vedere in figura , dove viene mostrato l'andamento del tasso istantaneo prodotto dal codec nel caso di frame rate minimo risoluzione enhanced e 8 bit per gli indici)

**Figure:** Andamento del tasso istantaneo.
$\resizebox*{12cm}{!}{\includegraphics{immagini/CAP4/tasso.eps}}$

Error concealment

Per quanto si possa regolare il tasso, inevitabilmente in una sessione si avrà la possibilità di perdere dei pacchetti, e il client deve essere quindi preparato per questa evenienza. Bisogna inoltre considerare che le frame sono codificate secondo un preciso schema sequenziale mostrato in figura , un'analogo schema ovviamente è deducibile anche per la decodifica.

**Figure:** Lo schema di codifica
$\resizebox*{8cm}{!}{\includegraphics{immagini/CAP4/SchemaCodifica.eps}}$

Il problema sta nel fatto che non tutte le frame sono codificate allo stesso modo, ci sono le frame con codifica intra e quelle con codifica inter, inoltre queste ultime a loro volta si distinguono in frame con CR unidirezionale (le frame del tipo $\left(\vphantom{ k-1}\right.$ k - 1 $\left.\vphantom{ k-1}\right)$ *4 + 4 e con k = 1, 2, 3...) e quelle con CR bidirezionale (quelle del tipo $\left(\vphantom{ k-1}\right.$ k - 1 $\left.\vphantom{ k-1}\right)$ *4 + 1, $\left(\vphantom{ k-1}\right.$ k - 1 $\left.\vphantom{ k-1}\right)$ *4 + 2 e $\left(\vphantom{ k-1}\right.$ k - 1 $\left.\vphantom{ k-1}\right)$ *4 + 3 con k = 1, 2, 3...). Quindi ogni frame va indirizzata al giusto blocco di decodifica.

La tecnica implementata è molto semplice: se indichiamo con numseq il numero di sequenza del pacchetto appena ricevuto e con oldnumseq quello dell'ultimo pacchetto ricevuto in ordine, bisogna verificare se numseq = oldnumseq + 1, nel qual caso non ci sono state perdite e quindi il payload può essere correttamente decodificato. Se invece la condizione non è verificata vuol dire che c'è stata una perdita oppure è arrivata una frame fuori ordine, quindi il payload non viene decodificato ma semplicemente si utilizza come frame l'ultima decodificata con successo. A questo punto si avanza di un unità oldnumseq e ci si sposta sul successivo blocco di decodifica, se era arrivata una frame fuori ordine questa viene scartata e si riceve una frame nuova, si ripete il controllo e si continua in questo modo finché il controllo non risulta verificato, il che significa che la frame può essere correttamente decodificata.

Bisogna osservare che per la decodifica delle frame con CR si deve ricorrere alle frame precedenti (alcuni blocchi vengono sostituiti con quelli di queste frame di riferimento), questo implica che quando si verifica una perdita verranno usate come frame di riferimento delle frame sbagliate e quindi, anche avendo ricevuto correttamente un nuovo pacchetto, la frame decodificata sarà caratterizzata da una scarsa qualità. Tuttavia proprio grazie al funzionamento del conditional replenishment questo effetto tende ad attenuarsi se si ricevono nuove frame, infatti le zone in cui si è avuta attività sono presenti nella frame codificata e non richiedono il riferimento e quindi la loro decodifica è corretta, l'errore persiste in quelle zone in cui l'attività non è così forte da richiedere la trasmissione del blocchetto codificato.

Questo porta ad una sorta di effetto memoria, cioè anche se si continua a ricevere correttamente i pacchetti alcune zone resteranno ``sporche''. Però c'è anche da dire che non appena sarà ricevuta una frame con codifica intra questo errore sarà azzerato in quanto tutti i blocchetti verranno codificati. Da una parte quindi aumentare il periodo di trasmissione delle frame intra consente di contenere il tasso di trasmissione, dall'altra però ridurre tale periodo consente di avere una qualità media superiore.

**Figure:** Andamento del PSNR nel caso di perdita di pacchetti.
$\resizebox*{12cm}{!}{\includegraphics{immagini/CAP4/psnr.eps}}$

La figura

mostra una situazione in cui si è verificata una perdita di pacchetti (questa evenienza è evidenziata dalle linee verticali tratteggiate), è evidente la caduta verticale del PSNR in questi casi, tuttavia le cose migliorano nettamente alla ricezione di frame con codifica intra (linee verticali continue). Tuttavia, si può notare che buona parte della qualità viene recuperata anche senza la ricezione di frame con codifica intra, questo è probabilmente imputabile al funzionamento stesso del conditional replenishment, come accennavamo sopra. Le zone in cui c'è una forte attività sono quelle sulle quali il CR fallisce e che quindi devono essere trasmesse, la loro ricezione permette di annullare i disturbi dovuti alle perdite, almeno nelle zone in movimento. Si può quindi affermare che già il solo conditional replenishment fornisce una certa robustezza nei confronti delle perdite, le zone in cui l'attività è bassa (laddove quindi il CR ha successo) resteranno però corrotte, il loro corretto ripristino è possibile solo ricevendo una frame con codifica intra, che quindi permette di ristabilire pienamente la qualità della riproduzione.

La sincronizzazione

Nel prototipo unicast la trasmissione inizia quando il server riceve un opportuno segnale di start da parte del client, quindi si potrebbe pensare che i due host siano già sincronizzati, in realtà ci sono almeno due situazioni in cui questo non è vero.

Il primo pacchetto contenente la frame con codifica intra può andare perduto, in questo caso il client non può iniziare la decodifica dei successivi pacchetti in quanto necessita di un riferimento iniziale.
Il server è di tipo concorrente, quindi è in grado di soddisfare le richieste di più host contemporaneamente, cosa accade allora se un host richiede la trasmissione quando la sequenza è stata già avviata? Anche questo host avrà bisogno di una frame di riferimento iniziale.

É chiaro che in entrambi i casi la soluzione più naturale consiste nell'attendere finché non viene ricevuta una frame con codifica intra. Quindi il client è stato progettato in modo tale che quando inizia la ricezione si mette in attesa di una frame intra, quindi riceve i pacchetti e va a controllare il marker bit, se il marker bit non è settato il pacchetto viene scartato mentre se risulta settato, il payload viene decodificato e si entra nel ciclo di decodifica.

Anche in questo caso quindi risulta determinante il fatto di spedire periodicamente una frame con codifica intra; risulta inoltre evidente che quanto minore è il periodo di trasmissione di queste frame tanto meno tempo sarà necessario per la sincronizzazione, ma allo stesso tempo tanto più alto sarà il tasso di trasmissione.

Le prove

Come visto in precedenza, il prototipo unicast permette di scegliere praticamente qualsiasi combinazione possibile dei parametri di codifica, questo ci ha permesso di sottoporlo ad una serie di prove sul campo per cercare di capire i modi migliori per sfruttare l'algoritmo di codifica.

Il codec è dotato di tre diversi tipi di scalabilità. Questo lo rende, in teoria, adattabile a diversi tipi di linea, infatti, note le caratteristiche di banda del collegamento sarà possibile scegliere il valore dei parametri caratteristici al fine di ottenere il bit-rate più adeguato.

In una prima serie di prove è stato semplicemente valutato l'andamento del tasso istantaneo del PSNR e il valore del tasso medio al variare dei parametri di codifica. In questo caso le prove sono state effettuate trasmettendo su un collegamento con la capacità di 2 Mbit/s.

In una seconda serie di prove invece si è agito in modo differente, il sistema è stato testato su una linea della quale era possibile variare la capacità, e quindi per diversi valori fissati si è cercato di determinare quali valori dei parametri di codifica dessero il migliore compromesso in termini tasso e qualità, in questo caso è stato rilevato anche il numero di pacchetti persi.

La configurazione utilizzata è mostrata in figura .

**Figure:** L'attrezzatura utilizzata per le prove
$\resizebox*{12cm}{!}{\includegraphics{immagini/CAP4/prove.eps}}$

Sul computer altair.router-test.cnit.it è stato installato il server, mentre su corcaroli.labnet.cnit.it il client. Il percorso che collega le due macchine passa attraverso gli switch LAN, i router e lo switch ATM. Come si vede dalla figura quest'ultimo è collegato ai router mediante delle linee seriali a 2Mbit/s. Il protocollo di comunicazione usato su questi collegamenti è in realtà Frame Relay, infatti lo switch ATM è in grado di gestire tanto Frame Relay che ATM (salvo poi effettuare internamente comunque una conversione verso ATM).

Tramite il software di controllo dello switch è possibile modificare le caratteristiche del collegamento, in particolare è possibile fissare il bit-rate ^4.4. Partendo quindi da un massimo di 2053 kbit/s (4844 celle/s) è possibile diminuire tale valore fino ad arrivare a 73 kbit/s (173 celle/s) con passi di 73 kbit/s (173 celle/s).

La riduzione della capacità del collegamento è resa possibile dal fatto che internamente lo switch ATM scarterà alcune celle (nel caso in cui il flusso di ingresso dovesse avere un bit-rate superiore a quello fissato) abbassando di fatto il bit-rate in uscita. E' chiaro che se il flusso ha un tasso medio al disotto del limite, ma presenta dei picchi nel bit-rate che superano quest'ultimo, subirà comunque delle perdite in quanto ovviamente il controllo viene fatto sul bit-rate istantaneo.

Agendo sui router è invece possibile cambiare la MTU (Maximum Transmission Unit), cioè la dimensione massima di un pacchetto IP che viaggia su quel link. Quindi se un pacchetto IP dovesse avere dimensione maggiore della MTU verrà frammentato in tanti pacchetti IP^4.5 ciascuno di dimensione al massimo pari alla MTU. Qualora anche uno solo di questi ``frammenti'' si dovesse perdere, tutto il pacchetto IP iniziale andrà perso (è noto che IP è un protocollo best-effort, non gestisce le ritrasmissioni). Questo fenomeno a parità di capacità del collegamento può influenzare il numero di pacchetti persi end-to-end, e quindi è da tenere in conto. Tuttavia per non introdurre troppe variabile si è preferito mantenere questo parametro fisso al valori di 1500 byte.

Le prove a capacità fissa

In questo caso si è cercato di studiare il comportamento del codificatore al variare dei parametri di codifica. La capacità della linea è stata fissata al valore massimo possibile e cioè 2053 kbit/s ( $\simeq$ 2 Mbit/s). Per ogni coppia di valori [frame rate , risoluzione] si è fatto variare il numero di bit usato per gli indici tra 4 e 8 bit. Utilizzare meno di 4 bit produce dei risultati molto scadenti da un punto di vista qualitativo e per questo tali combinazioni non sono state prese in considerazione.

Per ogni possibile combinazione sono stati calcolati il tasso istantaneo (medio, minimo, massimo e deviazione standard) il PSNR (medio, minimo, massimo e deviazione standard) e l'overhead (percentuale dello spazio del pacchetto occupato dagli header) medio dovuto alla pacchettizzazione. I primi due valori sono di chiara interpretazione, di seguito invece viene spiegato in che modo è stato calcolato l'overhead.

Le frame codificate, prima di essere spedite a destinazione, vengono inserite in un pacchetto RTP dal livello applicazione, al livello trasporto tale pacchetto viene incapsulato in uno UDP che a sua volta è incapsulato in un pacchetto IP al livello rete. Ogni livello quindi aggiunge un proprio header al pacchetto producendo quindi un incremento dell'overhead. L'header di RTP (nel caso in cui ci sia un'unica sorgente, cioè nel caso in cui il pacchetto non sia prodotto da un mixer) è costituito da 12 byte, quello di UDP da 8 byte, e quello di IP da 20 byte. Quindi saremmo portati a pensare che per ogni pacchetto c'è un overhead di 12+8+20 = 40 byte. In realtà non è così semplice, infatti bisogna tener conto anche del fatto che a livello IP può avvenire una frammentazione del pacchetto se quest'ultimo ha dimensioni maggiori della MTU.

In questo caso avremo il primo frammento che avrà un header RTP uno UDP ed uno IP, mentre i successivi frammenti avranno solo l'header IP^4.6, la figura mostra un esempio. La somma dei payload degli N pacchetti restituisce il payload originario.

**Figure:** Esempio di frammentazione di un pacchetto.
$\resizebox*{12cm}{!}{\includegraphics{immagini/CAP4/frammentazione.eps}}$

É chiaro quindi che solo il primo frammento avrà un overhead di 40 byte mentre gli altri avranno un overhead di 20 byte. Quindi per valutare l'overhead (in percentuale sul numero totale di byte ricevuti) medio sui pacchetti ricevuti si è usata la seguente espressione:

Overhead = 100* $\displaystyle {\frac{{\left[ \left\lfloor \frac{dim\, media}{MTU}\right\rfloor ... ...t\lfloor \frac{dim\, media}{MTU}\right\rfloor *20+40\right] *num\, pacchetti}}}$

Tenere conto della frammentazione fa sì che l'andamento dell'overhead non sia necessariamente monotono con le dimensioni del pacchetto (e quindi ad esempio con il numero di bit) come ci si potrebbe aspettare.

Risoluzione livello base

I dati relativi al PSNR, ottenuti a risoluzione base sono riportati nelle tabelle , , .

Table: PSNR a livello base e frame rate massimo.

Bit	PSNR Medio (dB)	PSNR Min (dB)	PSNR Max (dB)	PSNR DevStd (dB)
8	24.964	24.312	25.924	0.574
7	24.187	23.590	25.168	0.566
6	23.651	23.074	24.572	0.543
5	23.063	22.526	23.980	0.549
4	21.735	21.238	21.601	0.562

Table: PSNR a livello base e frame rate medio.

Bit	PSNR Medio (dB)	PSNR Min (dB)	PSNR Max (dB)	PSNR DevStd (dB)
8	24.969	24.312	25.920	0.577
7	24.192	23.590	25.156	0.572
6	23.655	23.074	24.572	0.545
5	23.065	22.526	23.975	0.551
4	21.738	21.238	21.601	0.564

Table: PSNR a livello base e frame rate minimo.

Bit	PSNR Medio (dB)	PSNR Min (dB)	PSNR Max (dB)	PSNR DevStd (dB)
8	24.982	24.349	25.920	0.585
7	24.204	23.625	25.156	0.579
6	23.666	23.124	24.572	0.549
5	23.075	22.555	23.975	0.560
4	21.745	21.252	21.601	0.567

**Figure:** PSNR medio a livello base
$\resizebox*{12cm}{!}{\includegraphics{immagini/CAP4/PSNRbase.eps}}$

In figura

sono riassunti i dati relativi all'andamento del PSNR medio nel caso di risoluzione base. Si può notare che il PSNR risulta ovviamente decrescente al diminuire del numero di bit utilizzati per gli indici, inoltre il passaggio da 5 bit a 4 bit porta un peggioramento più sensibile rispetto agli altri casi.

É anche interessante notare che il PSNR, anche se lievissimamente, risulta crescente al decrescere del frame rate, questo fenomeno è dovuto probabilmente al fatto che l'utilizzo del CR bidirezionale produce immagini ricostruite di qualità peggiore rispetto a quelle ricostruite con il CR unidirezionale (ovviamente però si ha un guadagno in termini di fattore di compressione). Infatti a frame rate min si utilizza un unico layer temporale, e le immagini sono tutte codificate con CR unidirezionale, il passaggio a frame rate med e max lo si ottiene aggiungendo gli altri due layer temporali, in questi layer si utilizza esclusivamente il CR bidirezionale. Oltre a questo va anche tenuto in conto che, a frame rate min, la percentuale di frame con codifica intra è maggiore.

Nelle tabelle , e sono riportati i dati relativi al valore del tasso rispettivamente nel caso di frame rate massimo, medio e minimo. Si può notare che il traffico prodotto ha una notevole variabilità, e quest'ultima risulta crescente con il tasso come si può capire dall'andamento della deviazione standard.

Table: Tasso istantaneo a livello base e frame rate massimo.

Bit	Tasso Medio	Tasso Min	Tasso Max	Tasso DevStd
	(kbit/s)	(kbit/s)	(kbit/s)	(kbit/s)
8	117.219	35.352	640.625	84.978
7	104.627	32.617	561.523	73.319
6	92.009	29.785	482.422	63.649
5	79.397	27.051	403.320	52.986
4	66.770	24.316	342.219	42.312

Table: Tasso istantaneo a livello base e frame rate medio.

Bit	Tasso Medio	Tasso Min	Tasso Max	Tasso DevStd
	(kbit/s)	(kbit/s)	(kbit/s)	(kbit/s)
8	69.938	25.781	320.312	47.473
7	62.298	23.633	280.762	41.459
6	54.637	21.582	241.211	35.442
5	46.982	19.434	201.660	29.428
4	39.314	17.383	162.109	23.409

Table: Tasso istantaneo a livello base e frame rate minimo.

Bit	Tasso Medio	Tasso Min	Tasso Max	Tasso DevStd
	(kbit/s)	(kbit/s)	(kbit/s)	(kbit/s)
8	45.560	23.047	160.15	28.308
7	40.391	20.703	140.381	24.717
6	35.199	18.359	120.605	21.131
5	30.148	15.967	100.830	17.543
4	24.816	13.623	81.055	13.958

**Figure:** Tasso medio a livello base
$\resizebox*{12cm}{!}{\includegraphics{immagini/CAP4/Tassobase.eps}}$

I dati relativi al tasso medio per i tre valori di frame rate sono riassunti nella figura , questa mostra che ovviamente al diminuire del numero di bit il tasso medio decresce, tuttavia si può anche notare che la pendenza della curva è più marcata nel caso di frame rate massimo che non negli altri due casi. In altre parole, la variazione percentuale del tasso medio al variare del numero di bit è più piccola nel caso di frame rate medio o minimo, questo rende di fatto poco conveniente agire sul numero di bit in tale situazione

Per concludere l'analisi delle prestazioni a livello base riportiamo i dati relativi all'overhead nelle tabelle , e .

Table: Overhead a livello base e frame rate massimo

Bit	Overhead (%)
8	5.540
7	6.199
6	7.036
5	8.135
4	9.642

Table: Overhead a livello base e frame rate medio

Bit	Overhead (%)
8	5.585
7	6.270
6	7.249
5	8.314
4	9.936

Table: Overhead a livello base e frame rate minimo

Bit	Overhead (%)
8	4.287
7	4.836
6	5.549
5	6.507
4	7.870

L'overhead risulta essere crescente al decrescere del numero di bit, così come era lecito aspettarsi. In particolare si può notare come il valore tenda a raddoppiare circa, passando da 8 bit a 4 bit. Il valore massimo, pari al 9.936 %, lo si ottiene nel caso di frame rate medio e indici da 4 bit, tale valore è discretamente alto e utilizzare pacchetti di dimensioni ridotte potrebbe portare a valori di overhead troppo alti.

I dati dell'overhead sono riassunti in via grafica nella figura .

**Figure:** Overhead a livello base
$\resizebox*{12cm}{!}{\includegraphics{immagini/CAP4/Overheadbase.eps}}$

Risoluzione livello enhanced

Di seguito vengono analizzati i dati relativi al livello di risoluzione enhanced.

Le tabelle , e riportano i valori assunti dal PSNR per i tre valori possibili del frame rate.

Table: PSNR a livello enhanced e frame rate massimo.

Bit	PSNR Medio (dB)	PSNR Min (dB)	PSNR Max (dB)	PSNR DevStd (dB)
8	28.078	27.058	29.632	0.447
7	26.688	25.894	28.047	0.501
6	25.570	24.878	26.732	0.506
5	24.461	23.845	25.533	0.520
4	22.739	22.157	23.622	0.550

Table: PSNR a livello enhanced e frame rate medio.

Bit	PSNR Medio (dB)	PSNR Min (dB)	PSNR Max (dB)	PSNR DevStd (dB)
8	28.098	27.058	29.632	0.462
7	26.703	25.894	28.047	0.511
6	25.579	24.875	26.732	0.511
5	24.467	23.845	25.533	0.524
4	22.743	22.160	23.672	0.551

Table: PSNR a livello enhanced e frame rate minimo.

Bit	PSNR Medio (dB)	PSNR Min (dB)	PSNR Max (dB)	PSNR DevStd (dB)
8	28.144	27.058	29.632	0.489
7	26.735	25.917	28.047	0.530
6	25.603	24.882	26.732	0.525
5	24.484	23.871	25.533	0.536
4	22.753	22.160	23.672	0.560

Sostanzialmente vengono confermate le osservazioni già fatte per il livello di risoluzione base. Chiaramente in questo caso i valori del PSNR sono mediamente più alti, tuttavia possiamo notare che mentre a risoluzione base, passando da 8 bit a 4 bit si aveva una riduzione del PSNR medio di circa 3 dB, in questo caso mediamente si assiste ad una riduzione di 6 dB. Quindi le immagini a livello enhanced risultano essere più sensibili alla variazione del numero di bit utilizzati per gli indici. La figura

riassume i dati relativi al PSNR medio.

**Figure:** PSNR a livello enhanced.
$\resizebox*{12cm}{!}{\includegraphics{immagini/CAP4/PSNRenhanced.eps}}$

Anche le osservazioni fatte a proposito del andamento del tasso sono sostanzialmente confermate per il livello di risoluzione enhanced come mostrano le tabelle

e la figura

. Proprio dalla figura tuttavia si può dedurre che la pendenza delle curve risulta essere leggermente inferiore rispetto a quello osservato nel caso di livello di risoluzione base, cioè a risoluzione enhanced il tasso medio risulta essere meno influenzato dalle variazioni del numero di bit usati per gli indici.

Table: Tasso istantaneo a livello enhanced e frame rate massimo.

Bit	Tasso Medio	Tasso Min	Tasso Max	Tasso DevStd
	(kbit/s)	(kbit/s)	(kbit/s)	(kbit/s)
8	566.409	164.746	3179.690	422.879
7	503.365	151.074	2784.182	369.533
6	440.271	137.207	2388.671	316.165
5	377.208	123.535	1993.166	262.817
4	317.104	109.766	1597.66	209.451

Table: Tasso istantaneo a livello enhanced e frame rate medio.

Bit	Tasso Medio	Tasso Min	Tasso Max	Tasso DevStd
	(kbit/s)	(kbit/s)	(kbit/s)	(kbit/s)
8	337.904	116.895	1589.841	237.391
7	299.638	106.348	1392.098	207.313
6	261.333	95.996	1194.34	177.229
5	223.051	85.449	996.582	147.151
4	184.739	75.098	798.828	117.067

Table: Tasso istantaneo a livello enhanced e frame rate minimo.

Bit	Tasso Medio	Tasso Min	Tasso Max	Tasso DevStd
	(kbit/s)	(kbit/s)	(kbit/s)	(kbit/s)
8	221.943	109.375	794.922	141.538
7	196.029	97.607	696.045	123.597
6	170.074	85.791	597.168	105.663
5	144.146	73.975	498.291	87.725
4	118.185	62.158	399.414	69.793

**Figure:** Tasso medio a livello enhanced
$\resizebox*{12cm}{!}{\includegraphics{immagini/CAP4/Tassoenhanced.eps}}$

Per concludere vengono mostrati i dati relativi all'overhead (tabelle

). Dalla lettura dei dati si nota un differente andamento rispetto a quello osservato a livello base, questo comportamento è ancora più evidente osservando la figura

Table: Overhead a livello enhanced e frame rate massimo

Bit	Overhead (%)
8	3.400
7	3.815
6	2.941
5	3.423
4	4.096

Table: Overhead a livello enhanced e frame rate medio

Bit	Overhead (%)
8	3.428
7	2.607
6	3.043
5	3.503
4	4.229

Table: Overhead a livello enhanced e frame rate minimo

Bit	Overhead (%)
8	2.617
7	2.960
6	3.406
5	2.710
4	3.305

Come si può vedere, l'overhead non è monotono con il numero di bit, tuttavia questa possibilità era stata anticipata quando è stata introdotta la modalità di calcolo dell'overhead. Questo situazione si è manifestata solo a livello enhanced a causa delle maggiori dimensioni dei pacchetti, che quindi sono più soggetti alla frammentazione operata da IP.

**Figure:** Overhead a livello enhanced
$\resizebox*{12cm}{!}{\includegraphics{immagini/CAP4/Overheadenhanced.eps}}$

Le prove a capacità variabile

In questa seconda serie di prove si è cercato di stabilire quale fosse il modo migliore di agire sui parametri di codifica al fine di adattare il tasso alla capacità della linea.

Sono stati adottati cinque diversi valori di capacità corrispondenti ai valori disponibili su alcune reti di accesso comuni (tabella )

Table: I diversi valori utilizzati per la capacità della linea

Capacità	Rete d'accesso
1 Mbit/s	XDSL
512 kbit/s	ADSL
256 kbit/s	ADSL
128 kbit/s	ISDN
64 kbit/s	ISDN

Le prove hanno evidenziato che anche nelle situazioni in cui il tasso medio prodotto dal codec è molto inferiore alla capacità della linea si possono avere delle perdite, soprattutto a causa dell'elevata burstyness causata dalle frame con codifica intra.

Inoltre si è potuto osservare che agire sul numero di bit è poco efficace in quanto la riduzione del tasso è tutto sommato contenuta. Molto più efficace risulta invece agire sul frame rate, considerando anche che il PSNR medio in questo modo risulta praticamente invariata, è ovvio che la scelta dipende anche dall'applicazione a cui ci rivolgiamo, nel caso di videoconferenza anche il frame rate minimo risulta più che sufficiente per avere una buona comprensibilità della sequenza, se invece si vuole riprodurre una sequenza più dinamica probabilmente avere un frame rate basso è troppo limitante.

Per ogni valore della capacità della linea si è cercato di determinare una o più combinazioni che ottimizzassero la trasmissione, ovvero che minimizzassero le perdite tenendo conto anche della qualità della sequenza. La qualità (spaziale) delle singole frame può essere valutata in modo oggettivo tramite il PSNR, ed il PSNR medio rappresenta quindi efficacemente la sola qualità spaziale, non tiene in conto in alcun modo della qualità temporale della sequenza, ovvero della diversa gradevolezza che si può riscontrare aumentando o riducendo il frame rate. Il modo migliore per valutare questo qualità è attraverso parametri soggettivi, e questo è quanto è stato fatto anche se nella tabella , dove vengono riassunti i risultati, viene riportato esclusivamente il PSNR medio. In ogni scelta si è cercato di dare un peso eguale tanto al valore del PSNR (quindi misura oggettiva) che alla gradevolezza riscontrata nella riproduzione (misura soggettiva).

Table: Dati riassuntivi delle prove a capacità variabile

Capacità	Combinazione scelta	Tasso Medio (kbit/s)	PSNR medio (dB)
1 Mbit/s	max, enhanced, 6bit	440.271	25.570
	med, enhanced, 8bit	337.904	28.098
512 kbit/s	med, enhanced, 6bit	261.333	25.579
	min, enhanced, 8bit	221.943	28.144
256 kbit/s	min, enhanced, 4bit	118,185	22.753
	max, base, 8bit	117.219	24.964
128 kbit/s	max, base, 4bit	66.702	21.735
	med, base, 8bit	69.9375	24.969
64 kbit/s	med, base, 4bit	39.314	21.738
	min, base, 8bit	45.5604	24.982

Si può vedere che le due scelte effettuate per la capacità di 256 kbit/s sono caratterizzate da una diversa risoluzione spaziale e quindi apparentemente non confrontabili. In realtà è stata già discussa la possibilità di attivare una modalità zoom, grazie alla quale un'immagine di livello base viene sovracampionata raggiungendo le dimensioni di un'immagine di livello enhanced. Visivamente si è riscontrato che la qualità della sequenza riprodotta a livello base ma con lo zoom era leggermente migliore di quella a livello enhanced, il tasso trasmissivo è praticamente lo stesso ma bisogna osservare che nella seconda combinazione il frame rate è quello massimo. L'immagine di livello base ``zoomata'' mostrava sicuramente un dettaglio inferiore a quella di livello enhanced, quest'ultima tuttavia risultava più ``sporca'' a causa del basso numero di bit utilizzati per gli indici, alla fine questo rende più gradevole alla vista l'immagine di livello base che non quella di livello enhanced.

Per confermare ulteriormente queste sensazioni si è misurato il PSNR della sequenza zoomata (in confronto all'immagine originale di 360×288 pixel) per poterlo confrontare con quello dell'immagine di livello enhanced. Per garantire le stesse condizioni questo calcolo è stato effettuato utilizzando il frame rate minimo (tabella ).

Table: Il livello base con lo zoom

Combinazione	PSNR medio (dB)	Tasso medio (kbit/s)
min, enhanced, 4bit	22.753	118.185
min, base(zoom), 8bit	23.038	45.560

I dati mostrano che, anche se di poco, il PSNR medio è a favore dell'immagine di livello base, ma soprattutto è interessante notare il valore del tasso medio, la proporzione è quasi di 3 a 1. In figura

sono mostrate le due frame finali ottenute per le due diverse combinazioni.

**Figure:** Due frame codificate a basso bit-rate a confronto
[Livello enhanced, 4 bit] $\resizebox{10cm}{!}{\includegraphics{immagini/CAP4/4bit.ps}}$ [Livello base con zoom, 8 bit] $\resizebox{10cm}{!}{\includegraphics{immagini/CAP4/8bitbase.ps}}$

Footnotes

... NAME="2134">^4.2: Implementata da Jori Liesemberg (jori@lumumba.luc.ac.be) per il suo lavoro di tesi ``Voice over IP in networked virtual environments'' e disponibile liberamente all'indirizzo http://lumumba.luc.ac.be/jori/jrtplib/jrtplib.html
... temporale ^4.3: Inoltre queste frame sono codificate con il conditional replenishment bidirezionale rispetto a dei riferimenti molto vicini temporalmente. Questo fa si che le loro dimensioni siano molto inferiori rispetto a quelle delle altre frame codificate.
...bit-rate ^4.4: in realtà quello che si fissa è il cell-rate in quanto, come dicevamo in precedenza, internamente lo switch lavora su celle ATM.
... IP ^4.5: A meno che il pacchetto non abbia il flag ``Don't Fragment'' settato.
... IP ^4.6: Si noti che in questi discorsi si sta trascurando l'eventuale header introdotto a livello Data Link, a causa del fatto che non possiamo sapere a priori quale tipo di protocollo verrà utilizzato.

Debian User 2003-06-05