Questo capitolo è svolto in modo parziale, incompleto e
frammentario. Sperabilmente, i suoi contenuti saranno approfonditi ed
estesi. In tutti i modi, c'è già qualche incipit
interessante.
Trattiamo prima dello Streaming,
ovvero la trasmissione e la fruizione di contenuti multimediali
(audio e/o video) via Internet in modalità unidirezionale, ossia
da una unica sorgente verso uno o più destinatari, senza che questi
ultimi possano (debbano, vogliano) a loro volta inviare contenuti
multimediali indietro al mittente.
Passiamo poi alla comunicazione Web,
ovvero alle
soluzioni in via di definizione che mirano a rendere il browser web
l'unica interfaccia alla fruzione di applicazioni multimediali, sia di
streaming che di comunicazione interpersonale e di gruppo, senza
ricorrere a player esterni o plugin specifici.
Nella ricezione streaming
sono fatte salve
alcune funzionalità che potremmo definire tipiche di video-registratori
e riproduttori di CD, MP3 e DVD, come la messa in pausa, il
riavvolgimento e il fast forward, e l'accesso diretto ad un determinato
istante temporale. Ma anche se l'unidirezionalità di base rende quasi
ovvia una impostazione di tipo client-server della architettura,
vi sono molti altri aspetti, come
erogazione di contenuti Live o On-Demand
trasporto basato su UDP o TCP
instradamento unicast o multicast
eventuale coinvolgimento di una CDN o di una distribuzione Peer to
peer
compatibiità con altri sistemi di telecomunicazione, come TV analogica
o digitale, e telefonia cellulare
compatibilità con altri sistemi di immagazzinamento multimediale
digitale, come il CD, l'MP3 ed il DVD
scelta dei codec, della banda, della qualità di servizio
indicizzazione e catalogazione dei contenuti
presenza o meno di un sistema di gestione dei diritti (DRM)
che
determinano importanti alternative realizzative, così variegate,
da causare di fatto un rallentamento della affermazione della
tecnologia. Dal punto di vista delle applicazioni di erogazione e
fruizione dei contenuti, il principale spartiacque può identificarsi
nelle alternative tra soluzioni aderenti a standard pubblici e
soluzioni proprietarie.
Le soluzioni aderenti a standard pubblici
sono conformi alle indicazioni contenute in documenti normativi come
quelli emessi da IETF, ed hanno l'obbiettivo di favorire
l'interoperabilità di apparati ed applicazioni di fornitori diversi, ma
accomunati dal supporto a protocolli comuni come quello per il
controllo (l'RTSP) dell'interazione tra client e
server, quelli comuni al VoIP (l'SDP, l'RTP)
per la descrizione ed il trasporto dei contenuti, ed a formati di codifica
e pacchettizzazione descritti da standard pubblici.
Le soluzioni proprietarie
tendono invece ad offrire soluzioni integrate, fornendo ad esempio sia
i componenti server che i client, adottando protocolli e codec coperti
da brevetto, applicando sistemi di protezione che impediscono la
fruizione non autorizzata.
Infine, è da citare un
approccio che di fatto consente di realizzare le funzioni basilari dell
streaming (come ad esempio il posizionamento intermedio) anche con un
protocollo nato per tutt'altro, come per l'HTTP
streaming.
Il Real Time Streaming
Protocol è descritto nella RFC
2326, e da allora, soggetto a revisione.
E' un protocollo strettamente Client-Server, e si occupa solo del
controllo della riproduzione (inizio, pausa, posizionamento, arresto),
delegando rispettivamente a SDP ed RTP
i compiti di descrivere il contenuto, e di trasportare i dati
multimediali. Sotto molti aspetti l'RTSP somiglia all'HTTP, ma a
differenza di
questo è stateful, in quanto la possibilità
per il client di mettere in pausa la riproduzione, obbliga il server a
ricordare per la durata della sessione, le informazioni relative ai
suoi client. Svolgiamo un rapidissimo esempio del suo funzionamento,
discutendo il seguente capture, in cui i messaggi inviati dal client
sono indicati in rosso:
Il client inizia il dialogo interrogando il server a riguardo dei metodi
disponibili, mediante il metodo OPTIONS.
Come si vede, anche in questo caso i messaggi convogliano
informazioni semantiche mediante l'uso di intestazioni, come Cseq,
che si incrementa di uno ad ogni nuovo messaggio del client, ed è citato
uguale nella relativa risposta.
Alla riga 5 il sever risponde con una sintassi ormai nota, formata
da una prima linea contenente un codice numerico di successo, ed alla
riga 10 il client passa a chiedere la descrizione di una URI di cui si
desidera la riproduzione. Questa descrizione è fornita nella risposta
di riga 15, mediante un elemento SDP contenuto nel
body
della risposta stessa. Notiamo che negli header di questa risposta sono
presenti elementi indicanti la data del contenuto originario, la data
attuale, intestazioni dedicate ai proxy ed al controllo cache, ed
intestazioni più propriamente dedicare allo streaming. Per quanto
riguarda l'SDP, notiamo una serie di linee a=
(righe 36-38) mediante le quali si asserisce l'adesione alle specifiche ISMA, un Initial
Object Descriptor di mpeg4, e la durata in secondi dell'intero clip.
Quindi, alla linea 39 troviamo la linea a=
relativa all'audio, associato al payload
type dinamico
96, e per il quale non è ancora stata negoziata una porta. Le linee
40-43 indicano che l'audio è associato alla traccia 5 (il file da cui
si parte, contiene audio e video del clip multiplati assieme nello
stesso file, ma suddivisi in differenti tracce), e che il PT 96
corrisponde ad un audio mpeg4, campionato a 22050 Hz, stereo, più altre
indicazioni specifiche. Le righe 44-48 descrivono invece il media
video, associato al PT dinamico 97, corrispondente ad un MP4, presente
sulla traccia 8 del file originale.
Il server RTSP dovrà demultiplare i flussi audio e video presenti
nel file originale, e generare per ognuno di essi un diverso flusso
RTP, mantenendo per questi la possibilità di rimanere sincronizzati.
Alla riga 49 il client inizia a predisporre il server alla
trasmissione, comunicando (riga 51) le porte su cui intende ricevere
RTP ed RTCP per quanto rigurda l'audio, che sono riscontrate dal server
alla riga 62; inoltre alla riga 59 il server assegna alla richiesta un
identificativo di sessione. Questo identificativo è citato alla riga
67, assieme alla richiesta di SETUP pe il media video (riga 64), che
viene a sua volta riscontrato dal server con la risposta che inizia
alla riga 70.
Finalmente, alla riga 80 il client richiede il PLAY dei media
associati alla sessione appena definita, riscontrato dal sever alla
riga 86. Infine, la riga 93 rappresenta la richiesta del client di
arrestare la riproduzione.
Real Networks è
il fornitore di una architettura
di streaming composta da server (Helix,
versione di
valutazione), client (RealPlayer),
encoder (RealProducer),
e codec (RealAudio, RealVideo). Può essere
ritenuta la prima soluzione commerciale per la distribuzione multimediale
su Internet. Mentre la componente di controllo
è attuata in accordo all'RTSP, il trasporto usa (preferenzialmente) un
protocollo proprietario (RDT),
così come anche il codec non segue gli standard pubblici. Viene inoltre
definito un formato di descrizione indicato come Real
Audio Metadata (.ram),
ed un linguaggio di sincronizzazione tra contenuti multimediali e
presentazioni testuali, il Synchronized
Multimedia Integration Language (.smil).
Infine, il player è in grado di riprodurre anche altri
formati e contenitori, e gran parte del codice sorgente alla base
della soluzione di Real, è stato rilasciato con licenza OpenSource.
Il plugin Flash
di Adobe risulta installato nel 99% dei browser web, ed anche se
la riproduzione video risulta penalizzata rispetto ad applicazioni
player dedicate, la sua estrema diffusione ed integrazione nelle pagine
web è la ragione della sua adozione quasi universale. Per diverso tempo
questo plugin si è limitato a riprodurre files ShockWaveFlash
(con estensione .swf),
un formato proprietario di grafica vettoriale, che si è poi evoluto a
formato contenitore di codifiche multimediali. Successivamente, si è
definito un ulteriore formato detto Flash
Video (con estensione .flv), che può
essere riprodotto anche da un
player esterno al browser. Un file flv
può essere ricevuto come singolo oggetto per una successiva riproduzione,
oppure visionato durante la ricezione in forma di download
progressivo HTTP, o in streaming RTMP.
Quest'ultimo è il protocollo con cui il Flash Player si collega in TCP
presso il server, e su questa unica connessione realizza diversi canali
virtuali su cui multiplare i dati audio, video, i messaggi RPC di Actionscript,
ed i messaggi
di controllo come per la negoziazione dei parametri (es. di banda) e di
riproduzione (es. play/stop).
Nonostante la licenza proprietaria neghi il diritto di sviluppare un
Player diverso, ne esistono diverse realizzazioni
indipendenti come ad esempio JW
FLV Player. Sebbene nel 2009 Adobe abbia annunciato di aver reso
pubbliche le specifiche di RTMP, queste mancano di importanti
dettagli. Allo stesso tempo, Adobe ha lanciato lo Open
Screen Project con il quale integra il proprio Flah Player in un runtime detto AIR
(Adobe Integrated Runtime)
eseguito al di fuori del Browser, ed esteso ai dispositivi
mobili.
Questo avanzamento
di HTML nasce ad opera di un gruppo
di lavoro che ne cura la versione
di sviluppo, e la sua prima versione ha visto la luce da parte del W3C nell'ottobre
2014.
Le nuove caratteristiche spaziano dalla grafica vettoriale alla
memorizzazione locale di dati, al drag-and-drop, alle applicazioni
off-line, al supporto della indicizzazione da parte di motori di
ricerca ed a quello delle formule matematiche, oltre che per i sensori
per la geolocalizzazione, il movimento e l'orientamento. Ma il motivo
per cui questo argomento si trova qui, è che anche il linguaggio di
markup si arricchisce di nuovi elementi, come <video> e <audio>
esplicitamente orientati alla multimedialità, rendendo possibile lo
streaming direttamente all'interno del browser, senza bisogno di plugin
aggiuntivi come il Flash Player.
E' una
iniziativa
(sito ufficiale)
tesa ad estendere le funzionalità di un browser web al fine di
permettere la Comunicazione Real-Time
di contenuti multimediali e
multiparte in modo nativo, senza quindi ricorrere a plugin od
applicazioni esterne. La normativa a riguardo viene sviluppata da W3C
per quanto riguarda la
definizione di tre nuove API Javascript, e da IETF
per
quanto riguarda i procolli coinvolti.
Lo
stack relativo è rappresentato nella figura a lato,
in cui viene evidenziato come il codice Javascript provveda a scambiare
segnalazione con il sito web che l'utente sta visitando, o con un
server di segnalazione terzo, anche ricorrendo ai WebSocket,
che permettono
una comunicazione pienamente bidirezionale, consentendo al browser
di ricevere anche eventi asincroni (RFC
6455). Sempre il codice Javascript accede
poi alle funzioni offerte da WebRTC mediante le tre nuove API
Consente l’interscambio di flussi di dati
arbitrari tra due device in connessione peer-to-peer
mentre invece i dati multimediali e/o di altra natura viaggiano
direttamente tra i due browser: per questo motivo, anche se mediata da
web, la comunicazione è da ritenersi di tipo peer
to peer, ed i server
web non sono per nulla coinvolti nell'uso di banda dei flussi
multimediali.
Lo schema
di comunicazione può
avvalersi della semplice architettura a
triangolo mostrata a sinistra,
in cui entrambi i browser stanno visitando il medesimo sito web, oppure
quella a trapezio
mostrata sotto, in cui i diversi siti web si scambiano la
segnalazione necessaria a mettere i due utenti in comunicazione,
avvalendosi di un protocollo esistente come SIP o Jingle.
Essendo
ora il web server in grado di esprimere i messaggi di segnalazione via
SIP, è relativamente immediato estendere le capacità di comunicazione a
partire dal browser a tutta la comunità SIP, o Jabber, o perché no,
raggiunere anche utenti di rete telefonica, disponendo dell'opportuno
gateway. Le compatibilità ora illustrate sono rese possibili dalla
scelta di IETF di riutilizzare i protocolli già adottati nel caso del
VoIP, come l'RTC
per il trasporto dei dati tra i browser, l'SDP per la descrizione dei
codec disponibili, ed ICE per la gestione di firewall e NAT.
Ma torniamo alle API Javascript. Dato che il codice in esecuzione nel browser che ne
esegue le chiamate ha origine dal server web che si sta visitando (e che viene visitato
dagli altri partecipanti alla sessione), esso può
realizzare il processo di controllo sessione in modo del tutto
autonomo, avvalendosi appunto di queste chiamate, e dialogare con il
server web mediante protocolli di segnalazione preesistenti o sviluppati
ex novo. Il WebRTC non si occupa di questi aspetti, quanto invece di
definire le API suddette, ed i protocolli di comunicazione tra
pari. L'attivazione di questi ultimi passa dall'invocazione di RTCPeerConnection, mediante la quale
l'applicazione Javascript esegue i passi descritti come Javascript
Session Establishment Protocol (JSEP),
ossia
attiva
il componente di attraversamento
NAT e Firewall ICE che inizia a
generare eventi con i quali notifica di possibili indirizzi (IP, porta)
su cui il browser può essere raggiunto; ogni volta che si presenta un
nuovo candidato, viene aggiornata la descrizione
di sessione locale;
crea un SDP
che descrive le proprie disponibilità in termini di indirizzi, dei media
presenti e dei rispettivi codec, invocando createOffer(),
quindi memorizza l'SDP con setLocalDescription(),
e lo invia tramite canale di segnalazione web all'altra parte. Chi
riceve l'offerta invoca dunque setRemoteDescription()
per memorizzarla, e quindi invoca createAnswer()
per generare un SDP di risposta, inviato anch'esso via segnalazione web;
quando
il processo di segnalazione è completato con successo, i media
possono essere scambiati direttamente tra pari, o tramite un server
TURN intermedio.
Sono quei siti che funzionano come vetrina per i contenuti a
disposizione presso una medesima infrastruttura di aggregazione per i
contributi offerti da una singola entità (come nel caso di un
broadcaster che replica le proprie trasmissioni via etere anche via
Internet) o di singoli individui. Alcune di queste piattaforme
consentono anche l'attivazione di canali live, e molto probabilmente
fanno uso di CDN.
YouTube ...non c'è davvero
bisogno di presentazioni!
Vimeo ospita contenuti di qualità,
cortometraggi, film e opere di animazione
Ustream con
uffici a Los Angeles, Tokyo, e Budapest, trae la sua origine da
esperimenti per permettere ai militari americani in Iraq di parlare con
casa
Justin.tvcon base a S.
Francisco, il suo ideatore iniziò trasmettendo la propria
vita per tre mesi ininterrotti; oggi ospita svariati argomenti
nel cui ambito trasmettono innumerevoli soggetti; vanta inoltre delle
condizioni di servizio volte ad impedire l’immissione di contenuti
ritenuti non graditi
Livestreamcon sede a
New York, per poter trasmettere occorre pagare una tariffa;
il proprio canale può quindi essere condiviso facilmente attraverso
social networks e/o incorporato in altri siti. Propone (a pagamento)
suoi strumenti di codifica e produzione
Bambusercon sede in
Svezia, è da citare il fatto che sia stata censurata
durante le rivolte egiziane e siriane dai rispettivi governi
YouNow
sembra più orientata ai singoli individui; la
versione a pagamento permette di selezionare l’insieme dei possibili
spettatori
DaCastcon sedi a S.
Francisco e Parigi, offre un servizio a pagamento con un free
trial, e permette di monetizzare i propri ascolti,
potendo
chiedere tariffe pay per view il cui metodo di pagamento è
incorporato nel player stesso
Voklecon base in
California, aggiunge allo schema classico la possibilità
per gli spettatori di inviare commenti e domande in formato testo, che
costituiscono successivamente dei punti di ingresso temporali
alla versione registrata della trasmissione
Chatroulette un luogo di
incontro virtuale in cui si viene collegati con persone a caso
Stickcambasata a Los
Angeles e lanciata nel 2005, attualmente ha sospeso le attività.
Offriva un servizio gratuito
usato prevalentemente da singoli individui, permettendo agli
spettatori
di inviare a loro volta la propria immagine.
CurrentTV era un
network televisivo internazionale di informazione indipendente, fondato
nel 2005 da Al Gore e da Joel Hyatt; si fondava sul concetto di contenuto
generato dagli utenti.
Sicuramente
la banda necessaria a trasmettere un segnale audio è sensibilmente
inferiore a quella per audio + video, e dunque il principio delle
streaming Internet è a maggior ragione applicabile al caso delle radio.
Dal TCP al VoIP, dal DNS all'Email alla crittografia, tutto ciò che accade
dietro le quinte di Internet, completo di cattura del traffico.
Scopri
come effettuare il download,
ricevere gli aggiornamenti,
e contribuire!
Lo
stack relativo è rappresentato nella figura a lato,
in cui viene evidenziato come il codice Javascript provveda a scambiare
segnalazione con il sito web che l'utente sta visitando, o con un
server di segnalazione terzo, anche ricorrendo ai WebSocket,
che permettono
una comunicazione pienamente bidirezionale, consentendo al browser
di ricevere anche eventi asincroni (RFC
6455). Sempre il codice Javascript accede
poi alle funzioni offerte da WebRTC mediante le tre nuove API
Lo 
esistente come SIP o 
Essendo
ora il web server in grado di esprimere i messaggi di segnalazione via
SIP, è relativamente immediato estendere le capacità di comunicazione a
partire dal browser a tutta la comunità SIP, o Jabber, o perché no,
raggiunere anche utenti di rete telefonica, disponendo dell'opportuno
gateway. Le compatibilità ora illustrate sono rese possibili dalla
scelta di IETF di riutilizzare i protocolli già adottati nel caso del
VoIP, come l'
