Non sono un programmatore, ma alla fine ho trovato un modo compatibile per realizzare una chiamata unica:


La prima parte (Object...) e' usata da Internet Explorer, la seconda (Embed...) dagli altri.

Il video e' erogato in http sulla porta 80 per renderla accessibile dovunque. E' generato da un cloud server che -- in base allo stato delle mie finanze -- potrebbe essere giu'.
Puo' essere utile provare ad aprire lo stream http://95.110.164.61/mpeg2 con un MPEG Transport Stream player (non con un browser) . Io uso Videolan VLC.
Se non lo conosci, posso solo dirti che e' un fantastico programma open source (sotto licenza GPL2) per riprodurre video, ma puoi farci molto di piu' come erogare stream, salvare e convertire media... Lo puoi scaricare liberamente dal sito di videolan. E' disponibile per diversi sistemi operativi, ultimamente per Android (per ora in beta, ma funziona molto bene).

Utilizzando Internet Explorer, a seconda delle impostazioni di sicurezza, ti potrebbe essere chiesta l'autorizzazione per installare un modulo active-x che ho indicato nella pagina web. Con gli altri browser devi aver installato il plug-in di VLC per Mozilla (dalla version 2 questo e' fatto per default durante il'installazione di VLC).

Il video e' doppiato in italiano, perche' penso che sia della massima importanza che il suo messaggio si diffonda anche nel nostro paese.
In ogni caso puoi trovare l'intera collezione in inglese sul sito del progetto "la storia delle cose" ("the story of stuff" project) oppure cercandoli in altre lingue.

Lo stream e' generato da VLC che gira su un virtual server in cloud, a partire da un file contentente un wrapper MPEG/DVB PAL 16:9 precompresso.
Con un doppio click sull'area del video (o cliccando sul bottone alla estrema destra), si espande a tutto schermo.

Lo stream e' un Mpeg Transport Stream a bitrate variabile (VBR), mediamente a 1,5 Mbps che trasporta un video PAL mpeg2 (720x404 pixel, 25 frames al second) e uno stream audio stereo a 128 Kbps in mpeg1 layer2 campionato a 44.1 Khz.
Il file e' precompresso nel formato di streaming perche' ho affittato un server virtuale con un solo core Xeon. QUello che e' importante qui e' la banda della connessione in rete di questo server virtuale: 1 Gigabit al secondo!
Qualora non riuscissi a vedere il video correttamente la causa e' probabilmente dovuto alla velocita' della tua connessione: essendo compresso in MPEG2, ogni /mac/smartphone e' in grado di decodificarlo, mentre le connessioni internet 3g (ed anche la wi-fi in aree congestionate) facilmente non forniscono piu' di 700 Kbps.

E' uno stream dal vivo: VLC eroga solo uno stream e ognuno accede allo stesso stream mediato in reverse-proxing da Apache.
Infatti non puoi controllarlo: la timeline che appare passando il puntatore del mouse sull'area video e' disabilitato.
Se lo fermi e lo fai ripartire diversi secondi dopo, una volta scaricata la cache, saltera' al punto dove il video e' arrivato nel frattempo (il video e' un loop di circa un'ora).
E' sicuramente piu' sostenibile dell'approccio unicast puro (usato nei servizi VoD come YouTube), perche' l'unica informazione unicast qui consiste nella ripetizione dei pacchetti richiesti dai player dopo averne ricevuta una copia corrotta.
Scherzando, dico che questa e' la Igino Manfre' International Broadcast, e veramete e' visibile in tutto il mondo perche' il suo TTL e' fissato a 100.

Ma e' uno stream http (quindi tcp/ip), che e' tutto fuorche' il metodo ideale per lo streaming.
A tempo infinito lo stream e' perfetto, erogato e distribuito come e'. Dei problemi possono nascere dal flusso irregolare della informazione, non consegnata al player in tempo per essere decodificata e presentata al tempo previsto.
Questo puo' essere misurato con il Media Delivery Index, introdotto nel 2006 con la RFC 4445 proposta da Welch (Ineoquest) e Clark (Cisco). E' spiegato nella voce di Wikipedia's lemma ma perfettamente mostrato da questo grafico tratto dal documento della Ineoquest Media Delivery Index Application Note

.
Mostra perche' un player puo' non essere in grado di mostrare correttamente un flusso a 3,75 Mbps malgrado abbia ricevuto tutti i bit necessari: tutti ma non in tempo utile
L'immagine fa riferimento ad una distribuzione video in UDP (dove non e' prevista alcuna ripetizione) mentre in questo caso puo' contare sulla affidabile garantita dal TCP.
Usando VLC puoi catturare lo stream creando un file con la seguente command line

"[vlc path]\vlc" http://95.110.164.61/mpeg2 :http-caching=1200 :demux=dump :demuxdump-file="c:\stream.ts"

Per default il path di installazione di VLC e' c:\program files\videolan\vlc. In ogni caso puoi conoscerlo dalle proprieta' del link
Attenzione: lo stream e' dal vivo, non inizia e finira' mai. Al ritmo di circa 1.5 Megabit al secondo, se te lo scordi , il file puo' diventare abbastanza grande: dopo circa un'ora circa 700 MB.


Questo e' uno stream dal vivo, originato a partire da un loop, ma potrebbe essere uno stream dal vivo trasmesso da un sistema remoto e rilanciato dal server in cloud.
Al contrario, nel caso di Adobe Streaming Server, Apple Http Live Streaming, Silverlight o il prossimo MPEG DASH (Digital Adaptive Streaming over HTTP) il video e' trasferito dal server al PC che lo riproduce in migliaia di fettine, ciascuna un file di pochi Kilobyte, riprodotto come una playlist.
Fortunatamente, essendo distribuiti in HTTP, utilizzano le cache http della rete. Ma questo lo sfrutta anche il mio stream come ogni distribuzione in http, anche se la mia audience e' sicuramente limitata.
E' importante comprendere che non c'e' alcuna stregoneria nella corretta distribuzione del video sul web.
L'approccio di VLC, simile al broadcast televisivo e' piu' sostenibile ed economico: non rack di server superdotati, perche' non ci sono milioni di file da copiare sui client.
Il sistema di base (come quello che uso io) puo' essere un server virtuale con un single core, affittabile a 40 euro al mese cosicche' ognuno puo' distribuire un contenuto dal vivo in tutto il mondo.