Diego Fantoma
Università degli Studi di Trieste Dimostrazione
Presso l'Università di Trieste è sempre più frequente la richiesta di poter videoregistrare le lezioni per poi metterle a disposizione agli studenti attraverso la piattaforma Moodle.
È assodato che la qualità ottenibile dall'uso di componenti domestiche quali webcan e microfoni di un portatile è del tutto insufficiente e per di più stiamo vivendo in un momento in cui youtube spopola offrendo video ad alta risoluzione cui gli studenti (ma in realtà tutti) ormai si stanno assuefacendo. È palese inoltre che l'integrazione audiovisiva fornisce una migliore resa per l'apprendimento in particolar modo per quanto riguarda gli aspetti del lipsync, quindi un'ottima visibilità dei movimenti della bocca ma anche delle espressioni facciali per dedurre il tono del discorso ed enfatizzare, evidentemente non solo con il volume della voce, i passaggi più rilevanti di una spiegazione.
A ciò si aggiunge la necessità di affiancare al video del docente l'esposizione dei contenuti, siano essi slide, filmati o scritte sulla lavagna.
Dare l'impressione che sia tecnicamente possibile realizzare un contenuto accettabile con strumenti personali è quindi deprecabile; tuttavia è anche impensabile che vi siano operatori costantemente a disposizione che provvedano alla registrazione delle lezioni ed è necessaria quindi una soluzione che permetta la realizzazione dei contenuti in modo estremamente semplice e automatizzato ma completo.
Tempo addietro l'Università di Trieste ha ricevuto dei finanziamenti con cui ha potuto realizzare un'infrastruttura di videoconferenza Polycom consistente in una quindicina di codec hardware (macchine stand-alone), un provisioning server (CMA4000) che consente anche l'utilizzo di un client software (Deprecato. come visto prima) e di un H323 recorder (RSS4000) che diverrà il fulcro del sistema di integrazione.
Ancora, l'ateneo giuliano disponeva già di uno streaming server Wowza per il quale le versioni più recenti del software Polycom offrivano una connessione diretta per lo streaming e la produzione di video on demand.
Si trattava quindi di comprendere bene il meccanismo dell'RSS e realizzare quanto necessario affinché recorder, streaming server e Moodle potessero dialogare, tenuto conto della necessità di consentire ai docenti delle registrazioni personalizzate.
Il primo step è stato quello di predisporre Wowza in modo da consentire lo streaming multiformato attraverso il push da parte dell'RSS, secondo i parametri previsti da Polycom.
Se i flussi erogati tramite Flash/RTMP/RTSP consentono l'utilizzo di sottodirectory nel nome, ciò non è vero per i formati HLS e SmoothStreaming e quindi si è dovuto provvedere alla creazione di due nuove configurazioni che puntassero correttamente ai video gestiti dall'RSS.
Per il trasferimento dei file sullo streaming server è stato creato un utente particolare dedicato all'RSS, con home all'interno della directory prevista dalle suddette configurazioni.
Così facendo sia in caso di live streaming che di VoD da parte dell'RSS Wowza risulta predisposto in modo generalizzato.
Quindi si è provveduto a creare un template apposito per la codifica all'interno dell'RSS, che sia compatibile con i formati accettabili da Wowza e che sarà da utilizzare nelle configurazioni dei singoli canali per ciascun docente.
Purtroppo l'RSS non consente una configurazione automatica per cui è necessario creare diverse istanze di media server, una per ciascun docente, e altrettanti VRR (canale docente) che rispondano alla numerazione GDS assegnata: queste operazioni che richiedono circa 5 minuti, devono essere fatte a mano per cui si è scelto di configurare il sistema su richiesta da parte del docente.
Sebbene l'RSS consenta la creazione di media server e VRR tramite API SOAP, probabilmente il lavoro richiesto non bilancia i 5 minuti distribuiti in un tempo piuttosto lungo. È tuttavia una possibile idea per attivazioni massive che potrebbe essere sfruttata nel futuro.
A questo punto il workflow è riassumibile nei seguenti punti:
- il docente chiama da un'aula attrezzata con macchina polycom il registratore H323, configurato con una extension personalizzata (che in genere corrisponde al numero di matricola)
- il registratore invia una mail a un indirizzo indicato nella configurazione del VRR per indicare che è partito il live streaming
- il registratore, al termine della chiamata, provvede a effettuare la conversione dei file nel formato previsto dal template e a copiare i file sullo streaming server via FTP (unico modo possibile)
- terminata la copia l'RSS invia una nuova mail a indicare l'avvenuta conclusione del processo e il file è disponibile per la visione tramite streaming server
Per completare il processo è stato deciso di imporre un indirizzo email unico cui inviare le informazioni da parte dell'RSS: questo account è interrogato da Fetchmail sullo streaming server che, tramite uno script in PERL analizza i messaggi ricevuti e, sulla base di una hash table, si preoccupa di comunicare al docente le informazioni personalizzate per la pubblicazione dei video.
© 2012 Media Touch 2000 srl, Università degli Studi di Padova - ISBN 9788890749322
Lato Moodle è stato sviluppato un semplicissimo filtro che sostituisce una stringa del tipo: RSSPLAY:ID_del_file_da_visualizzare
con un link al player. L'ID del file è generato dallo script e inviato al docente via email che non dovrà far altro che copincollarlo in un qualunque testo sulla piattaforma.
Poiché la configurazione prevede l'uso di un ampio volume iSCSI montato sia dal server Moodle che dallo streaming server, utilizzando OCFS2 come file system concorrente, il filtro è in grado di effettuare un check della sussistenza del file del video prima di esporre il link al player.
Non è altrettanto facile verificare la sussistenza di un flusso live ma la cosa può venir risolta in altro modo, ad esempio richiamando ffmpeg dallo script PHP. Questa possibilità ha come contraltare che se lo streaming server dovesse risultare irraggiungibile la pagina non verrebbe visualizzata se non dopo parecchi secondi producendo un fastidioso side effect per l'utente.
Una nota negativa relativa all'RSS è che a volte (ma con frequenza non banale) la conversione dei file non va a buon fine ma l'intera procedura si conclude come se fosse tutto a posto. È necessario quindi effettuare un check con ffmpeg prima di inviare la mail al docente che segnali ai gestori del sistema il problema. Pro futuro si potrebbe pensare di effettuare una chiamata tramite API SOAP per riavviare la conversione.
Al momento attuale non sono implementate le playlist per l'auto select del formato video in base alla banda di rete ma potrebbe essere una feature da implementare in futuro.
Infine, poiché i log dello streaming server vengono analizzati e caricati in un database, si potrà pensare a sviluppare un plugin per il docente per vedere le statistiche d'uso dei video.