Introduzione

L'ultimo decennio è stato caratterizzato dalla inarrestabile crescita della rete Internet, che ormai si appresta a diventare uno dei principali mezzi di comunicazione. Inizialmente erano disponibili poche semplici applicazioni, tipicamente basate sullo scambio di piccoli file di dati (e-mail, newsgroup, telnet, ftp), ma con il passare degli anni a questi si sono affiancati altri servizi che hanno radicalmente cambiato l'aspetto della rete. Primo fra tutti va sicuramente ricordato il World Wide Web, letteralmente ragnatela attorno al mondo, che permette di mettere a disposizione di tutti delle pagine contenenti informazioni di diversa natura (testo, immagini, suoni...). Il Web ha avuto certamente un ruolo determinante nella crescita di Internet, ed ha ancora oggi un ruolo predominante nello sviluppo vertiginoso della rete globale.

Negli ultimi anni, si è verificato un interesse sempre maggiore verso la trasmissione di flussi multimediali in tempo reale. Sin dalla sua nascita, Internet ha mostrato grosse potenzialità come mezzo di comunicazione alternativo. Se inizialmente, però, questo ruolo era sostanzialmente affidato alla sola posta elettronica, con l'allargarsi dell'utenza ed il progredire della tecnologia sono state presentate molte alternative. Prima si è assistito alla nascita delle cosiddette ``chat'', grazie alle quali più persone possono conversare in tempo reale, tramite semplici messaggi di testo, il passo successivo è stato segnato dai programmi di istant messaging, con i quali è possibile selezionare la persona o le persone con le quali si vuole conversare. La naturale evoluzione di questi programmi consiste nella possibilità di comunicare utilizzando anche audio e video, realizzando di fatto una sessione di videoconferenza casalinga, ed è quello a cui si sta assistendo in questi mesi.

Tuttavia, per come è strutturata, Internet non è certamente il mezzo migliore per tale tipo di applicazioni, poiché, come tutte le reti a commutazione di pacchetto, è molto più efficiente nella trasmissione dati che non per il traffico multimediale. Infatti i principali requisiti di una trasmissione multimediale in tempo reale sono:

I primi due punti sono complicati ulteriormente dalla natura eterogenea dell'utenza (con canali che vanno da pochi kbit/s ad alcuni Mbit/s, e terminali potenti come i PC o semplici come i cellulari 3G). Per superare questi limiti è essenziale ricorrere a tecniche scalabili di codifica e decodifica video, tali cioè da permettere la ricezione della sequenza desiderata ad un livello di qualità selezionato dal generico utente e compatibile con le risorse garantite dalla rete e disponibili al terminale. Inoltre, particolare attenzione deve essere posta sulla complessità computazionale, specialmente per quanto riguarda gli algoritmi di codifica (tipicamente la decodifica non è molto impegnativa).

Gli aspetti legati ai ritardi di consegna, invece, sono certamente più critici. In Internet il trasporto dei pacchetti dalla sorgente alla destinazione è affidato ad uno dei due protocolli TCP (Transmission Control Protocol) e UDP (User Datagram Protocol), che si trovano sopra il protocollo di livello rete IP (Internet Protocol). IP è un protocollo best-effort, cioè fa del suo meglio per trasmettere i pacchetti ma non garantisce che questi arrivino a destinazione, nè tanto meno che ci arrivino nell'ordine in cui sono stati spediti. Queste funzionalità, se veramente necessarie, vanno introdotte dai protocolli di livello trasporto. TCP allora aggiunge, tra le altre cose, la numerazione dei pacchetti e la ritrasmissione nel caso di perdite, garantendo così la consegna di tutti i pacchetti e rispettando anche l'ordine originario, chiaramente a discapito della velocità di trasmissione. Tutto questo rende TCP un protocollo adeguato per la trasmissione di dati, quindi per applicazioni nelle quali anche il dover aspettare la ritrasmissione di un pacchetto non è problematico, ma praticamente inutilizzabile per i flussi multimediali, per i quali paradossalmente ricevere un pacchetto con un ritardo elevato è più dannoso che non riceverlo affatto. Per questo motivo tipicamente, le applicazioni multimediali utilizzano come protocollo di trasporto UDP. Quest'ultimo non offre le stesse garanzie di TCP, ma risulta sicuramente più adatto in quanto l'unico suo scopo è di consegnare nel modo più veloce possibile ogni singolo pacchetto, senza però curarsi di problemi di riordino o di ritrasmissione. Tuttavia ci sono altri fattori che limitano l'uso dello stesso UDP nelle trasmissioni real-time; infatti mancano funzionalità come la numerazione dei pacchetti0.1, il timestamping0.2, l'identificazione del contenuto del pacchetto0.3, e altre ancora.

Queste ed altre funzionalità vengono garantite dal protocollo RTP (Real Time Protocol). Inizialmente disegnato per essere indipendente dal protocollo sottostante, tipicamente RTP viene posto al di sopra di UDP, completandolo quindi di quelle caratteristiche che ne fanno un protocollo adatto alle trasmissioni real-time.

Tuttavia, per poter garantire gli ultimi due punti di cui sopra, nemmeno questo è sufficiente, e solo tecniche che permettano di garantire la qualità del servizio (QoS) possono soddisfare quelle richieste. Internet non è stata pensata per garantire la QoS, e per questo motivo si stanno studiando diverse soluzioni che permetteranno di estenderla da questo punto di vista. Le più promettenti sono probabilmente Integrated Services e Differentiated Services, entrambe le quali permettono di aggiungere nuovi servizi all'attuale modello di rete senza doverne stravolgere la struttura.

In questo lavoro di tesi si è affrontato il problema della pacchettizzazione e spedizione di un flusso video codificato. La trasmissione avviene utilizzando il protocollo RTP. L'algoritmo di codifica utilizzato (realizzato in un precedente lavoro di tesi dal collega Paolo Parlato) è caratterizzato da un'elevata scalabilità (in risoluzione spaziale, risoluzione temporale e qualità) che lo rende fruibile ad un'utenza eterogenea, i vari livelli di scalabilità sono combinati in un flusso codificato embedded. Sono state implementati due diversi prototipi che si distinguono essenzialmente per la diversa modalità di trasmissione utilizzata (unicast in un caso e multicast nell'altro), entrambi i prototipi sono composti da due unità software, un server che si occupa di codificare il flusso video e di spedirlo su rete, ed un client che riceve i pacchetti ne decodifica il payload e riproduce a schermo la sequenza video.

Nel prototipo unicast si sfruttano le qualità del codec permettendo di scegliere i 3 parametri di codifica al fine di definire come meglio si crede il trade-off qualità/tasso trasmissivo. Tale prototipo è stato sottoposto ad una serie di prove con le quali si è cercato di stabilire quale fosse il modo migliore per sfruttare le caratteristiche di scalabilità del codec.

Nel prototipo multicast invece utilizzando la tecnica MMG (Multiple Multicast Group) si ha la possibilità di realizzare una comunicazione nella quale ogni host ricevente decide a quale qualità (e quindi a quale tasso) ricevere, e questo in modo indipendente da quanto scelto dagli altri host, e soprattutto in modo trasparente all'host che sta trasmettendo.

Per entrambi i prototipi sono state implementate tecniche per la gestione dei pacchetti persi (error concealment) e per la sincronizzazione tra client e server.

Lo sviluppo del software è stato svolto presso il Laboratorio per le comunicazioni multimediali del CNIT (Consorzio Nazionale Interuniversatario per le Telecomunicazioni) di Napoli. Il lavoro si colloca all'interno del progetto denominato Labnet, il cui obiettivo è lo studio e l'implementazione di diverse tecniche di apprendimento a distanza. In particolare, ad esempio, è in via di realizzazione un sistema web-based per la fruizione a distanza di esperienze di laboratorio di misure elettroniche.

Il lavoro è organizzato nel modo seguente:

Capitolo 1
Introduzione alle problematiche affrontate nell'ambito della compressione video, descrizione di alcune delle più diffuse tecniche di codifica e degli standard di codifica video H.261, MPEG-1, MPEG-2, MPEG-4. Nella parte finale viene descritto in dettaglio il codec utilizzato in questo lavoro;
Capitolo 2
Descrizione dei modelli di riferimento per le architetture di rete, con particolare enfasi sulla descrizione delle caratteristiche salienti dei protocolli che compongono la suite TCP-IP;
Capitolo 3
Descrizione dei protocolli utilizzati tipicamente nelle trasmissioni in tempo reale. Viene quindi introdotto l'ambiente Integrated Services con il protocollo RSVP, l'alternativa rappresentata da Differentiated Services, ed inoltre viene descritto approfonditamente il protocollo RTP;
Capitolo 4
Vengono introdotte le applicazioni sviluppate per questo lavoro di tesi. Vengono descritte le tecniche utilizzate per risolvere i problemi legati alla perdita dei pacchetti alla sincronizzazione, particolare risalto è dato alla tecnica MMG;
Conclusione
Si riassumono gli obiettivi raggiunti e si analizzano i punti sui quali bisogna ancora lavorare cercando anche di proporre delle possibili strade alternative.



Footnotes

... pacchetti0.1
E' vero che perdere un pacchetto non è così drammatico per una trasmissione real-time, ma per una corretta decodifica del flusso è comunque necessario sapere che tale pacchetto è stato perso.
...timestamping0.2
Etichette che permettono di ricostruire la giusta tempificazione del flusso ricevuto.
... pacchetto0.3
Questa informazione permette ad esempio di trattare con priorità diverse tipi di dati diversi.
Debian User 2003-06-05