Conclusioni e sviluppi futuri

In questo lavoro è stato presentato un sistema per la trasmissione, su reti a commutazione di pacchetto, di video in tempo reale destinato ad un utenza eterogenea, sia per quanto riguarda le caratteristiche della rete di accesso utilizzata, che per la potenza di calcolo disponibile. Il codec utilizzato è dotato di una forte scalabilità, è possibile infatti agire su tre distinti parametri che sono la qualità, il frame rate e la risoluzione spaziale. Esso combina in modo efficace la quantizzazione vettoriale (per la riduzione della ridondanza intraframe) ed il conditional replenishment (per la riduzione della ridondanza interframe) e nonostante questo è caratterizzato da una complessità computazionale contenuta, il che rende possibile effettuare tanto la codifica che la decodifica in tempo reale su processori di fascia media.

Il lavoro si è concentrato sullo strato di rete, mentre sono stati implementati due prototipi per la trasmissione dei dati codificati su rete, per il supporto della trasmissione in real-time si è fatto ricorso al protocollo RTP (che si affida ai servizi di UDP).

Il primo prototipo realizza una trasmissione di tipo unicast, il flusso codificato viene pacchettizzato ed inoltrato verso l'host destinazione, quest'ultimo decodifica le frame ricevute e le mostra a video. I vari tipi di scalabilità offerti dal codec possono essere combinati in diversi modi, questo ha permesso di studiare quali sono le combinazioni migliori al variare delle caratteristiche della rete di accesso. Si è evidenziato inoltre che, allo stato attuale delle cose, la scalabilità in precisione probabilmente non dà quei benefici che ci sarebbe potuti aspettare.

Il secondo prototipo implementato realizza una trasmissione di tipo multicast. In questo caso vengono sfruttate più a fondo le caratteristiche di scalabilità del codec tramite la tecnica MMG. I vari sottoflussi che compongono il flusso embedded vengono inoltrati su gruppi multicast diversi, in questo modo ogni host ricevente può stabilire, in modo indipendente da quanto fanno gli altri, quali livelli utilizzare e questo si traduce nella scelta dei gruppi da sottoscrivere.

Per entrambi i prototipi si è prevista la spedizione periodica di una frame con codifica intra al fine di contenere il decadimento della qualità della sequenza riprodotta, e soprattutto indispensabile per permettere la sincronizzazione degli host che dovessero inserirsi nella sessione quando questa è già iniziata. La sincronizzazione va perfezionata per il prototipo multicast, infatti in questo caso ci si è imbattutti nel problema di dover sincronizzarsi contemporaneamente su diversi flussi di pacchetti.

Inoltre è stata implementata anche una semplice tecnica di error concealment per reagire all'eventualità della perdita dei pacchetti.

Ci sono ancora diversi punti su cui lavorare per rendere funzionale l'applicazione realizzata.

Innanzitutto deve essere ancora implementato il codice necessario all'acquisizione delle frame dall'hardware video, allo stato attuale delle cose, le frame non codificate vengono lette da disco.

Inoltre attualmente esistono due entità separate, il server che si occupa della codifica e della trasmissione ed il client, che invece si occupa della ricezione, della decodifica e del rendering a schermo della sequenza video. Queste due unità vanno fuse in un'unica applicazione che sia in grado di svolgere entrambe i ruoli. Molta attenzione va posta alle prestazioni poichè, se è vero che sia il client che il server sono in grado di girare in tempo reale, non è detto che questo sia possibile quando entrambi vengono eseguiti in modo congiunto sulla stessa macchina. L'integrazione deve essere quindi seguita anche da un lavoro di ottimizzazione delle prestazioni.

Il traffico generato ha uno spiccato carattere impulsivo a causa della presenza delle frame con codifica intra. Sarebbe opportuno ``smussare'' il traffico per evitare di avere perdite concentrate proprio sulle frame intra. Ci sono due modi possibili di agire.

  1. Si può intervenire a livello di rete. Le frame codificate vengono frammentate ed inserite in pacchetti di dimensioni più piccole e poi, tramite algoritmi tipo leaky bucket o token bucket, si effettua lo ``shaping'' del traffico;
  2. Si può intervenire a livello di codifica. É necessario modificare lo schema di codifica per evitare la trasmissione delle frame intra. Si può ad esempio trasmettere periodicamente un blocchettino di immagine che sia codificato in modo intra, ogni volta si trasmettere un blocchettino differente, dopo un certo tempo tutta l'area dell'immagine sarà stata coperta.
La prima soluzione è certamente quella più veloce da implementare in quanto non richiede modifiche sostanziali all'architettura sottostante, tuttavia non è molto adatta ad una trasmissione in tempo reale. Gli algoritmi di shaping introducono necessariamente dei ritardi tanto in trasmissione che in ricezione (dove bisognerà ricomporre i dati frammentati), senza contare poi che la perdita anche di un solo frammento comporterebbe la perdita di tutta la frame codificata. Inoltre questo modo di agire va contro il principio dell'Application Level Framing (ALF) espresso da Clark e Tennenhouse in [18]. Nello spirito di ALF, gli stream di dati prodotti da applicazioni real-time vanno pacchettizzati in aggregati, chiamati Application Data Units (ADU), che sono significativi per l'applicazione e che quest'ultima è in grado di utilizzare indipendentemente dalla sorte degli altri pacchetti.

La modifica dell'algoritmo di codifica è certamente più complessa da effettuare, ma produce senza ombra di dubbio i risultati migliori, non introduce ulteriori ritardi ed il tasso risulta molto meno variabile. Attualmente esistono già diversi lavori in cui questa tecnica è usata con successo, probabilmente i risultati più interessanti sono mostrati dal codec PVH presentato da McCanne, Vetterli e Jacobson in [20].

Certamente questi problemi hanno evidenziato che probabilmente la soluzione migliore sarebbe stata quella di affrontare contemporaneamente tanto la progettazione dell'algoritmo di codifica che dello strato di rete.

Debian User 2003-06-05