Ci sono molti modi di trasmettere Video on Demand attraverso il web; tralasciando i metodi obsoleti (come quello di scaricare il video come download sul proprio computer) e quelli in cui bisogna scaricarsi un player 'propietario' (un software da usare solo per vedere i video in un formato non standard), attualmente sono in uso tre metodi:
1) uno che costringe ad attendere che tutto il video sia trasferito dal player (il componente che permetta di visualizzare i video) sul proprio computer
2) un secondo che permette di ricevere i dati video un poco alla volta, con il video che parte dopo pochi (o diversi) secondi mentre il player 'anticipa' i dati video successivi, riempendo la famosa barra. Esempi noti a tutti sono i video di Youtube. Una volta che tutti i dati sono stati ricevuti, si può andare avanti o indietro (seek) nel video, ma questo SOLO dopo che tutti il video è stato trasferito sul PC dell'utente. Questo modo viene chiamato "PROGRESSIVE" ed è attualmente quello piu' usato. Ha degli svantaggi dovuti sopratutto al fatto che il video una volta visto, rimane 'scaricato' anche sul pc dell'utente che può farne quelle che vuole e riutilizzarlo a sua volta. Questo sistema può essere implementato con costi molto contenuti
3) il terzo ed ultimo modo di distribuire il video è detto 'STREAMING'. Il video viene distribuito da un server specializzato che trasferisce esattamente (e solo) la porzione di video che deve essere vista (piu' qualche secondo in piu' per evitare 'singhiozzi' dovuti al traffico di rete). Questo permette all'utente di andare avanti o indietro nel video SENZA aspettare che questo sia stato scaricato o 'bufferizzato' sul suo pc. Il vantaggio diventa evidentissimo per filmati video di lunghezza superiore ai pochi minuti, ed il video NON rimane mai sul pc del cliente ne può essere scaricato. Per implementare questo sistema si necessità di server dedicati e di una notevole larghezza di banda.
Il modo di 'fornire' questi video via web è dettato dai protocolli utilizzati: dal semplice HTTP che tutti conosciamo ai RTMP /RTSP/MMS specializzati per il video.
Questo che segue è un esempio di un video in formato Flash distribuito attraverso il protocollo RTMP in "Streaming" usando il famoso player "JW FLV Player" implementato nei Ns. pacchetti.
Provate ad andare 'avanti ed indietro' per vedere con quanta velocità potete saltare nella parte video che scegliete (n.b. la velocità dipende anche dalla Vs. connessione internet ma la qualità è sempre assicurata)
Il file è codificato in MP4 con una risoluzione video nativa di 640x380 con codec H.264 e bit rate di 750 Kbps (ospitato su un servizio CDN)
Si può ottenere un risultato simile, usando il protocollo HTTP ed una soluzione ibrida chiamata "PSEUDO STREAMING", che è basata su software in parte open source e quindi piu' economica (il file è da 640x400 ed è sempre un mp4 - ospitato da google video)
Avrete notato che nella soluzione di streaming pura i tempi di 'seek' sono piu' veloci e che la barra non indica che si sta facendo buffering (non si colora di grigio): questo significa che un utente generererà solo 'traffico' minimo relativo esattamente a quanto visto.
Nel secondo esempio i tempi sono leggermente maggiori e la barra si 'riempie' avantaggiandosi nel fare buffering di video, per cui l'utente consuma piu' traffico di quanto realmente usufruito.
Dal momento che la web tv è parametrizzata come costi non solo allo spazio usato dai video ma anche dal traffico generato dagli utenti, è evidente che sul piano economico la soluzione dello streaming è piu' conveniente anche se ha costi inziali piu' alti.
Ancora un esempio di un video con risoluzione minore (580x306 nativo) ma con codifica ottimizzata per 600 Kbits (sempre in streaming, sempre su una CDN)
Non tutte le CDN sono uguali; questo che segue è un contributo video di eguale "peso": provate a lanciare tutte e due le finestre in play e spostarvi per vedere i diversi tempi di risposta tra una CDN discreta (sotto) ed una di classe A+ (sopra)
