Un pizzico di orgoglio per la Sardegna

Pubblicato il Ottobre 15, 2008 di lellodixit

Leggendo questo articolo comparso sul quotidiano L’Unione Sarda del 15 Ottobre 2008 non può non nascere un pizzico di orgoglio in chi lavora ai progetti del Distretto ICT di Sardegna Ricerche.
Per approfondimenti:

Antonio Mancosu

Postato in: Generale, Tecnologia | Contrassegnato da tag: , , , , , , , , , , , | Non ci sono Commenti »

Spegnimento della TV analogica in Sardegna

Pubblicato il Ottobre 12, 2008 di lellodixit

Ci scusiamo per l’interruzione.

Le trasmissioni riprenderanno il più presto possibile. Anzi, mai più.

Questo potrebbe essere il messaggio che spiritosamente qualche tecnico TV potrebbe essere tentato di mandare in onda il 15 Ottobre 2008. Sì, perchè a partire da tale data in Sardegna, prima regione europea ad essere interessata da tale cambiamento, verrà definitivamente spento il segnale televisivo analogico e il segnale ricevibile con le tradizionali antenne domestiche sarà esclusivamente quello digitale terrestre. Si parla di switch-off proprio per indicare lo “spegnimento” del segnale che per più di 50 anni è stato trasmesso sul territorio nazionale con tecnica analogica.

La conseguenza pratica immediata di questo cambiamento, già in fase di sperimentazione da qualche tempo in modo particolare in Sardegna e Valle d’Aosta, è quella di doversi necessariamente dotare di un dispositivo, il Set-top-Box (STB) o decoder per il digitale terrestre (a meno che il televisore non ne possieda uno integrato), in quanto i classici televisori non sono in grado di interpretare il segnale digitale, per cui questo compito deve essere demandato a un altro dispositivo, il decoder appunto.

Lo switch-off sarà effettuato in Sardegna nell’arco di tempo compreso tra il 15 e il 31 Ottobre 2008, secondo il seguente calendario:

  • Dal 15 al 16 Ottobre la zona dell’Ogliastra e del Sarrabus.
  • Dal 17 al 21 Ottobre il cagliaritano, il Sulcis Iglesiente e il Medio Campidano.
  • Dal 21 al 24 Ottobre l’oristanese ed il nuorese.
  • Dal 27 al 31 Ottobre la zona di Sassari e della Gallura.

Non resta che mandare un ideale saluto e un ringraziamento alla TV analogica che è stata, con i suoi pregi e i suoi difetti, un po’ mamma, un po’ maestra, a volte cattiva maestra, compagna, consigliera e attrice con un ruolo da protagonista nel ruolo di coesione sociale e culturale di un Paese (ancora) frammentato come l’Italia, sperando che la TV digitale, anche nelle forme alternative a quella digitale terrestre, sia in grado di adempiere al proprio ruolo in un modo magari diverso ma comunque sempre responsabilmente consapevole della potenziale influenza su modelli e comportamenti dei singoli e della collettività.

Per approfondimenti:

Antonio Mancosu

Postato in: Generale, Tecnologia, Tecnologie TV | Contrassegnato da tag: , , , , , , , , , , , , , , , , , , , , , , , , , , | 2 Commenti »

CreaTiVù a SMAU 2008

Pubblicato il Ottobre 11, 2008 di lellodixit

CreaTiVù, l’applicazione open source per la creazione partecipativa di programmi TV che è in fase di sviluppo presso il laboratorio “Produzione Collaborativa Programmi TV Multi-Piattaforma” di Sardegna Ricerche, sarà presentata nella versione demo a SMAU 2008, la principale fiera italiana dedicata all’Information & Communications Technology che si terrà a Milano dal 15 al 18 ottobre presso il polo fieristico di Milano City.

CreaTiVù sarà visionabile all’interno dello stand riservato a Sardegna Ricerche, inserito nell’ambito dell’area dedicata ai Percorsi dell’Innovazione e che comprenderà i 9 laboratori tecnologici di Sardegna DistrICT e alcune realtà regionali sarde del settore ICT.

Per approfondimenti:

Antonio Mancosu

Postato in: Generale, Tecnologia, Tecnologie TV | Contrassegnato da tag: , , , , , , , , , , , , , , , , , , , , , , , , , , , , | Non ci sono Commenti »

TV Digitali - Prima puntata: Introduzione

Pubblicato il Settembre 15, 2008 di lellodixit

Questo è il primo di una piccola serie di articoli che ho deciso di dedicare alle nuove forme di TV: le TV Digitali. Questo articolo contiene una breve introduzione e una prima classificazione di quelle che sono le TV digitali. Gli articoli successivi riguarderanno invece argomenti come le modalità di fruizione delle TV digitali, le tecnologie e gli standard (DVB, IP, streaming, P2P, broadcast, multicast, ecc.), le diverse offerte di servizi TV (Video-on-Demand, canali lineari basati su un palinsesto, User Generated Content), la filiera della TV digitale, aspetti riguardanti il mercato delle TV digitali.

La televisione, rispetto a come è stata concepita sino a qualche anno fa, sta evolvendo, per alcuni aspetti, verso qualcosa di profondamente diverso, sia dal punto di vista della modalità di fruizione da parte degli utenti, sia dal punto di vista della tecnologia che ne è alla base e che consente un’offerta più ricca di contenuti e di servizi.

La modalità di fruizione è influenzata da diversi fattori, come il tipo di dispositivi che stanno sempre maggiormente prendendo piede (dispositivi portatili vari, cellulari, PC, console per giochi e così via), e anche dal tempo che lo “spettatore” (termine improprio in alcuni casi) è disposto a spendere davanti a uno stesso schermo, quale che esso sia. A questi fattori si aggiunge poi, in parte come effetto del fattore relativo alle tipologie di dispositivi, la possibilità per l’utente, in modo più marcato in alcuni casi di TV digitale, di poter interagire con il servizio, con la conseguenza che la fruizione ne trae un valore aggiunto non trascurabile.

La più grande trasformazione che sta alla base dell’evoluzione della televisione è la diffusione delle tecnologie digitali, per cui quando si parla di nuove forme di TV si parla essenzialmente di TV digitali, in cui il segnale trasmesso non è più semplicemente un’onda elettromagnetica variabile nel tempo che viaggia nell’etere, come nel caso della TV analogica che è oramai sulla via del tramonto, ma è una serie di impulsi elettrici codificati numericamente come sequenze di ‘0’ e di ‘1’ i quali, opportunamente modulati, possono viaggiare nell’etere, su collegamenti satellitari e a microonde, su cavi in fibra ottica o in rame, e che possono essere generati e decodificati solo da dispositivi digitali.

Le TV digitali, spesso dette piattaforme TV, e altre volte indicate (forse impropriamente) come canali TV, sono essenzialmente di cinque tipi:

  • Televisione Digitale Terrestre (DTT, Digital Terrestrial Television)
  • Televisione Digitale Satellitare
  • IPTV (Internet Protocol Television)
  • Web TV
  • Mobile TV

La TV Digitale Terrestre è quella finalizzata a sostituire e migliorare il classico servizio di TV analogica presente in Italia dai primi anni ’50 del secolo scorso. La TV Satellitare, presente ormai da vari anni, è stata la prima forma di TV digitale erogata in Italia. La IPTV, molto più diffusa ad esempio in Francia che in Italia, viene distribuita essenzialmente dai grossi operatori di telecomunicazioni attraverso le proprie infrastrutture di rete, mentre la Web TV viene per lo più distribuita tramite la rete Internet anche da piccoli operatori. La Mobile TV è un tipo di TV digitale pensata per essere fruita anche in mobilità ed è erogata principalmente da grandi operatori e da compagnie telefoniche.

La classificazione precedente in realtà può apparire arbitraria, in quanto ad esempio la Web TV viene in alcuni casi indicata come Internet TV (o come Net TV), per sottolineare la rete su cui viene distribuita svincolandola dal servizio più generale attraverso il quale ad oggi viene fruita, ossia il Web appunto, per cui si tratta esclusivamente, in questo caso, di una questione terminologica. Inoltre, spesso si classifica come IPTV anche la Web TV (o Internet TV), cosa che qui tuttavia non verrà fatta (si veda ad esempio ITU-T IPTV Focus Group per una precisa definizione di IPTV).

La classificazione precedente inoltre non tiene conto di un’altra forma di TV, che è quella via cavo (cavo coassiale) poco diffusa in Europa e in Italia, per cui qui non viene presa in considerazione.

In base a questa classificazione è poi difficile collocare fenomeni comunque importanti quali ad esempio Youtube, che rappresenta in sostanza un servizio di condivisione di video che poco ha a che vedere con il concetto di televisione sia dal punto di vista della qualità complessiva, nella maggior parte dei casi scadente, sia dal punto di vista della enorme eterogeneità di contenuti presenti nel servizio.

Alcuni dei cinque tipi di televisione elencati sopra hanno già raggiunto un buon livello di maturazione tecnologica e di penetrazione presso il pubblico, come nel caso della TV satellitare, mentre in altri casi si è in una fase di transizione o di definizione precisa di standard sia tecnologici che di tipo legislativo, oltre che alla ricerca di adeguati modelli di business, per cui un’analisi puntuale di queste diverse tipologie di TV ed un loro confronto non può non tenere conto di questi importanti aspetti.

Riferimenti

  • http://www.itu.int/ITU-T/IPTV/
  • http://www.osservatori.net/new_tv
  • Tommaso Tessarolo, “Net TV”, Apogeo, 2007

Antonio Mancosu

Postato in: Tecnologie TV | Contrassegnato da tag: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , | Non ci sono Commenti »

CreaTiVù: un’applicazione per creare programmi TV multi-piattaforma

Pubblicato il Agosto 31, 2008 di lellodixit

Sul sito Web di CreaTiVù si può trovare un’anteprima delle caratteristiche dell’applicazione Web CreaTiVù che è in corso di sviluppo presso il Laboratorio “Produzione Collaborativa Programmi TV Multi-Piattaforma” di Sardegna Ricerche (laboratorio a cui collaboro anche io).
L’applicazione è finalizzata alla creazione partecipativa di programmi televisivi destinati a qualsiasi piattaforma distributiva (Digitale Terrestre, IPTV, Mobile TV, Web TV, ecc.) ed è improntata sul modello partecipativo che caratterizza il cosiddetto Web 2.0, in cui i protagonisti sono gli utenti.

Che altro dire: per saperne di più visitate CreaTiVù.

Antonio Mancosu

Postato in: Tecnologie TV | Contrassegnato da tag: , , , , , , , , , , , , , , , , , , , | Non ci sono Commenti »

Valutazione della qualità per Video over IP

Pubblicato il Luglio 20, 2008 di lellodixit

Lo scenario futuro delle applicazioni funzionanti in rete sarà sempre più caratterizzato dall’integrazione ed erogazione di servizi video-voce-dati su un’unica infrastruttura di rete, cioè quella che si poggia sull’Internet Protocol. Questo scenario, noto con il nome commerciale di Triple Play, si baserà su servizi e applicazioni multimediali come ad esempio IP Telephony, Video-on-Demand, Streaming, IPTV, Videoconferenza, particolarmente rilevanti in aree applicative quali ad esempio l’E-learning, l’Entertainment, la Telemedicina.

Una tale prospettiva, molto attraente per utenti e operatori delle telecomunicazioni, pone tuttavia alcune problematiche, principalmente derivanti dal fatto che le applicazioni multimediali che coinvolgono voce e video richiedono ingenti risorse in termini di banda e presentano requisiti piuttosto stringenti in termini temporali, essendo dei media time-dependent, quindi particolarmente sensibili a impairments come delay, jitter e packet loss.

Riferendosi alla Internet pubblica, tali problematiche sono particolarmente rilevanti, essendo questa progettata per fornire un servizio di tipo best-effort, che mal si concilia con i requisiti dei flussi multimediali. Ciò si traduce, in assenza di meccanismi di QoS, in un forte impatto sulla qualità dei servizi offerti, per cui si presenta la necessità di valutare l’influenza che il trasporto di flussi multimediali su una rete come Internet ha sulla qualità percepita dall’utente.

Nel caso specifico di servizi video over IP la questione non è banale, in quanto non esistono, allo stato attuale, degli standard consolidati che siano in grado di associare, in tempo reale, ad una data sequenza video con determinate caratteristiche e in una data condizione operativa della rete, un valore di qualità del video.

Esistono molti lavori nella letteratura che risultano utili per inquadrare l’ambito del problema della valutazione della qualità video. Quella che segue è una breve rassegna di alcuni di questi lavori, con i punti salienti che li caratterizzano.

Come è spiegato in [9], la qualità di una sequenza video digitale può essere influenzata principalmente dall’algoritmo di codifica utilizzato e dagli errori derivanti dalla trasmissione su una rete a commutazione di pacchetto. Si illustra inoltre l’importanza di avere a disposizione delle metriche oggettive che permettano di non affidarsi ai dispendiosi e lunghi metodi soggettivi. Vengono anche presentate le metriche oggettive tradizionali come la metrica peak-signal-to-noise-ratio (PSNR) e altre metriche sviluppate negli ultimi anni.

I metodi per la misura della qualità video ricadono in tre categorie [8]: metodi Full-Reference (FR), che richiedono l’accesso alla sequenza video originale e a quella alterata dalla trasmissione; metodi Reduced-Reference (RR) simili ai metodi FR, ma che richiedono un minor numero di parametri; metodi No-Reference (NR) che non necessitano di accedere al video originale.

In [10] si spiega come il numero di fattori da prendere in considerazione per una stima in tempo reale della qualità video sia troppo alto per poter essere applicato alla totalità dei casi, e come anche la natura della scena debba essere presa in considerazione.

La Raccomandazione ITU-T J.144 [11] è uno standard che fornisce delle linee guida per la valutazione oggettiva, tramite tecniche FR, di sequenze video in applicazioni one-way; questo standard è utile in particolare per stabilire il grado di corrispondenza tra misure oggettive e misure soggettive.

Lo standard ITU-T J.148 [12] illustra invece i requisiti che dovrebbe avere un modello per la valutazione oggettiva della qualità di un servizio multimediale, con particolare attenzione ai servizi a banda stretta.

Di seguito si presenta una breve rassegna dei lavori che propongono delle tecniche per la valutazione della qualità video nel caso di trasmissione su una rete.

[1] fornisce le informazioni per analizzare gli impairments di rete che affliggono applicazioni come streaming video o voice over IP, senza tenere conto delle tecniche di codifica, rilevanti nel caso del video. Si basa su due componenti: il Delay Factor (DF) e il Media Loss Rate (MLR).

Un metodo per la valutazione oggettiva della qualità video è presentato in [2], in cui ci si basa su tre parametri: edge distortion, spurious edges, motion distortion. Questo metodo non fa riferimento a impairments di rete.

L’impatto congiunto del bit-rate di codifica e del packet loss sulla qualità video è studiato in [3], ma limitatamente al caso di sequenze video codificate in MPEG-2. Il risultato è una formula la quale dice che esiste un bit-rate ottimale, che dipende dal tipo di scena video, a cui la qualità presenta un valore massimo.

[4] propone un framework capace di stimare, lato server, la qualità disponibile all’utente basandosi su dati come packet loss rate (PLR) medio e strategia di error concealment al decoder. La tecnica si basa sulla stima della distorsione mean-squared-error (MSE) tra sequenza originale e sequenza decompressa, e l’approccio è in termini di variabili random. Questa tecnica non può utilizzare il codec video MPEG-4 AVC/H.264 per motivi legati all’interpretazione numerica dei risultati.

Un’altra tecnica per il monitoraggio in tempo reale della qualità video su reti IP è presentata in [5], in cui si introduce un modello loss-distortion che tiene conto dell’impatto del codec, della pacchettizzazione e delle caratteristiche del video (ad esempio scene con grande movimento). La difficoltà derivante dal fatto di dover considerare le caratteristiche del contenuto della scena viene aggirata introducendo una metrica di qualità “relativa”, che consente di ottenere una stima della qualità senza dover decodificare la sequenza video. Questo approccio assume che siano già disponibili stime accurate di alcune quantità.

In [6] si introduce un modello che tiene conto di vari fattori che influiscono sulla qualità video, come bit-rate, frame-rate, rapporto tra macroblocchi INTRA/INTER, packet loss rate, burst loss. Il modello si basa sulle Reti Neurali Artificiali (ANN), usate per creare un mapping non lineare tra misure oggettive e soggettive di qualità video. La complessità della tecnica è accresciuta dal fatto di doversi affidare a dei test soggettivi.

Un lavoro specifico sul video streaming è [7], che si limita tuttavia al caso di un formato video proprietario. Si sviluppano delle tecniche per estrarre le informazioni sulla qualità del video dai pacchetti osservati, considerando il payload ai livelli network, transport e application. Gli impairments considerati come aventi influsso sulla qualità video sono quelli legati al rate adaptation e alla gestione del playout buffer.

Un altro lavoro che si limita a sequenze MPEG-2 è [8], in cui si utilizzano metodi NR per valutare l’impatto del packet loss sulla qualità. I metodi utilizzati servono a stimare il MSE dovuto al packet loss e sono: FullParse, QuickParse, NoParse.

Come si può notare da questa breve rassegna, i metodi elencati si distinguono principalmente in base a numero e tipo di parametri considerati, e al campo di applicabilità.

Riferimenti

[1] RFC 4445: A Proposed Media Delivery Index, http://www.rfc-archive.org/getrfc.php?rfc=4445

[2] J. Okamoto, T. Hayashi, A. Takahashi, and T. Kurita, “An objective quality assessment method for arbitrary video streams”, Proc. PCS2004, Dec. 2004

[3] O. Verscheure, P. Frossard, , M. Hamdi, User-Oriented QoS Analysis in MPEG-2 Video Delivery, RealTimeImg(8 ), No. 5, October 1999, pp. 305-314

[4] M. Fumagalli R. Lancini S. Tubaro, Video Quality Assessment from the Perspective of a Network Service Provider, IEEE 8th Workshop onMultimedia Signal Processing, 2006

[5] S. Tao, J. Apostolopoulos, R. Guérin, Real-Time Monitoring of Video Quality in IP Networks, NOSSDAV’05, June 13–14, 2005, Stevenson, Washington, USA

[6] S. Mohamed, G. Rubino, H. Afifi, F. Cervantes, Real-Time Video Quality Assessment in Packet Networks: A Neural Network Model,

[7] A. Reibman, S. Sen, J. Van der Merwe, Video Quality Estimation for Internet Streaming, WWW 2005, May 10.14, 2005, Chiba, Japan.

[8] A. R. Reibman, V. Vaishampayan, and Y. Sermadevi. Quality monitoring of video over a packet network, IEEE Trans. Multimedia, April 2004

[9] Stefan Winkler, Digital Video Quality, John Wiley & Sons, 2005

[10] S. A. Mohamed, Evaluation automatique de la qualité des flux multimédias en temps reel: une approche par réseaux de neurones, http://www.irisa.fr/armor/lesmembres/Mohamed/Thesis/node10.html

[11] ITU-T Rec. J.144, Objective Perceptual Video Quality Measurement Techniques for Digital Cable Television in the Presence of a Full Reference, May 2004

[12] ITU-T Rec. J.148: Requirements for an objective perceptual multimedia quality model, May 2003

Antonio Mancosu

Postato in: Comunicazioni Multimediali | Contrassegnato da tag: , , , , , , , , , , , , , , | Non ci sono Commenti »

H.264/AVC over IP

Pubblicato il Giugno 29, 2008 di lellodixit

Generalità

Le reti IP possono essere caratterizzate in base al modo in cui vengono gestite, ad esempio la rete Internet nella sua concezione primaria è una rete IP cosiddetta “unmanaged”, in cui il servizio offerto non offre garanzie di consegna dei pacchetti o di priorità di traffico (servizio best-effort). Un importante elemento da considerare è la natura fisica della rete di comunicazione su cui fluiscono i pacchetti, che può essere wireless o wireline (o una loro combinazione).

In base al livello di gestione a cui le reti IP sono soggette, è possibile avere differenti caratteristiche in termini di maximum transfer unit size (MTU size), di probabilità di errori sui bit dei pacchetti, e di controllo del traffico (paradigma di traffico TCP).

La MTU size è la massima dimensione che un pacchetto può avere per essere trasmesso senza essere frammentato/ricombinato a livello di rete e di trasporto. Per collegamenti wireline tipicamente la MTU è di circa 1500 bytes, per collegamenti wireless è di circa 100 bytes.

La probabilità di errore sui bit per reti wireline è trascurabile, mentre va tenuta in considerazione per reti wireless.

Il paradigma di traffico TCP, poco usato in realtà, consiste essenzialmente nella riduzione del bit rate della metà da parte del sender quando il packet loss supera una certa soglia. Questo consente un controllo della congestione e di garantire quindi un traffico più regolare.

La codifica video con metodi quali quelli presenti nello standard H.264 consiste di strumenti per la robustezza nei confronti degli errori indotti dalla trasmissione in rete; tuttavia si può notare che approcci apparentemente finalizzati allo stesso scopo, come appunto la codifica error-resilient e il controllo della congestione, siano alla prova dei fatti contraddittori: la codifica error-resilient aggiunge ridondanza al bitstream aumentando il bit rate e il carico della rete per mantenere la qualità ad un livello desiderato, mentre il meccanismo di controllo della congestione riduce il carico della rete in presenza di alti tassi di errore. Finora, la soluzione al problema causato da una tale contraddizione è stata quella di ridurre la qualità del video alla sorgente mediante la riduzione del frame rate, della dimensione delle immagini, della qualità dell’immagine, e, nel caso peggiore, saltando la trasmissione di alcuni frames.

Protocolli

Per applicazioni di streaming e di conversazione audio/video la gerarchia di protocolli utilizzati è ben definita. Segue una rassegna per livelli:

  • Livello fisico e di data link: le reti IP sono indipendenti dai protocolli di questi livelli.
  • Livello di rete: le reti IP utilizzano il protocollo IP, con un header di 20 bytes ed un payload di dimensione variabile.
  • Livello di trasporto: il protocollo di trasporto per audio e video più usato su reti IP è UDP, che offre un servizio best-effort come IP, senza garanzia di consegna nè possiblità di ritrasmissione. L’header di UDP è di 8 bytes.
  • Livello di trasporto/lato applicazione: in questo livello ibrido si colloca il protocollo RTP, che fornisce un importante supporto alla trasmissione di audio e video in tempo reale, tramite informazioni come numero di sequenza dei pacchetti, timestamp, tipo di payload, marker bit ecc. Un pacchetto RTP consiste di un header di 12 bytes e di un payload contenente l’informazione utile. Un protocollo associato ad RTP, il RTCP, fornisce ulteriori servizi aggiuntivi a quelli offerti da RTP.
  • Livello applicazione: a questo livello sono utilizzati vari protocolli come H.245, SIP, RTSP, per annunciare ad esempio la disponibilità di un media stream, per stabilire connessioni (reali o virtuali), per negoziare alcune opzioni, e per controllare una sessione.

Riferimenti

S. Wenger, “H.264/AVC over IP”, IEEE Transactions on Circuits and Systems for Video Technology, Vol. 13, No. 7. (2003), pp. 645-656.

Antonio Mancosu

Postato in: Comunicazioni Multimediali | Contrassegnato da tag: , , , , , , | Non ci sono Commenti »

Lo standard di codifica video H.264/AVC

Pubblicato il Giugno 22, 2008 di lellodixit

Lo standard H.264/AVC è stato definito nel 2003 dalla ITU-T con lo scopo di fornire un supporto ad applicazioni di vario genere con una qualità superiore ai precedenti standard di codifica video.

E’ suddiviso in tre profili: Baseline, Main, Extended, ciascuno con delle proprie caratteristiche e potenziali ambiti applicativi. Tra le principali aree applicative si possono citare:

  • Televisione via cavo, via satellite, digitale terrestre, DSL, ecc.
  • Memorizzazione su supporti ottici.
  • Servizi di conversazione voce e video su ISDN, IP, LAN DSL, su reti wireless e mobili, ecc.
  • Servizi di Video-on-Demand e di video streaming su varie piattaforme di rete.
  • Servizi di Multimedia Messaging (MMS).

Il codec H.264 consiste di due blocchi principali: il Video Coding Layer (VCL) che si occupa della codifica vera e propria dei dati video, ed il Network Abstraction Layer (NAL) che si occupa di organizzare i dati codificati in modo adatto per il trasporto in rete.

La figura seguente esemplifica tale architettura, in cui è evidenziata la separazione tra il livello di pertinenza del codec da quello di trasporto per entrambi i lati, encoder e decoder:

h264_vcl-nal

Il VCL consiste di un’unità che si occupa della compressione, e opera ai livelli sintattici di blocco, macroblocco, e slice. E’ progettato in modo da essere il più possibile indipendente dalla rete, e contiene vari strumenti di codifica che migliorano la robustezza agli errori del flusso video compresso.

Il NAL adatta le stringhe di bit generate dal VCL a vari ambienti di rete e multiplex. Copre tutti i livelli sintattici al di sopra del livello di slice. Il NAL permette ai dati codificati dal VCL di poter essere trasmessi su RTP/UDP/IP, H.324/M, MPEG-2 transport, H.320.

La separazione tra VCL e NAL consente una separazione tra gli aspetti del codec relativi all’elaborazione del segnale e quelli relativi al trasporto su un canale di comunicazione, separazione che si traduce in una maggiore flessibilità in fase di progetto delle applicazioni.

Le nuove caratteristiche introdotte dallo standard H.264 possono essere suddivise in categorie:

  • miglioramento della capacità di predire i valori del contenuto dell’immagine da codificare.
  • Miglioramento dell’efficienza della codifica.
  • Robustezza nei confronti di errori/perdite e flessibilità nel funzionamento in vari ambienti di rete.

Per ognuna di queste categorie lo standard specifica vari strumenti, un sottoinsieme dei quali viene adottato a seconda del profilo (Baseline, Main, Extended).

In base alle caratteristiche di ogni profilo si può dire che il profilo Baseline è adatto per applicazioni come videotelefonia, videoconferenza, e comunicazioni wireless; il profilo Main si può utilizzare per applicazioni di memorizzazione video e broadcasting televisivo; infine il profilo Extended si presta bene ad applicazioni di streaming media.

Tools di error-resilience in H.264

Lo standard H.264 sfrutta i tools già presenti in altri schemi di codifica video e ne introduce dei nuovi per migliorare le prestazioni derivanti dalla trasmissione in rete.

Ecco una breve rassegna delle tecniche utilizzate dal codec H.264:

  • Intra Placement: posizionamento di immagini, blocchi, macroblocchi, slices codificati intra per contrastare effetti di drifting. H.264 consente la predizione di macroblocchi Intra anche da macroblocchi Inter .
  • Picture Segmentation: H.264 consente la segmentazione di un’immagine sotto forma di slices. La disponibilità di una slice codificata consente di ricostruire i macroblocchi di questa slice.
  • Reference Picture Selection: la selezione di un’unità di riferimento, sia essa una immagine, una slice, o un macroblocco, può essere utilizzata come strumento di robustezza nei confronti degli errori.
  • Data Partitioning: si creano più stringhe di bit per una slice (stringhe dette partizioni), e si allocano tutti i simboli di una slice in una singola partizione che ha una stretta relazione semantica con ogni altra. In H.264 sono presenti tre tipi di partizione: Header information, Intra Partition, Inter Partition.
  • Parameter Sets: un sequence parameter set contiene tutta l’informazione relativa ad una sequenza di immagini; un picture parameter set contiene tutta l’informazione relativa a tutte le slices appartenenti ad una singola immagine. Le informazioni sui parameter sets possono essere inviate in-band o out-of-band.
  • Flexible Macroblock Ordering: disponibile solo per i profili Baseline ed Extended, consente di assegnare i macroblocchi alle slices in un ordine diverso da quello di scansione normalmente utilizzato. Ciò consente una maggiore efficacia nel mascheramento degli errori nel caso di perdita di una slice.
  • Redundant Slices: consente ad un encoder di piazzare, in aggiunta ai macroblocchi della slice stessa, una o più rappresentazioni ridondanti dello stesso macroblocco nello stesso bit stream. La rappresentazione ridondante può essere codificata utilizzando diversi parametri di codifica.

Riferimenti

  • T. Wiegand, G. J. Sullivan, G. Bjøntegaard, and A. Luthra, “Overview of the H.264/AVC video coding standard,” IEEE Transactions on Circuits and Systems for Video Technology, vol. 13, pp. 560–576, July 2003.

  • T. Stockhammer, M. Hannuksela, and T.Wiegand, “H.264/AVC in wireless environments,” IEEE Transactions on Circuits and Systems for Video Technology, vol. 13, pp. 657–673, July 2003.

  • S. Wenger, “H.264/AVC over IP”, IEEE Transactions on Circuits and Systems for Video Technology, Vol. 13, No. 7. (2003), pp. 645-656.

  • Iain E. G. Richardson , “H.264 and MPEG-4 Video Compression”, Wiley, 2003

Antonio Mancosu

Postato in: Comunicazioni Multimediali | Contrassegnato da tag: , , , , , , , , , , | 2 Commenti »

Playout buffering

Pubblicato il Giugno 15, 2008 di lellodixit

Per playout buffering si intende la memorizzazione temporanea, al lato ricevente di un’applicazione, dei pacchetti in arrivo in modo da compensare la variabilità dei ritardi con cui giungono questi pacchetti ed in modo tale da consentire una riproduzione dell’informazione in essi contenuta che sia la più fedele possibile a quella presente al lato mittente dell’applicazione.

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.

de-jitter

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:

diagramma_tempo_pacchetti

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

Postato in: Comunicazioni Multimediali | Contrassegnato da tag: , , , , , , , , , , , , | 1 Commento »

Audio e video in rete: problematiche

Pubblicato il Giugno 14, 2008 di lellodixit

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:

jitter

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

Postato in: Comunicazioni Multimediali | Contrassegnato da tag: , , , , , , , , , , , , , | Non ci sono Commenti »

Next Page »