POLITECNICO DI TORINO

Transcript

1 POLITECNICO DI TORINO III Facoltà di Ingegneria Corso di Laurea in Ingegneria Elettronica TESI DI LAUREA EDITING IN TEMPO REALE DI FLUSSI VIDEO SU ARCHITETTURE STREAMING Relatori prof. Fulvio Corno prof. Maurizio Rebaudengo Candidato Diego Villabruna

2 Settembre 2002

3

4 Indice 1 Audio e video streaming Introduzione Creazione del contenuto multimediale Flussi video Flussi audio Interleaving Altri formati Data editing Data Encoding Streaming delivery Streaming play Obiettivo della tesi Software di audio/video streaming Introduzione Microsoft RealSystem Apple Quicktime Scelte di progetto ed applicazione prototipale Introduzione Architettura generale del progetto Architettura hardware e software di sistema Architettura server Architettura client Caratteristiche di rete Applicativo prototipale Multimedia Mixing Server Architettura generale Prerequisiti Conversioni di formato Struttura principale dell'applicativo Invio flusso A/V a Real Producer...32

5 4.4.6 Mixing A/V Interattività del sistema MMS: Implementazione interazione libera MMS: Implementazione interazione guidata Formato file di controllo mixer 48 5 Analisi prestazioni e funzionalità ottenibili Introduzione RITARDO DEL SISTEMA (tempo di loop) CARICO CPU e MASSIMO FRAME RATE Valutazione Stream PIP Statico Valutazione Stream Filmato semplice Valutazione Stream PIP dinamico Valutazioni conclusive Possibili sviluppi e conclusioni...63 Appendice A: Librerie FFMPEG: CODEC supportati...67 Appendice B Librerie FFMPEG: Strutture dati e funzioni utilizzate...69 Appendice C: RealSystem - Interfacce di rete supportate...73 Appendice D: Interfaccia a oggetti Real Producer...75 Appendice E: Esempio file Storyboard...81

6 1 Audio e video streaming 1 Audio e video streaming 1.1 Introduzione Con il termine streaming media si intende la diffusione in rete di informazioni di tipo multimediale: tipicamente audio e video. Durante un processo di streaming intervengono almeno quattro soggetti: una sorgente che genera il contenuto multimediale (ad esempio una videocamera), un computer server che riceve i dati provenienti dalla sorgente, li converte in un formato idoneo alla trasmissione e li trasmette in rete, una rete di trasmissione dati ed uno o più computer client che rielaborano i dati ricevuti rendendoli disponibili agli utilizzatori finali (Figura 1). COMPUTER CLIENT SORGENTE COMPUTER SERVER RETE COMPUTER CLIENT COMPUTER CLIENT Figura 1 - Architettura streaming (unicast) La morfologia di collegamento sopra proposta viene anche definita unicast, in quanto un unico server gestisce un numero limitato di client. Il numero massimo di questi ultimi dipende dalla banda e dalla quantità di 6

7 1.1 Introduzione memoria posseduti dal server stesso. Qualora vi siano troppi client da servire per il modello unicast, è possibile ricorrere ad un'architettura definita multicast che prevede l'utilizzo di più server in cascata. Definiti i soggetti che intervengono nel processo di streaming media è ora possibile definire le fasi che lo compongono, che sono: Creazione del contenuto multimediale Data editing Data encoding Streaming delivery Streaming play 1.2 Creazione del contenuto multimediale Il primo passo da compiere per effettuare uno streaming è la generazione di un flusso audio e video. Il sistema più semplice da implementare è di prelevare questi dati direttamente da una videocamera. A tale scopo è possibile utilizzare un'apposita scheda di acquisizione dati che campioni il segnale analogico fornito dalla telecamera. E' comunque preferibile utilizzare una telecamera digitale fornita di uscita DV collegata ad un'interfaccia firewire (IEEE1394) data la migliore qualità di immagine ottenibile e il minor costo. E' inoltre possibile prelevare il flusso audio/video (A/V) da un file statico di tipo multimediale (AVI, MPEG, ecc..), avendo cura che questo rispetti i requisiti di interleaving (cfr ) 7

8 1 Audio e video streaming Flussi video Un flusso video è per definizione una sequenza di immagini ed è caratterizzato da quattro parametri che sono: risoluzione orizzontale (espressa in pixel) risoluzione verticale (espressa in pixel) frame per secondo (fps). Rappresenta il numero di immagini da visualizzare nell'unità di tempo. Formato dell'immagine. Esistono diversi standard di rappresentazione dell'immagine che sono indice di come questa venga discretizzata e immagazzinata in formato binario. In questo testo è fatto riferimento esclusivo al formato RGB o equivalente, che prevede la scomposizione di ogni singolo punto dell'immagine nelle tre componenti fondamentali additive: rossa (Red) verde (Green) e blu (Blue) con risoluzione di campionamento 8 bit per ogni componente. I formati più noti ed utilizzati, sono il formato PAL (720 x 576 x 25 fps) e il formato NTSC (720 x 480 x 29,97 fps). Accanto a questi standard sono nati altri sottoformati meno ingombranti e più adatti alle caratteristiche della rete. Non si tratta di standard veri e propri, bensì delle risoluzioni maggiormente utilizzate. Queste sono: (352 x 240 x 25 fps) - (340 x 288 x 25 fps): utilizzate per la conservazione di filmati su file e considerate equivalenti alla risoluzione degli attuali apparecchi televisivi. (352 x 240 x 15 fps) (340 x 288 x 15 fps) (160 x 120 x 15 fps): utilizzati per lo streaming media, differiscono dai precedenti per la minore occupazione di banda e sono conseguentemente più adatti alla trasmissione in rete. 8

9 1.2 Creazione del contenuto multimediale Flussi audio Sono caratterizzati da: Numero di canali Solitamente uno per streaming mono e due per streaming stereo, anche se possono essere presenti molti più canali. Frequenza di campionamento: Espressa in Hz, è l'equivalente del parametro fps dello streaming video. I valori più usati sono: 11 khz per gli streaming di bassa qualità, 22 khz per gli streaming di media qualità, 44 khz per i file audio di tipo mp3 e provenienti da sorgenti digitali tipo CD Audio e infine 48 khz solitamente impiegati nei formati DVD. Risoluzione: Numero di bit per campione. I valori tipici sono: 8 bit per qualità molto scadenti e 16 bit per tutti gli altri casi Interleaving Il concetto di interleaving nasce dalla necessità di far coesistere flussi di tipo diverso all'interno di un unico stream, per utilizzare quindi un solo canale di trasmissione seriale. La soluzione adottata è paragonabile al metodo Time Division Modulation (TDM) impiegato in telefonia. I due flussi in ingresso (composti dai frame del flusso video e dai campioni del flusso audio) vengono spezzati in pacchetti di dimensioni opportune, solitamente compressi ed infine disposti all'interno dello streaming finale in modo alternato (Figura 2). 9

10 1 Audio e video streaming t A... V... A V 5 5 A V A A Flusso audio t V A V V Flusso video Compressione Compressione V 3 A 3 V 2 t A V A Flusso finale Figura 2- Esempio di interleaving In questo processo, la componente video è considerata prioritaria rispetto alla componente audio e presa come riferimento per il calcolo di tutte le altre grandezze in gioco. Ogni pacchetto video (non ancora compresso) ha la dimensione in byte necessaria a contenere una singola immagine (frame). Essendo i due flussi in ingresso strettamente legati dal punto di vista temporale, ne segue che la durata di un pacchetto audio prima della compressione dovrà essere almeno pari alla durata di un singolo frame video, dove: durata frame video 1 fps durata frame audio dimensione pacchetto (byte) numero canali audio frequenza di campionamento byte per campione Imponendo uguali queste due grandezze e risolvendo la semplice equazione si ricava la dimensione in byte di un pacchetto audio (non compresso). Questa sarà data da: 10

11 1.2 Creazione del contenuto multimediale dimensione 1 fps canali audio frequenza di campionamento byte per campione Per un formato a 25 fps, con audio stereo a 22 khz si ha: durata frame video 40 ms 1 dimensione pacchetto audio byte Le relazioni sopra descritte garantiscono il sincronismo tra i due flussi. Resta comunque possibile sbilanciare le dimensioni del pacchetto audio oppure le sequenze con le quali si susseguono i pacchetti audio e video costringendo però l'utilizzatore a ricorrere a sistemi di bufferizzazione di tipo FIFO. Talvolta prima di inserire i pacchetti all'interno del flusso finale si ricorre ad un''operazione di compressione dati, che permette di ridurre la dimensione finali dello stream senza intaccarne i meccanismi di sincronismo (dato che in fase di utilizzo i flussi originali vengono ripristinati tramite un processo di decompressione). 11

12 1 Audio e video streaming Altri formati Lo streaming si presenta come un'architettura aperta e quindi adatta a supportare diverse tipologie di dati. E' possibile infatti immaginare che lo streaming sia una sorta di canale di trasmissione che collega le periferiche sorgenti collegate al computer server con le periferiche di utilizzo collocate presso il computer client. In quest'ottica gli streaming audio e video possono essere visti come canali trasmissivi che collegano ad esempio una telecamera posizionata sul server con lo schermo e gli altoparlanti del computer client. In modo analogo è possibile pensare il collegamento di qualunque tipo di periferica con la sua corrispondente: ad esempio una scheda di acquisizione dati può essere collegata al rispettivo visualizzatore grafico. Attualmente oltre ai formati audio e video questa tecnologia è utilizzata nelle presentazioni a distanza per il trasferimento temporizzato di immagini e testi 1.3 Data editing Applicabile solo nei casi in cui si effettua lo streaming da un file statico, il data editing è il processo durante il quale il materiale acquisito e salvato su file viene modificato. Tramite appositi pacchetti software è infatti possibile aggiungere simboli, sottotitoli, eliminare e aggiungere sequenze, tracce audio e quanto altro necessita per fornire al file multimediale il suo aspetto definitivo. Al fine della ricerca svolta, questo processo risulta di scarsa importanza e pertanto non approfondito. 12

13 1.3 Data editing 1.4 Data Encoding I dati in uscita dalla sorgente hanno caratteristiche tali da non essere adatti alla trasmissione in rete. Infatti anche per un filmato di qualità molto modesta come il 160 x 120 x 15 fps con audio stereo a 22 khz, 16 bit per campione è necessario un flusso di dati costante con velocità pari a 3,7 Mbit/s. Il processo di data encoding è rivolto quindi a ridurre l'occupazione in banda e ad ovviare al fatto che la rete, per come è costituita, non garantisce una velocità di trasmissione costante. Il primo problema viene risolto applicando ai flussi di ingresso un algoritmo di compressione dati, le cui caratteristiche variano a seconda del software scelto per effettuare il data encoding (cfr. 3). Per ovviare alla velocità di trasmissione non costante, si utilizza una trasmissione a pacchetti dei due flussi rispettando le regole di interleaving descritte precedentemente. Ogni pacchetto trasmesso contiene un'intestazione o header (Figura 3) che oltre ad identificare il tipo di pacchetto audio o video (ID) contiene un campo speciale chiamato time stamp. Questo indica a chi riceve il pacchetto l'istante temporale al quale lo stesso dovrà essere utilizzato. HEADER Video Id Time stamp Frame compresso Figura 3 - Esempio di pacchetto video 13

14 1 Audio e video streaming In questo modo velocità variabili non costituiscono più un problema: sarà chi riceve il flusso dati a renderne costante la velocità in fase di utilizzo (Figura 4). Computer Server Rete Computer Client Figura 4 - Regolazione velocità pacchetti con metodo time stamp 1.5 Streaming delivery Questa fase racchiude tutte procedure necessarie per il trasferimento dei pacchetti dati dal computer server al computer client. Inizialmente è il computer client ad aprire la connessione verso il server, comunicando tramite un socket internet la sua intenzione a ricevere un particolare documento di streaming. A questo punto il server effettua l'identificazione del client, verifica che questo abbia le autorizzazioni e le caratteristiche di banda adatte a ricevere il documento richiesto e procede all'invio dello stesso. 14

15 1.5 Streaming delivery La trasmissione dati può avvenire tramite il protocollo di trasmissione dati TCP o UDP. Solitamente è il server a decidere quale protocollo utilizzare in base ad alcuni test di banda che effettua con il client. La scelta però cade solitamente sul protocollo UDP che ha come vantaggi quello di adattarsi bene alla struttura a pacchetti tipica dello streaming e non richiede troppe risorse di sistema al server (una porta UDP non è aperta in modo esclusivo per un solo client). Dopo aver stabilito il protocollo, l'instradamento dei pacchetti avviene tramite i normali meccanismi della rete, senza nessun particolare accorgimento. Di norma viene anche implementato un canale di ritorno di tipo TCP utilizzato per l'handshaking e per eventuali richieste di ritrasmissione di pacchetti persi. E' comunque possibile utilizzare un canale TCP anche per la trasmissione dati: sia il server sia il client possono infatti forzare il tipo di protocollo da utilizzare. 1.6 Streaming play La fase conclusiva del processo di streaming è rappresentata dallo streaming play. Il client per mezzo di un apposito software (generalmente chiamato player) identifica e decomprime i pacchetti ricevuti, ricostruisce i flussi audio/video e li invia alle periferiche corrispondenti. Il player può interagire con il server tramite alcuni comandi fissi, inviati tramite il canale TCP di ritorno, che permettono all'utente di fermare ed avviare la riproduzione (e la conseguente trasmissione dati da parte del server). Qualora si effettui lo streaming di una sorgente statica (file), l'utente finale ha a disposizione alcuni comandi aggiuntivi, quali il riavvolgimento e l'avanzamento veloce. 15

16 1 Audio e video streaming 2 Obiettivo della tesi La tecnologia di streaming audio/video appena descritta, sebbene supportata da continue innovazioni tecnologiche volte ad incrementarne le prestazioni in termini di banda passante e velocità, difetta purtroppo per quanto riguarda il livello di interattività permesso ai suoi utenti. L'utilizzatore di un sistema streaming infatti interagisce con il flusso video ricevuto in modo marginale, potendo compiere solo operazioni di tipo start stop (cfr. 1.6) Inoltre il server che effettua lo streaming provvede alla gestione degli utenti e dei collegamenti in modo molto efficiente, ma non è in grado di interagire in alcun modo con il contenuto multimediale che distribuisce in rete. L'obiettivo di questa testi è lo studio di un'architettura di streaming multimediale interattiva, che integrandosi con gli attuali software di streaming esistenti permetta l'adattamento in tempo reale di uno o più flussi audio/video in funzione delle azioni di un utente. Inizialmente nel capitolo 3 si analizzeranno i principali pacchetti software per la gestione di audio/video streaming al fine di individuare il più versatile ed adatto alla realizzazione proposta. Di seguito nel capitolo 4 si motiveranno alcune scelte di progetto inerenti le configurazioni hardware e software da utilizzare per la realizzazione del progetto (lato client e lato server). Successivamente nel capitolo 5 si realizzerà un'applicazione di tipo prototipale atta a dimostrare la validità delle scelte effettuate in precedenza. Questa permetterà di effettuare test e misurazioni che consentiranno di stabilire le caratteristiche ed i limiti del sistema implementato, permettendo così nel capitolo 6 di valutare i possibili sviluppi futuri. 16

17 2 Obiettivo della tesi 17

18 2 Obiettivo della tesi 3 Software di audio/video streaming 3.1 Introduzione Il mercato dello streaming media è dominato da tre famose compagnie: la Microsoft, la RealNetworks, e la Apple, che con i loro prodotti coprono la quasi totalità degli streaming che avvengono in rete. Per poter scegliere il prodotto più adatto, sono stati presi in considerazione diversi aspetti, quali le caratteristiche fondamentali, le possibilità di interfacciamento, la documentazione fornita, i tipi di hardware e software supportati, l'attuale diffusione in rete, ecc... Di seguito vengono descritte le architetture adottate dalle tre case ed elencati i punti favorevoli e contrari di ogni architettura. 3.2 Microsoft La soluzione Microsoft utilizza tre programmi : Windows Media Encoder, Windows Media Services e Windows Media Player. Il primo, eseguito su un computer server, provvede ad effettuare la parte di streaming relativa al data encoding. Il secondo invece si occupa di gestire lo streaming delivery. E' in grado di pubblicare in rete file multimediali e collegandosi al Media Encoder anche eventi live (il collegamento avviene tramite socket internet). Il server che lo ospita può essere lo stesso del Media Encoder, ma deve necessariamente essere dotato di un sistema operativo Windows NT Server 1. Il terzo, da utilizzarsi sui computer client, provvede allo streaming play. E' 1 Con NT server, si intendono tutti i sistemi operativi Microsoft implementati con tecnologia NT (come Windows 2000 server ad esempio) 18

19 3.2 Microsoft supportato da tutte le versioni di windows. Media Player Media Encoder Media Services Client 1 OS: Microsoft Windows Media Player Server 1 OS: Microsoft Windows Server 2 OS: Microsoft NT Server Client 2 OS: Microsoft Windows Figura 5 - Streaming Microsoft Il punto di forza dello streaming Microsoft sta nell'elevata diffusione e popolarità del Media Player (presente in ogni versione in commercio del sistema operativo Windows). Numerosi sono risultati invece i punti a sfavore. Primo tra tutti la scarsa documentazione, che si è dimostrata poco chiara, troppo generica e con pochi esempi. Da questa è risultato che il Media Encoder non fornisce nessuna interfaccia di ingresso dati, potendo esclusivamente acquisire i flussi audio/video direttamente dalle periferiche multimediali collegate al computer 19

20 3 Software di audio/video streaming server. L'unico metodo per inviare un flusso audio/video al Media Encoder per la successiva pubblicazione, è quello di implementare un driver (di tipo VXD, SYS o WDM in funzione della versione del sistema operativo scelto) che emuli una scheda di acquisizione o un dispositivo A/V. Un altro aspetto negativo è causato dal fatto che lo streaming Microsoft è progettato per funzionare con sistemi hardware basati esclusivamente su processori della famiglia x86 e con sistemi operativi Windows, escludendo in tal modo tutte le altre architetture esistenti. Infine Media Services è supportato solo da Windows NT Server, che come noto presenta problemi di stabilità e sicurezza nell'ambito della applicazioni per la rete. Sebbene questa linea di progetto sia realizzabile, è di fatto sconsigliabile, anche per l'elevata complessità del driver da realizzare, soprattutto nell'ottica di progettare un sistema in grado di gestire più utilizzatori. 3.3 RealSystem L'architettura implementata dalla RealSystem è basata su tre prodotti che sono in stretta analogia con i componenti del pacchetto Microsoft; questi sono: Real Producer, Real Server e Real Player. Come nel caso precedente il primo gestisce il data encoding, il secondo lo streaming delivery ed il terzo lo streaming play. 20

21 3.3 RealSystem Real Player Real Producer Real Server Client 1 Real Player Server 1 Server 2 Figura 6 - Streaming RealSystem Client 2 Contrariamente a quanto accade per le altre compagnie, la RealSystem si occupa esclusivamente di streaming e non realizza nessun tipo di sistema operativo. Il software implementato da questa casa presenta di conseguenza un grosso vantaggio: quello di essere multi-piattaforma e quindi operare sulla maggior parte dei sistemi operativi oggi utilizzati (Windows, Solaris, Linux- Unix, MacOs). Analizzando la documentazione completa e molto ben dettagliata, si comprende l'estrema versatilità dell'architettura sviluppata dalla RealSystem. Real Producer, che ovviamente gestisce i flussi provenienti dalle periferiche A/V, è fornito di un'interfaccia per l'ingresso dati, attraverso la quale è possibile inserire frame video e campioni audio. Un software esterno può quindi abbastanza agevolmente interfacciarsi al Real Producer ed inviare i dati al Real Server per la pubblicazione. Lo stesso Real Server è molto versatile. Prevede il trasporto di quattro tipi di media: audio, video, singole immagini (RealPix) ed eventi web (RealEvent), ma se queste tipologie non fossero sufficienti è possibile realizzare piccoli moduli aggiuntivi (plug-in) che adattano Real Server a qualunque tipo di streaming. 21

22 3 Software di audio/video streaming Tra le caratteristiche favorevoli si collocano anche: Buona diffusione del Real Player (scaricabile gratuitamente). Uso gratuito del Real Producer e del Real Player Disponibilità di utilizzare la versione Trial del Real Server per un anno, senza alcuna limitazione funzionale. Unica nota dolente del sistema è la lentezza con la quale RealSystem supporta le nuove versioni dei diversi sistemi operativi: in particolare in ambiente Solaris, è supportata la versione 7 (la versione 8 è supportata solo a mezzo di patch), e in ambiente Linux, è supportato solo il Kernel 2.2 ed il compilatore gcc versione Le caratteristiche sopra elencate, rendono lo streaming RealSystem il più adatto alla realizzazione del progetto. 3.4 Apple Quicktime Si tratta del pacchetto sviluppato da Apple. Prevede QuickTime Broadcaster, QuickTime server e QuickTime Player. In modo analogo ai casi precedenti il primo modulo gestisce il data encoding, il secondo lo streaming delivery ed il terzo lo streaming play. Sebbene sia lo standard più utilizzato su sistemi Mac, ha scarsa diffusione per quanto riguarda tutti gli altri utilizzatori. Inoltre il prodotto QuickTime Broadcaster, indispensabile per eventi live è disponibile esclusivamente per architetture Mac. In via teorica, è possibile interagire direttamente con il QuickTime Server, in 22

23 3.4 Apple Quicktime quanto ne esiste una distribuzione OpenSource (Darwin) funzionante con OS X, Solaris, Linux e Windows 2000, ma questo genere di interazione risulta sconveniente e quindi sconsigliabile. 23

24 3 Software di audio/video streaming 4 Scelte di progetto ed applicazione prototipale 4.1 Introduzione Nel capitolo precedente è stato individuato il pacchetto software che maggiormente si adatta alla realizzazione di un sistema di streaming multimediale interattivo. In base alla scelta effettuata è ora possibile definire la struttura generale dell'intero progetto approfondendo in particolar modo l'architettura hardware, i sistemi operativi utilizzati e la struttura funzionale del software prototipale realizzato. 4.2 Architettura generale del progetto 7. L'architettura generale implementata nel progetto è rappresentata in figura Figura 7 - Schema generale architettura implementata 24

25 4.2 Architettura generale del progetto Dallo schema presentato in figura si vede che il cuore dell'intero progetto è costituito dal software prototipale Multimedia Mixing Server il quale acquisisce i flussi multimediali contenuti su file, li rielabora in tempo reale secondo le richieste dell'utente e li distribuisce in rete al client utilizzando lo streaming RealSystem. Il lavoro di programmazione ha riguardato esclusivamente il lato server dell'intera architettura. Nessun accorgimento particolare o lavoro di programmazione è stato quindi svolto sul computer client che utilizza esclusivamente il proprio sistema operativo ed il Real Player. Prima di entrare nel dettaglio dell'applicazione prototipale, è bene definire l'architettura hardware ed i sistemi operativi usati nel progetto. 4.3 Architettura hardware e software di sistema La configurazione scelta è la seguente: Rete Server Client Figura 8 - Architettura hardware utilizzata Per minimizzare l'utilizzo di risorse si sceglie di eseguire Real Producer, Real Server ed il software prototipale di mixing (Multimedia Mixing Server) sullo stesso computer server. Nel caso in cui le prestazioni risultassero non soddisfacenti, sarà possibile rivedere questa scelta. 25

26 4 Scelte di progetto ed applicazione prototipale Architettura server Il server deve rispondere a due requisiti fondamentali: potenza e stabilità. E' stato quindi utilizzato un computer basato su processore AMD Athlon XP a 1533 MHz, con 512 MByte di RAM DDR e hard disk IDE ATA 100. Tale configurazione garantisce potenza di calcolo e velocità di trasferimento dati. Come sistema operativo è stato scelto un sistema unix (per la precisione Linux distribuzione Red Hat 7.0) che presenta grande versatilità, stabilità in rete e buoni strumenti di analisi e debugging, oltre alla caratteristica apprezzabile di essere un sistema operativo gratuito Architettura client Le caratteristiche del computer client sono praticamente ininfluenti al fine del progetto. I test sono stati effettuati utilizzando come client un PC di media potenza funzionante con sistema operativo windows Caratteristiche di rete La rete è un aspetto importante dell'applicazione. Sebbene il sistema di streaming RealSystem si possa adattare alle diverse velocità dell'interfaccia di rete e della rete stessa (Appendice C, pagina 75 ), quest'ultima deve comunque garantire prestazioni sufficienti. Ad una maggiore velocità della rete corrisponde una migliore qualità dello streaming, in termini di frame rate e di qualità delle immagini. 26

27 4.3 Architettura hardware e software di sistema In questo caso è stata utilizzata la rete LAN 2 del Politecnico di Torino che permette trasmissioni a 100 Mbit/s e quindi altissima qualità di streaming in condizioni di basso o medio carico. 2 LAN: Acronimo di Local Area Network. Generalmente si tratta di connessione ad alta velocità (10 o 100 Mbit/s ) tra calcolatori situati nello stesso edificio o in edifici adiacenti. 27

28 4 Scelte di progetto ed applicazione prototipale 4.4 Applicativo prototipale Multimedia Mixing Server Architettura generale Multimedia Mixing Server (MMS) è un software di tipo prototipale che effettua lo streaming in rete di flussi a/v, generati in tempo reale. Il programma racchiude in sé le caratteristiche di un mixer video e quelle di un mixer audio, essendo in grado di miscelare tra loro secondo le richieste di un utente: fino a due flussi video provenienti da file diversi (tipicamente AVI o MPEG) sequenze di immagini flussi audio (in formato AVI o WAV) Il flusso a/v così generato viene poi inviato al Real Producer SDK e tramite Real Server raggiunge il computer client dove viene utilizzato (Figura 9). Figura 9 - Schema di funzionamento MMS 28

29 4.4 Applicativo prototipale Multimedia Mixing Server E' bene ricordare che sebbene il formato AVI goda di una larghissima diffusione, non è totalmente supportato dai sistemi operativi Unix-like. Per decodificare i file AVI ed MPEG sotto Unix, Multimedia Mixing Server utilizza le librerie FFMPEG versione 0.45; un lavoro di Gerard Lantau che supporta diversi codec AVI. Un elenco dei formati supportati è riportato in Appendice A, pagina Prerequisiti Affinché MMS funzioni in modo corretto, i file multimediali in ingresso devono soddisfare alcuni requisiti, che sono: I formati dei file devono essere supportati dalle librerie FFMPEG I flussi video devono avere le stesse caratteristiche: in particolare devono avere la stessa risoluzione in pixel e lo stesso frame rate. I flussi audio devono avere la stessa frequenza di campionamento e la stessa risoluzione (bit per campione). Nessun limite è imposto però ai parametri stessi: il software può effettuare il mixing e lo streaming di flussi audio a qualunque frequenza e flussi video a qualunque risoluzione/frame rate. Gli unici vincoli in tale direzione provengono dall' hardware utilizzato, e sono funzione della potenza del server e della velocità della rete. Si precisa che sebbene i file di ingresso abbiano lo stesso formato, possono però differire tra loro per quel che riguarda le caratteristiche di interleaving e di impacchettamento dati. Per ovviare a questi inconvenienti, MMS utilizza per ciascun flusso audio / video in ingresso, un sistema di buffer (di tipo FIFO) associato a tecniche di lettura sincronizzata; queste permettono di ridurre le dimensioni dei buffer video a contenere una singola immagine. I buffer audio invece sono dimensionati per contenere 5 secondi di dati. Una 29

30 4 Scelte di progetto ed applicazione prototipale dimensione così elevata è utile quando si utilizzano entrambi i flussi di uno stesso file AVI; infatti per riempire nuovamente il buffer video con un solo frame, è necessario conservare tutti i pacchetti audio che lo precedono. La dimensione scelta si è rivelata adatta durante tutti i test effettuati Conversioni di formato Le librerie FFMPEG possono essere considerate come un'adattatore che trasforma le differenti tipologie di file di ingresso in un formato audio/video di uscita sempre uguale. L'audio in uscita è composto dalla sequenza dei campioni a 16 bit organizzati in byte, LSB first (Less Significative Byte) come mostrato l'esempio di Figura 10. Lo stesso formato dati appena descritto è utilizzato in ingresso al pacchetto Real Producer SDK. Figura 10 - Libreria FFMPEG: Formato audio di uscita (codifica LSB First) Lo stesso discorso non vale per il flusso video, in quanto il formato dati in uscita dalle librerie FFMPEG non corrisponde al formato dati di ingresso del Real Producer. Consideriamo un singolo frame: i colori dei pixel che lo compongono 30

31 4.4 Applicativo prototipale Multimedia Mixing Server vengono scomposti nelle tre componenti fondamentali RGB (con campioni a 8 bit per colore). Per ogni pixel sono quindi necessari 3 byte. L'ordine con cui i pixel vengono decodificati dalle librerie FFMPEG è il seguente: prima da sinistra a destra e poi dall'alto al basso (in pratica riga per riga, come il comune sistema di lettura di un testo). Figura 11 - Scansione Pixel di un'immagine Il formato richiesto in ingresso dal Real Producer SDK è differente: in quanto i pixel sono codificati con le componenti R e B invertite (in pratica BGR) ed anche l'ordine di scansione è differente, poiché questo deve essere da sinistra a destra e dal basso all'alto. In pratica la scansione dei dati comincia dall'ultima riga e retrocede fino alla prima. Questa operazione è effettuata dal mixer a/v che mentre miscela i flussi video, provvede anche a capovolgere l'ordine di scansione delle righe e a scambiare le componenti colore. Maggiori dettagli sull'interfaccia delle librerie Real Producer sono disponibili in Appendice D a pagina 77 del presente testo Struttura principale dell'applicativo L'intero software è stato sviluppato utilizzando il linguaggio C /C++ e compilato utilizzando gcc versione 2.96, incluso nella distribuzione del sistema operativo. L'approccio alla programmazione adottato è stato di dividere il programma in più moduli separati, ciascuno dei quali si occupa di un aspetto diverso del problema. Questa tecnica, oltre ad essere una buona norma, è stata 31

32 4 Scelte di progetto ed applicazione prototipale resa necessaria da alcune incompatibilità riscontrate tra le librerie di streaming e quelle di decodifica dei file multimediali. Lo schema di funzionamento del programma può essere rappresentato tramite il seguente flow chart. Figura 12 - Flow chart struttura principale MMS In una prima fase Multimedia Mixing Server comunica all'interfaccia di Real Producer le caratteristiche dello streaming da effettuare. In particolare vengono indicati dati quali la velocità di connessione del client, il formato audio, il formato video e il nome con il quale lo streaming verrà pubblicato in 32

33 4.4 Applicativo prototipale Multimedia Mixing Server rete 3. Successivamente il software legge ed interpreta i possibili comandi provenienti da un utente, effettua il mixaggio dei vari flussi secondo le indicazioni ricevute ed infine passa il flusso generato in tempo reale all'interfaccia Real Producer per la pubblicazione. Alcuni passaggi sopra elencati sono relativamente semplici, pertanto se ne tralascia il commento invitando il lettore interessato a consultare direttamente i sorgenti del programma. Altri passaggi sono invece particolarmente importanti per comprendere appieno i meccanismi di streaming interattivo, e pertanto vengono approfonditi nei capitoli seguenti Invio flusso A/V a Real Producer Come visto nel paragrafo 1.4, il sistema di streaming integra in ogni pacchetto un codice numerico denominato time stamp, che indica l'istante temporale al quale il pacchetto dovrà essere utilizzato. Questo codice garantisce al client una certa flessibilità per quanto riguarda la velocità di ricezione dei dati, ma impone allo stesso tempo delle restrizioni al software di mixing, che non solo dovrà supportare la velocità del flusso richiesta dal sistema, ma dovrà inviare i pacchetti audio e video in modo sincronizzato rispetto al times tamp. Il passaggio dei pacchetti che compongono il flusso a/v è stato implementato secondo il seguente schema: 3 Tipicamente il file viene pubblicato in rete combinando l'indirizzo del server con il numero indicato all'interfaccia Real: qualcosa del tipo rtsp://serverip/encoder/nomeindicato 33

34 4 Scelte di progetto ed applicazione prototipale Figura 13 - Flow chart invio sincronizzato flusso A/V all'interfaccia Real Producer 34

35 4.4 Applicativo prototipale Multimedia Mixing Server Si fa presente che in ingresso al flow chart, tutti i buffer FIFO si ipotizzano già caricati con i rispettivi dati. Durante la fase di mixaggio i flussi multimediali vengono combinati in uno solo. In uscita dal blocco di mixing, nel buffer video sarà presente un frame, mentre nel buffer audio saranno presenti una serie di campioni audio. La dimensione ideale di quest'ultimo buffer è suggerita direttamente dall'interfaccia di Real Producer durante l'inizializzazione della stessa. Di seguito vengono calcolati i due time stamp relativi al pacchetto video ed al pacchetto audio. Si ricorda che il time stamp indica un istante temporale, che aumenta di volta in volta di quantità calcolabili con le formule del capitolo Successivamente il programma aspetta che giungano gli istanti di tempo indicati dai timestamp e conseguentemente invia i pacchetti all'interfaccia. I pacchetti vengono sempre inviati in modo alternato, audio video audio video ecc. Nel caso in cui il programma sia in anticipo rispetto ai tempi indicati dai time stamp, rilascia tempo di CPU permettendo ad altre risorse di avere più potenza di calcolo. Questo passo è reso necessario perché il software è destinato ad essere utilizzato su un computer server e non è ammissibile (se non in situazioni critiche) che un processo occupi il 100% del tempo di CPU. Durante i tempi di attesa, in modo periodico, MMS presenta a video alcuni dati statistici, in particolare vengono presentati il tempo di codifica totale, il frame rate ed il tipo di effetto video applicato. E' infine interessante notare che l'invio dati è autoregolante: se per qualche motivo il server arriva in ritardo con la codifica (magari a causa di altri processi funzionanti sul server), al ciclo seguente la procedura riduce 35

36 4 Scelte di progetto ed applicazione prototipale automaticamente il tempo di rilascio CPU, permettendo di fatto il recupero. Questo particolare dell'implementazione permetterà di valutare le prestazioni del sistema. Infatti al crescere delle caratteristiche dello streaming da utilizzare (ad esempio all'aumentare della risoluzione del video, del frame rate o della frequenza di campionamento dati) il processo tenderà ad occupare sempre più tempo di CPU; arrivato al 100% non riuscirà più a trasmettere al frame rate richiesto, continuando comunque alla massima velocità possibile Mixing A/V Con il termine Mixing si intende la miscelazione dei flussi a/v provenienti dalle sorgenti esterne. Il software MMS implementa un mixer a due canali, (di seguito chiamati canale 1 e canale 2) ciascuno dei quali può essere composto da un flusso audio, un flusso video e da immagini statiche. Si noti che i singoli flussi di ogni canale possono provenire tutti dallo stesso file (ad esempio un unico file AVI), oppure ciascuno da un diverso file multimediale. La scelta è del tutto arbitraria. I tipi di mixaggio video ottenibili sono riportati in Figura 14, dove i frame dei due canali sono contraddistinti da toni di grigio differenti: 36

37 4.4 Applicativo prototipale Multimedia Mixing Server Figura 14 - Effetti video disponibili La funzione che genera questi effetti video si chiama PIPN, ed è in grado di inserire un'immagine opportunamente scalata all'interno di un'altra a dimensione intera. L'effetto generato assume il nome di Picture in picture (PIP). PIPN è molto versatile e permette inserendo alcuni semplici parametri, di generare molti effetti video come quelli sopra riportati. I parametri da impostare sono: Fattore di scala dell'immagine più piccola. Posizione dell'immagine più piccola all'interno dell'immagine più grande 37

38 (coordinate x e y espresse in pixel). 4 Scelte di progetto ed applicazione prototipale Buffer FIFO dei due frame (sotto forma di puntatori) Il risultato di questa operazione è un'immagine pronta per essere utilizzata da Real Producer, in quanto il mixer, generando la nuova immagine, si occupa anche di adattarne il formato (cfr ). Di seguito sono riportate alcune immagini di esempio che permettono di verificare come funzioni nel caso pratico la funzione PIPN e la qualità ottenibile dal sistema. I fotogrammi riportati sono stati ottenuti catturando le immagini dello schermo del computer client, mentre il Real Player era in funzione. Per la dimostrazione sono stati utilizzati due video musicali del gruppo irlandese U2 (per la precisione il videoclip della canzone One ed il videoclip della canzone Elevation ). Figura 15 - Effetto PIP TIPO 1 38

39 4.4 Applicativo prototipale Multimedia Mixing Server 39

40 4 Scelte di progetto ed applicazione prototipale Figura 16 - Effetto PIP TIPO 2 Figura 17 - Effetto PIP TIPO 3 40

41 4.4 Applicativo prototipale Multimedia Mixing Server 41

42 4 Scelte di progetto ed applicazione prototipale Figura 18 -Effetto PIP TIPO 4 Figura 19 - Effetto PIP TIPO 5 42

43 4.4 Applicativo prototipale Multimedia Mixing Server Figura 20 - Effetto PIP TIPO 6 (Dinamico) Un' ultima nota sul mixing dei flussi audio: il flusso audio di uscita è sempre quello associato al canale che ha il frame video a schermo intero Interattività del sistema Come accennato in precedenza, MMS implementa una nuova classe di streaming, che può essere definita streaming interattivo. E' possibile immaginare due tipologie di interazione diverse: interazione libera : l'utente gestisce direttamente il mixer audio/video, inviando i comandi corrispondenti nei modi e nei tempi a lui preferiti. interazione guidata : l'utente seleziona da un elenco grande a piacere, uno o più file che contengono sequenze preimpostate di comandi che andranno a gestire il mixer audio/video. Dato che i due tipi di interazione non sono tra loro compatibili sono state 43

44 4 Scelte di progetto ed applicazione prototipale realizzate due implementazioni diverse del programma MMS: la prima che permette l'interazione libera, la seconda che permette l'interazione guidata. Nei capitoli seguenti sono descritte le specifiche più significative delle due implementazioni. Resta comunque inteso che le caratteristiche e le soluzioni fino a qui descritte sono comuni ad entrambe le implementazioni, e quindi valide MMS: Implementazione interazione libera Il software dimostrativo prevede di utilizzare due file in formato AVI contenenti un videoclip musicale ciascuno. I video utilizzati sono in formato 352x288 con 25 fps e le tracce audio sono stereo con frequenza di campionamento 32 khz. Il progetto completo prevede che l'utente dal computer client invii al server tramite la rete i comandi per effettuare il mixaggio. Trattandosi però di un'applicazione di tipo prototipale, e quindi volta a testare le funzionalità del sistema, è stato implementato un metodo più sbrigativo che prevede l'invio di comandi direttamente dalla tastiera del computer server. I comandi implementati sono i seguenti. 44

45 4.4 Applicativo prototipale Multimedia Mixing Server Comandi da tastiera Tasto Comando Descrizione G Inizio mixing L'applicativo attende questo comando per iniziare a mixare i due videoclip. Nel frattempo effettua lo stream di un segnale di test (barre colore o monoscopio). Q Termina programma Questo comando termina l'esecuzione del programma. 0 Effetto FULLSCREEN Imposta l'effetto di mixing indicato 1 Effetto PIP tipo 1 Imposta l'effetto di mixing indicato 2 Effetto PIP tipo 2 Imposta l'effetto di mixing indicato 3 Effetto PIP tipo 3 Imposta l'effetto di mixing indicato 4 Effetto PIP tipo 4 Imposta l'effetto di mixing indicato 5 Effetto PIP tipo 5 Imposta l'effetto di mixing indicato R Effetto PIP tipo 6 (rimbalzo) Imposta l'effetto di mixing indicato S swap Scambia il canale 1 con il canale 2 F Frame rate Visualizza un elenco di dati statistici (ad esempio il frame rate) Tabella 1 - Elenco comandi disponibili da tastiera Il canale impostato di default è il canale 1. Per la descrizione degli effetti si rimanda al paragrafo

46 4 Scelte di progetto ed applicazione prototipale MMS: Implementazione interazione guidata In questa modalità, le regole di mixaggio vengono preimpostate all'interno di un file di controllo che interagisce con il mixer a/v. Per realizzare il programma dimostrativo di questa funzionalità si è immaginato di dover distribuire in rete un filmato in più lingue contenente un normale flusso audio/video inframmezzato da lucidi (quale può essere ad esempio una videolezione del Politecnico). Il materiale sorgente è composto da una singola traccia video, da n tracce audio e da n file contenenti i lucidi. Il client seleziona il linguaggio desiderato; il file di controllo ne coordina il mixaggio video/lucidi/audio. (Figura 21). 46

47 4.4 Applicativo prototipale Multimedia Mixing Server FILE DI CONTROLLO TRACCIA VIDEO (AVI) AUDIO LUCIDI MIXER LINGUA 1 ESPERIMENTO FISICA AUDIO LUCIDI LINGUA 2 SCELTA CLIENT AUDIO LUCIDI LINGUA n Figura 21 - Schema di funzionamento Interazione guidata in MMS Per motivi analoghi all'implementazione precedente, l'interazione del client viene effettuata direttamente dalla tastiera del server. Le scelte sono quindi comunicate a MMS come parametri da linea di comando durante l'esecuzione dello stesso; questo permette di supportare più utenti contemporaneamente e più linguaggi utilizzando sessioni diverse dello stesso applicativo. 47

48 4 Scelte di progetto ed applicazione prototipale Formato file di controllo mixer Il file di controllo è l'equivalente della timeline dei programmi di video editing. Si tratta in pratica di una sequenza di comandi che devono essere eseguiti dal mixer a/v ad istanti di tempo ben precisi. La precisione ottenibile con questo metodo è infatti pari alla durata del singolo frame e quindi impossibile ad ottenersi con l'interazione libera. Il file è un semplice file di testo, scritto in linguaggio simile a SMIL ed è modificabile con qualunque editor di testi. Nel file non sono al momento previsti header o terminatori: la sequenza di comandi termina con la fine del file. Ad ogni linea del file è associato un comando distinto. Ogni linea ha il seguente formato: Offset (byte) TIMECODE IN TAB TIMECODE OUT TAB LUCIDO TAB EFFETTO TAB STOP FLAG COMMENTI Figura 22 - Formato file di controllo per lucidi dove: TIMECODE IN: Riferimento temporale. E' l'istante di inserimento del lucido nel flusso video principale (riferito al video principale stesso). Ha forma: HH:MM:SS.mmm dove : HH rappresentano le ore MM i minuti SS i secondi mmm i millesimi. 48

49 4.4 Applicativo prototipale Multimedia Mixing Server TIMECODE OUT: Analogo al timecode in: è l'istante di fine utilizzo del lucido. LUCIDO: Indica il numero ordinale (a quattro cifre) del lucido da proiettare: i valori possibili vanno da 0000 a Nell'attuale implementazione prototipale questo parametro viene ignorato: i lucidi sono contenuti all'interno di un unico file AVI chiamato SLIDE.AVI. Grazie a questa scelta è stato possibile utilizzare per la lettura dei lucidi le stesse funzioni fornite dalle librerie FFMPEG. Il parametro lucido è stato inserito nell'ottica di una nuova implementazione del software Multimedia Mixing Server nella quale i lucidi sono salvati su disco in file separati; dal parametro lucido sarebbe così possibile risalire al nome del file da leggere (0000.gif ad esempio oppure 0000.jpg a seconda dei formati di immagine supportati). EFFETTO: Indica il tipo di effetto desiderato. I valori possibili vanno da 00 a 99. Il loro significato è riportato in Tabella 2. CODICE EFFETTO TIPO EFFETTO 00 Fullscreen video 01 Fullscreen lucido 02 PIP tipo 1* 03 PIP tipo 1 04 PIP tipo 2* 05 PIP tipo 2 06 PIP tipo 3* 07 PIP tipo 3 08 PIP tipo 4 * 09 PIP tipo 4 10 PIP tipo 5 * 11 PIP tipo 5 12 PIP tipo 6 * 13 PIP tipo 6 Tabella 2 - Codici effetti del file di comando 49

50 4 Scelte di progetto ed applicazione prototipale Per le descrizioni degli effetti si rimanda alla Figura 14, paragrafo Gli effetti contrassegnati dall'asterisco in tabella indicano che il lucido appare in riquadro ed il filmato a schermo intero, viceversa per quelli senza l'asterisco. STOP FLAG: Campo di tipo booleano(0 = falso; 1=vero). Quando lo stop flag è attivo, il video e l'audio vengono messi in pausa (fermo immagine). Il flag è utilizzato per effettuare titolazioni senza perdere i frame del filmato principale. Commenti: Ogni carattere inserito dopo il campo di stop flag viene ignorato. E' quindi possibile inserire un commento per ogni linea di comando. TAB:(CODICE ASCII 8). Ha funzione di separazione tra i campi ed effettua una tabulazione in fase di editing. Note conclusive: Questa implementazione comporta alcune modifiche nella parte di lettura dei file multimediali, in particolare è implementata la possibilità di mettere in pausa la lettura di un qualunque flusso. E' stata infine inserita una procedura che provvede alla lettura e all'interpretazione del file di comando. Per ulteriori informazioni si invita a consultare il listato del programma. 50

51 4.4 Applicativo prototipale Multimedia Mixing Server 5 Analisi prestazioni e funzionalità ottenibili 5.1 Introduzione Questo capitolo approfondisce le prestazioni ottenibili del programma prototipale Multimedia Mixing server. I dati raccolti ed analizzati permettono infatti di determinare caratteristiche fondamentali dell'applicativo, quali il tempo che intercorre tra il comando impartito dall'utente e la visualizzazione del risultato, la potenza richiesta al server per effettuare lo streaming di flussi video con diverse caratteristiche, il numero di utenti gestibili da un singolo server, ecc... Analizzando questi dati sarà possibile comprendere la validità del sistema implementato, le possibili migliorie e le funzionalità ottenibili con lo streaming multimediale interattivo. Per fornire una panoramica vasta e significativa sono state utilizzate due configurazioni hardware differenti che presentano caratteristiche di potenza crescenti. Queste sono: Configurazione 1: AMD K6 II 500 MHz 320MBytes RAM DIMM Hard Disk IDE UDMA33 Configurazione 2: AMD Athlon XP (1533 MHz) 512 MByte di RAM DDR Hard Disk IDE ATA

52 5 Analisi prestazioni e funzionalità ottenibili 5.2 RITARDO DEL SISTEMA (tempo di loop) Con ritardo del sistema (tempo di loop) si intende il tempo che intercorre tra il comando dell'utente al server (ad esempio cambio di effetto video) ed effettiva visualizzazione dello stesso. Comando Visualizzazione Figura 23 - Tempo di Loop Dalle prove effettuate è risultato che questo tempo non dipende dalla potenza del client e del server, ma esclusivamente dalla dimensione del buffer di ricezione utilizzato dal client e dalla velocità di trasmissione della rete. A tal proposito si ricorda che il buffer è utilizzato dal client per sopperire alle variazioni di velocità della rete (metodo time stamp, cfr. 1.4). Il tempi ottenuti si attestano mediamente intorno ai 25 secondi anche se in condizioni ottimali di traffico, con la rete del Politecnico questi tempi si stabilizzano intorno ai 14 secondi. 52

53 5.2 RITARDO DEL SISTEMA (tempo di loop) Durante le prove per la misurazione del tempo di loop, si è riscontrato inoltre che detto tempo rimane costante per la durata di ogni singola prova. 53

54 5 Analisi prestazioni e funzionalità ottenibili 5.3 CARICO CPU e MASSIMO FRAME RATE. Il CARICO CPU indica la percentuale di potenza di calcolo utilizzata da Multimedia Mixing Server rispetto alla potenza di calcolo totale. Le prove sono state effettuate utilizzando MMS versione interazione guidata, con un filmato video 360x288x15 fps e traccia audio mono a 32 khz con campioni a 16 bit. Il parametro fps è poi stato modificato per ottenere filmati con diverse caratteristiche. Infine il file di storyboard utilizzato prevedeva l'applicazione di 3 tipologie di effetti che sono: PIP Statico (still) : Il flusso del filmato originale viene fermato, e si effettua lo streaming di una immagine statica composta dall'ultimo frame del filmato e da un lucido mixati insieme dalla funzione PIP. Questa condizione corrisponde in pratica alla potenza richiesta dal solo sistema Real Server/Real Producer. Filmato semplice: Streaming di audio e video: la funzione PIP non interviene. In questo caso si ottiene la potenza necessaria per la lettura e la decodifica del flusso video, del flusso audio e del sistema Real Server/Real Producer. PIP dinamico: Tutte le parti del programma MMS sono in funzione: la lettura audio, la lettura video, la lettura dei lucidi, la funzione PIP e lo Streaming RealServer/Real Producer.. I risultati ottenuti sono riportati in Tabella 3 e Tabella 4 (rispettivamente per la configurazione con AMD K6II 500 MHz e AMD Athlon XP 1800+). Nella prima colonna è riportato il frame rate (fps) richiesto al sistema di 54