Il 21 dicembre si e’ svolto a Urbino un incontro di aggiornamento sulla gestione avanzata di flussi multimediali organizzato dal Corso di Laurea in Informatica Applicata e da NeuNet. Anche questa volta si è trattato di un esperimento condotto in pubblico dagli sviluppatori di openBOXware, la piattaforma open source per la gestione di flussi multimediali.
In poco più di un’ora Lorenz e Saverio sono riusciti a programmare e ad illustrare ai partecipanti tutti i plugin per openBOXware necessari a dimostrare la fattibilità di innovative modalità di distribuzione di contenuti multimediali.
Per capire il senso del’incontro potete dare un’occhiata alle slides proiettate nel corso della presentazione. La prima parte illustra sinteticamente l’architettura di openBOXware, la seconda parte discute i problemi di banda che affliggono le reti di accesso e le conseguenti esigenze di gestione dei flussi multimediali, la terza parte mostra la struttura della demo ed enumera i plugin di cui è stata data dimostrazione pratica.
Chi avesse già assistito a precedenti incontri su openBOXware o a presentazioni sul multicast wireless e sulle reti di accesso neutrali può risparmiarsi le prime due parti e passare direttamente alla terza, a cui è dedicato il resto di questo post.
L’esperimento
Lo schema dell’esperimento è illustrato di seguito. I blocchi azzurri rappresentano 5 computer sui quali è installato openBOXware. Tutti i computer appartengono alla stessa rete locale. I riquadri gialli rappresentano i plugin per openBOXware che consentono alle 5 istanze di scambiarsi flussi multimediali di diversa natura, rappresentanti dalle frecce. Le frecce nere rappresentano collegamenti unicast, mentre quelli rossi collegamenti multicast. Le frecce più spesse rappresentano flussi a banda larga (superiore a 1Mbps).
Hop 1:
Sulla macchina A gira un’istanza di openBOXware che implementa un server HTTP [1] che rende disponibile un filmato in un container Mp4 (video H.264 e audio AAC). Sulla macchina B openBOXware riceve il filmato attraverso un media source HTTP [2] che si comporta da client.
Hop 2:
Sulla macchina B il flusso ricevuto dal media source HTTP è ridiretto da openBOXware senza transcodifica su un media target TCP [3] che si comporta da client mandando lo stream alla macchina C in modalità push. La macchina C riceve lo stream attraverso un media source TCP [4] configurato come server.
Hop 3:
L’istanzie di openBOXware che gira sulla macchina C rilancia il video H.264 in un container RTP in modalità multicast su UDP attraverso l’apposito plugin RTP media target [5]. Il descrittore SDP è reso disponibile dal server HTTP [1] che gira sulla macchina A. Sulla macchina E gira un media source SDP [6] che recupera il descrittore dal server HTTP e si collega al gruppo multicast a cui invia il flusso il media target RTP.
La macchina E emula il comportamento di un utente non autorizzato a ricevere il video. Per questo il flusso generato dalla macchina C è corrotto in modo da non poter essere fruito senza ulteriori informazioni trasmesse in unicast direttamente dalla macchina A ai soli utenti registrati. Nel nostro esempio il flusso multicast non contiene la traccia audio.
La macchina D rappresenta un utente registrato presso il server [1] e autorizzato a ricevere il video. Il plugin per openBOXware che gira sulla macchina D non è un semplice media source, ma un’applicazione [7] che include un media source SDP per la ricezione di video in multicast, una custom pipeline UDP per la ricezione in unicast del flusso audio generato dal server [1] in modalità push a seguito della prima richiesta del video, e un widget srt per la riproduzione dei sottotitoli scaricati in unicast http dallo stesso server [1].
Scenari
L’esperimento condotto in laboratorio è esemplificativo della possibilità di implementare meccanismi evoluti per la distribuzione di flussi multimediali lavorando ad un livello di astrazione che massimizza la produttività e la portabilità del codice, e utilizzando la stessa piattaforma software in tutti gli elementi della catena. Nel caso specifico, la macchina A rappresenta un generico server disponibile in rete, la macchina B rappresenta un proxy, la macchina C rappresenta un gateway unicast-multicast, la macchina D rappresenta un client autorizzato alla fruizione di un contenuto on demand, la macchina E rappresenta un client non autorizzato. L’esempio mostra come sia possibile:
- sfruttare il multicast per ottimizzare l’occupazione di banda sul penultimo miglio consentendo a più utenti (autorizzati) di ricevere lo stesso flusso,
- implementare tecniche di protezione che consentano di limitare la fruizione dei contenuti ai soli utenti registrati,
- personalizzare/localizzare l’audio e/o i sottotitoli attraverso flussi unicast sincronizzati al flusso video multicast,
- rendere trasparente all’utente il rilancio locale in multicast attraverso descrittori SDP.
