Il blocco funzionale che si occupa di tale operazione è il buffer di de-jitter (o buffer di playout), che è essenzialmente un’area di memoria capace di memorizzare un certo numero di pacchetti, numero che dipende dalla dimensione del buffer stesso.

La dimensione del buffer di de-jitter può essere regolata in base ad approcci statici oppure in base ad approcci adattivi, i primi dei quali utilizzano una dimensione statica del buffer, mentre i secondi si affidano a metodi statistici in grado di stimare l’andamento dei parametri di rete per regolare la dimensione del buffer in modo dinamico.

Idealmente, all’uscita dal buffer di de-jitter, i pacchetti possiedono una spaziatura temporale uniforme, per effetto della rimozione del jitter operata tramite la memorizzazione temporanea dei pacchetti. La figura successiva illustra questo concetto: i pacchetti provenienti dalla rete sono affetti dal jitter, ossia arrivano con ritardi variabili, osservabili dalla spaziatura non uniforme tra i pacchetti stessi; questi pacchetti vengono memorizzati per una certa quantità di tempo nel buffer di de-jitter in modo da compensare l’effetto del jitter; all’uscita dal buffer i pacchetti sono equispaziati, ossia il jitter è stato rimosso.

Sostanzialmente il buffer di de-jitter, nel memorizzare temporaneamente i pacchetti in arrivo, aggiunge un ulteriore ritardo (ritardo di buffering o buffering delay) ai pacchetti stessi, ritardo che va a sommarsi al ritardo di rete. Questo ritardo aggiuntivo viene scelto in base a delle stime che l’algoritmo di playout buffering opera, stime che riguardano soprattutto l’andamento dei ritardi di rete ed il jitter, e serve a determinare o programmare l’istante di playout o playout delay più opportuno, ossia l’istante di tempo in cui il contenuto di ogni pacchetto dovrà essere riprodotto. Gli algoritmi più sofisticati utilizzano poi queste stime per impostare il playout delay in base a diversi criteri che possono ad esempio tenere conto dell’impatto sulla qualità dei flussi. Per i pacchetti in arrivo, se il loro istante di arrivo è tale da essere superiore all’istante di playout programmato, tali pacchetti vengono scartati, altrimenti vengono inseriti nel buffer di de-jitter in attesa di essere passati al decoder una volta raggiunto l’istante di tempo opportuno. Si capisce quindi come la scelta del buffering delay sia cruciale, in quanto da essa dipende la possibilità di scartare o meno dei pacchetti, introducendo eventualmente perdite che vanno ad aggiungersi alle perdite di rete. La seguente figura illustra quanto appena detto:

Come è evidente dalla figura precedente, quei pacchetti che sono ricevuti dopo l’istante di tempo programmato per il loro playout, rappresentato dalla linea azzurra tratteggiata superiore, vengono scartati e vanno trattati come perdite. Chiaramente, impostando un buffering delay (e quindi un playout delay) maggiore, l’eventualità di perdere pacchetti a causa di ritardo diviene meno probabile, a spese però di un ritardo che va poi a pesare sul ritardo complessivo (o delay end-to-end), e che in alcuni casi può non essere accettabile soprattutto se i requisiti di interattività dell’applicazione sono stringenti per cui il ritardo complessivo deve essere mantenuto entro una certa soglia.

Da quanto detto è evidente quindi la stretta relazione esistente tra delay, jitter, buffering delay e perdite. Un buon algoritmo di playout buffering dev’essere in grado di trovare il giusto bilanciamento tra questi fattori, tenendo conto inoltre dei vincoli di interattività dell’applicazione.

Un aspetto fondamentale degli approcci di playout buffering è, come si è detto, l’impostazione del playout delay. Un concetto strettamente correlato a questo, per approcci dinamici e adattivi, è quello relativo alla scelta dell’istante in cui variare il playout delay. Infatti, in un algoritmo di playout buffering dinamico, il playout delay viene variato periodicamente, in base a dei criteri diversi. La variazione del playout delay implica una variazione nella spaziatura temporale con cui i pacchetti vengono riprodotti (o inviati al decodificatore), per cui occorre esaminare con attenzione cosa questo significhi nel caso specifico di segnali sensibili al ritardo come la voce ed il video.

Considerando il caso del segnale vocale, la variazione del playout delay all’interno di uno stesso talkspurt può avere effetti negativi sulla qualità del segnale risultante. Però, considerando che esistono i periodi di silenzio, si può agire durante tali periodi per operare la variazione del playout delay, senza influire significativamente sulla qualità finale. In questo caso ciò che si ottiene nella pratica è una variazione, rispetto al segnale originale, dei periodi di silenzio, che potranno risultare accorciati o allungati. Questo è l’approccio comunemente adottato nel caso della voce, anche se esistono tecniche che operano modificando il playout delay all’interno dei talkspurts agendo sulla forma d’onda.

Nel caso del video, per la sua natura, non esistono istanti più o meno opportuni in cui variare il playout delay; perciò, se questo può apparire come uno svantaggio in termini di appropriatezza della scelta da effettuare, dall’altro lato consente una maggiore flessibilità nella scelta stessa.

Come conclusione a questo discorso, si possono individuare tre concetti essenziali da tenere presenti nello sviluppo di un algoritmo di playout buffering:

1. Metodo di stima delle statistiche di rete.
2. Criterio da utilizzare per il dimensionamento del buffer di de-jitter.
3. In quali istanti modificare il playout delay.

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

Non-proprietary, standards based
Simple, scalable
Robust, Reliable, Redundant
End-to-End HD or SD System
Low Total Cost of Ownership

Download the Precis Overview Document

Precis is an all digital file-based networked news production solution that leverages non-proprietary components. It is a simple, scalable software / hardware solution that integrates all elements of the news production process; ingest, editing, playout, archiving and redistribution to multiple media outlets. And since it is based on standard IT-components, it supports HD natively, offering you a straightforward upgrade path to true HD news production. Precis is an open system offering you the flexibility to choose your preferred cameras, newsroom computer system, and nonlinear editors. This eliminates vendor lock-in giving facilities the freedom to integrate a variety of equipment across a newsroom.http://www.broadcastequipmentguide.com/bitcentral-precis-news-production-system_10_01_07.php

Dopo un lungo periodo di assenza a causa degli esami universitari e della svogliatezza generale causata dalle continue deludenti prestazioni, torno finalmente ad aggiornare il blog, e lo faccio alla vigilia di una partita che, secondo logica, non avrebbe dovuto esistere. Invece, come da tradizione in questa stagione, siamo riusciti a complicarci la vita in maniera disarmante, costringendoci a doverci giocare tutto in una settima partita. Domani sera l'ingresso sarà completamente gratuito, e speriamo che ci sarà un discreto pubblico per sostenere una squadra che sembra, ora più che mai, completamente allo sbando.