html5-img
1 / 117

RETI MOBILI E MULTIMEDIALI

Università degli Studi di Roma “La Sapienza” Dipartimento INFOCOM. RETI MOBILI E MULTIMEDIALI. Aldo Roveri Lezioni dell’ a.a. 2009-2010. 1. VI . Multimedia. Aldo Roveri, “RETI MOBILI E MULTIMEDIALI” Univ. di Roma “La Sapienza” - a.a. 2009-2010. CONTENUTI. VI .1 Compressione audio e video

zarola
Download Presentation

RETI MOBILI E MULTIMEDIALI

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Università degli Studi di Roma “La Sapienza” Dipartimento INFOCOM RETI MOBILI E MULTIMEDIALI Aldo Roveri Lezioni dell’ a.a. 2009-2010 1

  2. VI. Multimedia Aldo Roveri, “RETI MOBILI E MULTIMEDIALI” Univ. di Roma “La Sapienza” - a.a. 2009-2010

  3. CONTENUTI • VI.1 Compressione audio e video • VI.2 L’operazione di streaming • VI.3 Streaming audio/video memorizzato • VI.4 Servizi audio e video interattivi • VI.5 Controllo della multimedialità

  4. Multimedia • VI.1 Compressione audio e video

  5. Digitalizzazione della voce • La voce telefonica analogica ha una larghezza di banda lorda di 4 kHz; • può quindi essere campionata con una frequenza di 8 kHz: ciò produce 8000 campioni/s. • Secondo la codifica PCM standard, ogni campione è codificato con 8 bit; il segnale numerico risultante ha quindi un ritmo uguale a 64 kbit/s.

  6. Digitalizzazione dei suoni musicali (1/2) • Se si desidera riprodurre suoni ad alta fedeltà (HF), la larghezza di banda lorda del segnale analogico viene normalmente assunta uguale a 22,050 kHz per ogni canale (tra i due di una riproduzione stereo). • Il campionamento per ogni canale deve essere allora alla frequenza di 44,100 kHz.

  7. Digitalizzazione dei suoni musicali (2/2) • Utilizzando una codifica a 16 bit/campione il segnale digitale che ne risulta per musica HF mono-canale ha un ritmo uguale 44,1 x 16 = 705,6 kbit/s , mentre per musica HF stereo (due canali) il ritmo binario è uguale a 44,1 x 16 x 2 = 1,411 Mbit/s. • Per un trasferimento o una memorizzazione è necessaria un’operazione di compressione.

  8. Digitalizzazione di dati video (1/5) • Un segnale video è il risultato di una sequenza di immagini fisse che vengono presentate su uno schermo con una velocità tale da dare l’impressione del movimento: i nostri occhi non possono infatti distinguere le singole immagini quando queste vengono riprodotte in sequenza con sufficiente velocità.

  9. Digitalizzazione di dati video (2/5) • Per ingannare l’occhio umano con l’impressione del movimento sono sufficienti 25 immagini/s, ma per evitare effetti di tremolio dell’immagine ogni immagine viene ridisegnata una seconda volta; ne consegue che la presentazione è equivalente a 50 immagini/s. • D’altra parte ogni immagine è composta da una matrice di pixel (Picture Elements), il cui numero (in verticale e in orizzontale) costituisce la risoluzione dell’immagine.

  10. Digitalizzazione di dati video (3/5) • Ogni pixel viene rappresentato da una sequenza di bit, che specifica il colore del pixel: per immagini in bianco e nero basta 1 bit/pixel; per immagini a colori il numero di bit per ogni pixel dipende dal numero di colori impegnati.

  11. Digitalizzazione di dati video (4/5) • La risoluzione standard di ogni immagine (quadro) di un segnale televisivo su schermo di formato 4:3 contiene 720x576 pixel, mentre per un sistema ad alta definizione (HD TV) su uno schermo di formato 16:9 la risoluzione prevede un quadro contenente 1920x1152 pixel.

  12. Digitalizzazione di dati video (5/5) • Se allora ciascuno dei tre colori primari (rosso, verde, blu) è codificato con 8 bit e se quindi ogni pixel è rappresentato con 24 bit, ogni immagine di un segnale televisivo a colori con risoluzione standard è codificabile con 720 x 576 x 24 ≈ 9,95 Mbit. • Conseguentemente il segnale televisivo, che è una sequenza di immagini di questo tipo, viene numerizzato con un ritmo binario, che è uguale a 25 x 9,95 ≈ 248,8 Mbit/s e che per essere trasferito o memorizzato richiede un’operazione di compressione.

  13. Tecniche di compressione (1/2) • Nella compressione di segnali numerici audio e video si adottano attualmente due principali tecniche di compressione: • quella predittiva • quella percettiva. • Si distinguono poi tecniche di tipo • lossless, senza perdita di informazione, • lossy, con perdita di informazione.

  14. Tecniche di compressione (2/2) • Una tecnica di compressione è qualificabile attraverso il cosiddetto rapporto di compressione e cioè il rapporto tra i due ritmi a monte e a valle dell’operazione di codifica. • Com’è intuitivo, le tecniche lossy consentono di conseguire un maggior rapporto di compressione rispetto a quelle lossless, ma a spese di una minore qualità del risultato auditivo o visivo.

  15. Compressione del segnale telefonico (1/5) • Nelle reti mobili (ove è importante contenere i ritmi del segnale trasferito) la voce telefonica è codificata con una tecnica chiamata AMR (AdaptiveMultiRate). • Il codificatore AMR è un dispositivo integrato singolo con otto possibili velocità emesse; i ritmi che ne risultano sono controllabili dalla rete di accesso radio e non dipendono dalla effettiva attività della sorgente.

  16. Compressione del segnale telefonico (2/5) • Tra i ritmi riportati nella Tab.VI.1 vanno segnalati quello di 12,2 kbit/s che è impiegato nel GSM e che, nella versione a pieno ritmo (EFR), è ulteriormente impiegato in UMTS, ove il codificatore è in grado di modificare il proprio ritmo binario ogni 20 ms.

  17. Compressione del segnale telefonico (3/5) Tab.VI.1

  18. Compressione del segnale telefonico (4/5) • Lo schema di codifica in AMR è il cosiddetto ACELP (Algebraic Code Excited Linear Predictioncoder): ogni 20 ms (e quindi ogni 160 campioni estratti alla frequenza di 8kHz), il segnale vocale è analizzato per estrarne i parametri del modello CELP; i bit dei parametri vocali emessi dal codificatore sono poi pesati in funzione della loro importanza soggettiva prima di essere emessi.

  19. Compressione del segnale telefonico (5/5) • Lato sorgente si impiega un rivelatore di tratti di voce attiva (VAD – Voice Activity Detector) e si valuta il rumore acustico di sottofondo; questo rumore (Comfort Noise) viene trasferito al lato ricevente, che provvede, con trame apposite ad intervalli regolari dette SID (SilenceDescriptor), a riprodurlo nei periodi in cui non sono ricevute trame vocali.

  20. Compressione dei dati audio (1/3) • Nella compressione predittiva, detta anche differenziale, si codifica la differenza tra ogni campione e una predizione di questo effettuata sulla base dei campioni precedenti. • Il vantaggio risiede nella minore dinamica dei campioni differenza e quindi nella possibilità di codificarli con un minore numero di bit rispetto alla codifica di ogni campione con ampiezza quale risulta dal campionamento del segnale di sorgente.

  21. Compressione dei dati audio (2/3) • Un esempio di questa tecnica è rappresentato dal DPCM (Differential PCM) che codifica • un segnale telefonico al ritmo di 32 kbit/s; • un segnale vocale con banda lorda di 7kHz (e quindi con qualità migliore rispetto al segnale telefonico) al ritmo di 64 kbit/s.

  22. Compressione dei dati audio (3/3) • Nella compressione percettiva si sfruttano alcune caratteristiche del sistema uditivo; alcuni suoni, in frequenza e nel tempo, non ci fanno percepire altri suoni. • La codifica MP3 (MPEG-1 Audio Layer 3) utilizza queste caratteristiche producendo segnali audio digitali a velocità comprese tra 112 e 128 kbit/s con rapporti di compressione che corrispondentemente variano tra 12 :1 e 10:1. • Il ritmo di codifica cresce passando al Layer 2 (tra 192 e 256 kbit/s) e al Layer 1 (384 kbit/s). • Si tratta in ogni caso di codifiche di tipo lossy.

  23. Compressione dei dati video: immagini fisse (1/3) • Nello standard JPEG (Joint PhotographicExperts Group) la compressione, che è usualmente di tipo lossy, è attuata in tre passi • l’immagine è segmentata in blocchi di 8 x 8 pixel e di ogni blocco di 64 pixel viene calcolato il contenuto spettrale nello spazio con una Discrete Cosine Transform (DCT) bidimensionale;

  24. Compressione dei dati video: immagini fisse (2/3) • segue una quantizzazione effettuata tramite opportune matrici che pesano i coefficienti di ordine più basso (che rappresentano le frequenze spaziali minori) con un passo di quantizzazione più piccolo e viceversa per i coefficienti di ordine più alto; • si conclude con una codifica entropica e con una eliminazione delle ridondanze di tipo statistico; la componente continua della DCT è codificata in DPCM.

  25. Compressione dei dati video: immagini fisse (3/3) • Il rapporto di compressione che si può raggiungere è determinato essenzialmente dal parametro di scalatura per la matrice di quantizzazione; si può raggiungere un rapporto di compressione 15:1 senza alterare visibilmente la qualità dell’immagine

  26. Compressione dei dati video: immagini in movimento (1/2) • La compressione MPEG (Moving Picture Experts Group) è specifica per immagini in movimento • Si attua riducendo la ridondanza delle singole immagini (codifica intraframe) e delle relazioni tra immagini successive (codifica interframe). • Nella sua prima versione (MPEG-1) lo standard è stato predisposto per la memorizzazione di dati su CD e opera a una velocità di 1,5 Mbit/s.

  27. Compressione dei dati video: immagini in movimento (2/2) • La seconda versione (MPEG-2) è stata progettata per i DVD e opera a velocità più alte, da 3 a 6 Mbit/s; è impiegata nella formazione del segnale diffuso nella TV digitale terrestre e satellitare. • Le compressioni effettuate nei due standard MPEG-1 e MPEG-2 sono di tipo lossy.

  28. Multimedia • VI.2 L’operazione di streaming

  29. Classi di applicazioni multimediali • Ci riferiamo alle operazioni di streaming di informazioni audio/video e, in questo ambito, distinguiamo tre classi a cui corrispondono modalità di attuazione ed esigenze prestazionali tra loro diverse. • Le tre classi sono • streaming audio/video memorizzato; • streaming audio/video in tempo reale; • streaming audio/video in tempo reale interattivo.

  30. Perdite di pacchetti (1/5) • Per ognuna di queste tre classi, occorre tenere conto che Internet offre un servizio di rete “best-effort” (a meno di interventi correttivi su cui si parlerà nel seguito) e che tale tipo di servizio può portare a mancanza di controllo su • perdite di pacchetti ; • ritardi di trasferimento dei pacchetti.

  31. Perdite di pacchetti (2/5) • Le perdite hanno origine nei buffer dei router attraversati dai pacchetti nel loro transito dall’origine alla destinazione; sono sostanzialmente dovute all’evento di trabocco di questi buffer e al conseguente scarto dei pacchetti che non possono essere inoltrati verso un collegamento in uscita. • Altre cause di perdita sono dovute a disturbi di natura varia quali si presentano, ad esempio, in collegamenti wireless.

  32. Perdite di pacchetti (3/5) • Se lo streaming riguarda solo un flusso audio/video, il grado di perdita (quota parte dei pacchetti persi rispetto a quelli emessi all’origine) non è una prestazione critica, nel senso che possono essere tollerati gradi di perdita di valore contenuto, orientativamente non superiore al 10%, ma in ogni caso con valore limite dipendente da ogni specifica applicazione.

  33. Perdite di pacchetti (4/5) • Quando lo si reputi necessario, si può contenere l’effetto delle perdite • in ricezione, con il mascheramento delle perdite attuato con l’interpolazione dei dati mancanti con quelli ricevuti; • in trasmissione, con l’impiego di codici correttori d’errore (FEC), di schemi di interallacciamento (interleaving) e, in generale, di ridondanza a bassa velocità e a bassa risoluzione.

  34. Perdite di pacchetti (5/5) • I gradi di perdita possono essere fortemente contenuti con l’adozione di TCP come protocollo di trasporto in luogo di UDP e compatibilmente con la prestazione di ritardo.

  35. Ritardi di trasferimento (1/4) • Il ritardo di trasferimento di un pacchetto da estremo a estremo è la somma dei tempi di trasmissione e dei ritardi di propagazione, di elaborazione e di accodamento nei router attraversati dal pacchetto sul suo percorso da estremo a estremo.

  36. Ritardi di trasferimento (2/4) • Il ritardo di un pacchetto ha in generale natura aleatoria: dipende infatti da vari parametri legati alla trasmissione del pacchetto stesso e al collegamento che è di supporto alla trasmissione; si manifesta quindi con realizzazioni che presentano • un valor medio, che chiameremo ritardo di base e che dipende, a parità del collegamento, dal carico sui nodi e sui rami della rete; • fluttuazioni all’intorno del ritardo di base, che sostanzialmente dipendono dalla variabilità delle durate di permanenza dei pacchetti nei buffer dei router e che sono denominate jitter di pacchetto.

  37. Ritardi di trasferimento (3/4) • I valori dei ritardi di base possono assumere valori non particolarmente stringenti nelle due classi di streaming con file memorizzati o in tempo reale, con un limite più stretto per la seconda classe rispetto alla prima, ma in ogni caso entro valori di qualche decina di secondi. • Nel caso invece della classe di streaming interattivo, il ritardo di base deve avere un valore tale da non pregiudicare l’interattività della comunicazione.

  38. Ritardi di trasferimento (4/4) • Ad esempio, nel caso di trasferimenti in campo telefonico, ritardi di base inferiori a 150 ms non sono percepiti dall’orecchio umano. • Se il ritardo cresce nell’intervallo tra 150 e 400 ms, la qualità della comunicazione, seppure peggiorata, è ancora accettabile. • Tale qualità peggiora in modo da pregiudicare l’interattività della comunicazione se il ritardo supera orientativamente il valore di 400 ms.

  39. Jitter di pacchetto (1/4) • Nel trasferimento di dati audio/video in tempo reale (interattivo o meno) assume importanza sulla qualità dell’informazione ricevuta il jitter di pacchetto, e cioè la variabilità del ritardo con cui arrivano i pacchetti che contengono i dati. • Per una corretta riproduzione dei dati audio/video in tempo reale è necessario che il jitter sia di valore il più possibile contenuto.

  40. Jitter di pacchetto (2/4) • Gli effetti del jitter possono essere contenuti • aggiungendo, in emissione, ad ogni pacchetto l’istante relativo di generazione; • scegliendo opportunamente, in ricezione, l’inizio della riproduzione; • memorizzando i dati ricevuti in un buffer di riproduzione, in attesa dell’inizio della riproduzione; • prevedendo di dotare i pacchetti di numeri di sequenza, che consentano il riordino dei pacchetti in ricezione; • scartando i pacchetti che pervengono dopo l’inizio della riproduzione.

  41. Jitter di pacchetto (3/4) • In Fig.VI.1 è mostrato il trattamento in ricezione di pacchetti emessi a intervalli costanti e trasferiti con ritardi affetti da jitter; sono considerati i tempi di permanenza nel buffer di riproduzione e, in particolare, viene mostrato il caso di scarto di un pacchetto.

  42. t(0) D(0) V(0) t(1) T D(1) V(1) t(2) T D(2) V(2) t(3) T D(3) V(3) t(4) T D(4) V(4) Pacchetto scartato t(5) T D(5) T V(6) D(6) t(6) Asse emissione Asse riproduzione Jitter di pacchetto (4/4) Fig.VI.1

  43. Multimedia • VI.3 Streaming audio/video memorizzato

  44. Streaming audio/video memorizzato (1/3) • Il contenuto multimediale è memorizzato su un server e può essere trasferito a un client che ne fa richiesta. • La riproduzione del file presso il client deve essere continua , e cioè deve poter essere in sincronia con i tempi di registrazione originali; ciò impone limiti critici al ritardo dei dati, che devono essere ricevuti dal client in tempo utile per la loro riproduzione.

  45. Streaming audio/video memorizzato (2/3) • Questo vincolo di riproduzione continua non impedisce che, con una opportuna modalità di controllo, il client abbia la possibilità di interagire con il server per ottenere funzioni tipiche di un registratore audio/video operante in locale, quali il fermo-riproduzione e la possibilità di spostarsi in avanti o all’indietro. • Il trasferimento del file è usualmente di tipo unicast.

  46. Streaming audio/video memorizzato (3/3) • Nel modulo, che presso il client consente di riprodurre il file trasferito, devono essere previste varie funzioni quali: • la decompressione dei file audio/video durante la riproduzione; • la rimozione del jitterquando necessario per la qualità della riproduzione e con le modalità chiarite in precedenza; • il contenimento delle perdite quando necessario per la qualità della riproduzione; la modalità più semplice è ottenuta mascherando le perdite con l’interpolazione dei dati mancanti con quelli ricevuti.

  47. Streaming con media player (1/3) • Un file audio/video memorizzato potrebbe essere trasferito come un qualsiasi altro file. • Ad esempio si potrebbe usare un browser e trasferire il file residente su un server web attraverso il protocollo HTTP. • In questa ipotesi il server web potrebbe spedire il file in forma compressa al browser. • Il browser, dopo aver memorizzato il file, potrebbe utilizzare un’ applicazione ausiliaria, chiamata media player , che permette di ascoltare l’audio e di vedere il video e che quindi ne consente la riproduzione (FigVI.2).

  48. Streaming con media player (2/3) Fig.VI.2

  49. Streaming con media player (3/3) • Il trasferimento del file audio/video effettuato in questo modo ha un grosso inconveniente: dato che file di questo tipo hanno in generale grandi dimensioni anche se in forma compressa e dato che una loro riproduzione può avvenire solo dopo un loro trasferimento completo, l’utente, in funzione del collegamento utilizzato con il server, deve aspettare tempi anche molto lunghi prima di usufruire del contenuto del file; ciò può essere inaccettabile.

  50. Streaming con metafile (1/3) • Per risolvere questo problema, il media player si connette direttamente al server per ottenere da questo il file audio/video e per poterlo riprodurre durante la ricezione. • Per questo scopo il server web memorizza due file: • il file audio/video; • un metafile , che contiene informazioni riguardo al file audio/video.

More Related