Audio e video in rete: problematiche

Consideriamo una rete a commutazione di pacchetto basata sul protocollo IP, quindi una rete cosiddetta “connectionless”. Una rete di tale tipo, come è Internet, ha la peculiare caratteristica di essere attraversata da pacchetti che viaggiano attraverso link e nodi della rete stessa in modo totalmente indipendente l’uno dall’altro, nodi e link che sono tra l’altro risorse condivise e quindi con caratteristiche altamente dinamiche ed il cui comportamento non sempre è facilmente prevedibile. I pacchetti di uno stesso flusso audio, ad esempio, possono seguire percorsi completamente differenti per giungere alla destinazione. Possono pertanto arrivare in un ordine qualsiasi rispetto a quello stabilito in fase di trasmissione e con ritardi differenti tra loro, obbligando il riordino in ricezione ed un ripristino della giusta temporizzazione. Può anche accadere che alcuni pacchetti vengano persi durante il transito in rete. Se poi nei nodi interni della rete non è previsto nessun meccanismo che sia in grado di assegnare maggiore priorità ai pacchetti che trasportano informazioni sensibili ai ritardi come lo sono l’audio ed il video, ad esempio, ecco che si ha un quadro introduttivo di quanto non sia banale trasmettere in modo efficace audio e video su Internet.

Inoltre, a maggiori requisiti di interattività dell’applicazione coinvolta corrispondono maggiori conseguenze negative che i problemi menzionati causano, obbligando ad affrontare in modo molto accurato le possibili soluzioni.

Entrando nei dettagli dei principali problemi che una rete IP come Internet presenta riguardo alla trasmissione di audio e video, si può tentare di riassumerli in pochi punti:

• Perdita di pacchetti (loss).

• Ritardo nella consegna dei pacchetti (delay).

• Variazione del ritardo nella consegna dei pacchetti (jitter).

La perdita di pacchetti nella rete può essere dovuta ad esempio a situazioni di congestione, per cui un pacchetto viene scartato quando non può essere accomodato nella coda di un router.

Il ritardo di rete può essere dovuto anch’esso a situazioni in cui i link della rete sono congestionati ed i ritardi di accodamento nei nodi intermedi della rete sono significativi.

La variazione del ritardo, o jitter, è il problema più serio, ed è anch’esso legato ai tempi di accodamento variabili nei nodi interni della rete.

Per quel che concerne le perdite, queste possono manifestarsi come perdite isolate o random, oppure sotto forma di “burst”, ossia gruppi consecutivi di pacchetti persi. C’è comunque da dire che per l’audio e il video si è in grado, anche grazie ai meccanismi di correzione e mascheramento degli errori, di ovviare in parte a tale problema.

Il jitter è il problema più serio in quanto è un fenomeno che altera in modo profondo le relazioni temporali tra i pacchetti che sono state introdotte al lato mittente dell’applicazione. Se infatti alla sorgente i pacchetti audio e video sono stati prodotti ad intervalli temporali regolari, ed al lato destinazione tale regolarità non viene rispettata, la riproduzione dell’audio e del video può essere fortemente compromessa in termini di qualità ed intelligibilità.

La figura seguente illustra una situazione tipica, in cui i pacchetti vengono generati al lato mittente dell’applicazione ad un tasso costante, con spaziatura temporale pari a T, sono quindi inviati sulla rete IP e, una volta giunti al lato destinatario dell’applicazione, presentano spaziature temporali irregolari, a causa del jitter indotto dal transito sulla rete:

Un’ulteriore questione di grande rilievo che è specifica di applicazioni che implicano la presenza di due o più flussi contemporaneamente, è quello della sincronizzazione tra questi flussi. In particolare, in applicazioni audio-video interattive (ma non solo) come la videoconferenza e la videotelefonia, la sincronizzazione tra la voce ed il video viene riferita con l’espressione “lyp synchronization”, ad indicare la necessità di mantenere un certo livello di sincronizzazione tra la voce e le labbra di chi parla.
Per affrontare i problemi sopra citati sono possibili due approcci: il primo è quello che prevede di introdurre, all’interno della rete, dei meccanismi tali da garantire un certo livello di qualità del servizio, essenzialmente rendendo i nodi intermedi della rete capaci di assegnare delle priorità al traffico con requisiti temporali più stringenti. Il secondo approccio è quello di aggiungere “intelligenza” ai sistemi terminali della rete, ossia ai nodi terminali in cui le applicazioni ed i servizi vengono effettivamente fruiti.
La prima possibilità si basa sul presupposto di avere a disposizione una serie di protocolli e meccanismi che garantiscano una effettiva qualità del servizio, ma allo stato attuale è ragionevole pensare che si dovrà avere a che fare ancora per un po’ di tempo con la classica natura “best-effort” di Internet, senza garanzie di qualità. Per cui non resta che affidarsi al secondo approccio, studiando soluzioni da realizzare ai nodi estremi, laddove i pacchetti vengono generati e laddove i pacchetti vengono ricevuti per estrarne l’informazione utile alle applicazioni.

Una prima soluzione che segue il secondo approccio è già stata introdotta, e riguarda i meccanismi che consentono di correggere o mascherare in ricezione le eventuali perdite di pacchetti. Per quanto riguarda invece il problema del jitter, la soluzione che si adotta comunemente è quella di introdurre un buffer di de-jitter in ricezione, ossia una “memoria tampone” che memorizza temporaneamente i pacchetti in arrivo dalla rete, consentendo di ripristinare la temporizzazione stabilita al lato mittente, separando di fatto l’istante in cui essi arrivano dall’istante in cui il loro contenuto verrà riprodotto, introducendo così un opportuno ritardo. Si parla in tale contesto di “playout buffering”.

Riferimenti

Tesi di laurea in Ingegneria Elettronica di Antonio Mancosu, A.A. 2005/2006: “Controllo del ritardo di playout nelle comunicazioni audio-video su reti a pacchetti”.

Antonio Mancosu