Only one way of Streaming

This video cannot be played in your current browser.
View the download version at
root. -->

cisco openh264 homepage
To embedInitially found a way of generating the stream and after toa streaming 'm a fan of videoone way Really - as it often happens - you can stream but you cannot so the only way to embed video

Un solo modo di streammare

questo testo in italiano

From this website I stream in http many video (see the list) through Videolan VLC proxed by Apache.

hls streaming and playing using VLC
hls is not a real streaming but the local copy of chops of video within a playlist
vlc 2 can be used to generate and stream these chops.

The unicast I'm using take advantage from web http caches scattered worldwide and for this has many point in contact with multicast but requires only the port 80 to be open. The server is loaded for a single output stream, and -- as far as I know -- it seems do not exist any network flood.
The standard user interface of VLC http player do not allow any control of the stream: it cannot be stopped or restarted, simply can be accessed from the instant in which the connection is established. As already written, due the implicit usage of web http cache, I do not notice any network or computational load proportional to the number of connected clients.
Exactly what happens in ordinary radio broadcasting, where the repeater network is replaced by the web routers and -- in this case -- there is no initial massive power wasting.

What is required to view these streams

The stream can be seen on any device able to reproduce a video transport stream received in http.
On android devices I'm using the Videolan VLC app (beta 0.1.3) that must recall the single stream (see here.
The other two streams (as widely explained here) are reflected in http on high ports by VLC that receives two RTP audio/video streams on two known RTP ports. One of these two (http://www.iginomanfre.it/rtp_int) is generated internally to the server itself by a further instance of VLC that reflects what received by the server: it is always available, and is what you see running below these lines.
The other one (http://www.iginomanfre.it/rtp_ext ) is always on and "ready to forward" what addressed in RTP audio/video to the server on another known port by any external source placed wherever in the world.

.
Above, if you're on whatever PC (windows, mac or linux) where is installed VLC is embedded the http://www.iginomanfre.it/rtp_int stream.
Please read the disclaimer about this video (related to the dyson air multiplier)


Above the page rtp_test while streaming from my desktop from Rover's waiting room in Sirmione.
As explained in that page, the top video (the same embedded few lines above) is internally stream in RTP toward the server itself and from this forwarded in http to the world after being reverse proxed by apache. The lower video is generated from my laptop, trasmitted in RTP to the server in cloud and from that received by the laptop itself. The latence is about 24 seconds. (that's not a videocall!)

Browser compatibility of this page

This page (as generally speaking all the pages in this web site) are written in plain html. The next images show the same page opened by five well diffused web browsers:

apple safari (5.1.7 for windows), microsoft internet explorer 10

opera 12 and firefox 22. Opera 34 do not support any more the NPAPI plug.ins

Google Chrome when Chrome used to accept VLC plug-ins (on this page was not on the same of the former figures)

Chrome non accetta piu' i plug-in NPAPI (quindi neppure quelli di VLC) dal primo settembre 2015

Chrome does not accept any more the NPAPI plug-ins (thus including VLC one) since september 1st, 2015

network load

VLC standard user interface play controls of of http stream player really do not implement any VoD control.
It simply plays best effort what is on the wire. Dealing with a continous http stream you can only stop the video, but when you'll restart it, it will restart the reproduction until the depletion of saved cache.
At its end -- depending on the preferences set -- it will generally skip to the live video.

As streamer VLC generates one only stream for all the players. The cascaded Apache streaming server simply "boost" the stream decoupling it from the source, but being no possible relationship (i.e. control) with the generator (VLC, because VLC do not allow them), the overall transmission sound very similar to a best effort multicast, because the only unicast informations could be the corrupted packets repetitions requests issued by the players and (maybe) served by the http server (but again, depending on the preferences set, the repeated frames are usually skept). All (seems) to rely on the http caches scattered everywhere on the web.

Known drain of PAL_1500, about 1.5 Mbps. Really this PAL Transport Stream was playing since many hours through Telecom Italia's ADSL (I really forgive it was running)

Drain after adding another PAL_1500, reached by my smartphone through h3g mobile network. Can http caches justify why after few seconds this drain of two streams returns (about) to one only?
The clip is five minute long so the clip is not fall in a loop (The time division is about 8 sec/div, so the entire plot is about 320 seconds, less than 4 minutes).
If a streaming server streams a number of unicast streams equal to the number of clients, 1.5+1.5 used to give 3: with that scale 3 Mbps should be 0.30% of 1 Gbps. Why this drain fall down to 0.12% (equal to 1.2 Mbps) after few seconds? Shouldn't this drain around 0.3% constant ?


To know who is writing, click over the language you like

other streaming experiments

back

esperimenti di Streaming e Webcasting

Da questo server erogo in http streaming diversi video (vedi l'elenco) erogati da Videolan VLC e mediati da Apache.

generazione, erogazione e riproduzione di flussi hlsutilizzando VLC
hls non e' un vero streaming ma una copia in locale di piccoli segmenti di video nell'ambito di una playlist (in italiano scaletta)
vlc 2 puo' essere usato per geneare e erogare questi segmenti.

L'unicast che sto usando si avvantaggia delle cache http distribuite dovunque nel mondo e per questo ha molti punti di contatto con il multicast ma richiede che sia aperta solo la porta 80. Il server eroga un solo stream, e -- da quanto ho visto -- sembra che non esista alcun network flood.
L'interfaccia standard del player http di VLC non permette alcun controllo dello stream: non puo' essere fermato o ripreso, semplicemente puo' essere acceduto dall'istante in cui e' stabilita la connessione. Come scritto sopra, per la utilizzazione (implicita) delle cache http, Non ho notato alcun carico computazionale o di rete proporzionale al numero dei client connessi.
Esattamente come accade nelle ordinarie trasmissioni radio, dove la stazione trasmittente e' (logicamente) rimpiazzata dai router del web e -- in questo caso -- non il consumo di energia e' ridotto al minimo, senza alcuno spreco.

Cosa serve per vedere questi stream

Gli stream possono essere visti su qualsiasi dispositivo in grado di riprodurre un trasnsport stream video ricevuto in http.
Sui dispositivi android Uso l'applicazione Videolan VLC (beta 0.1.3) che deve richiamare il singolo stream (vedi qui.
Gli altri due stream (come ampiamente spiegato qui) sono ricevuti da VLC in RTP audio/video su due porte alte e determinate e riflessi in http su porte alte per essere poi mediati da Apache. Uno di questi due (http://www.iginomanfre.it/rtp_int) e' generato internamente al server stesso da una ulteriore istanza di VLC poi utilizzato per il resto del lavoro: e' sempre disponibile, ed e' cio' che (probabilmente) vedi qui sotto.
L'altro (http://www.iginomanfre.it/rtp_ext ) e' sempre pronto ad inoltrare cio' che gli e' inviato in RTP audio/video su un'altra porta alta e definita da una qualsiasi sorgente esterna posta dovunque nel mondo.

.
Sopra, se sei su un qualsiasi PC (windows, mac o linux) dove e' istallato VLC e' incluso lo stream http://www.iginomanfre.it/rtp_int.
Dai una occhiata al disclaimer di questo video (che mostra un uso singolare del dyson air multiplier)


L'immagine qui sopra mostra la consultazione della pagina rtp_test mentre trasmettevo dal mio desktop nella sala d'aspetto della Rover a Sirmione.
Come spiegato nella pagina linkata, il video di sopra (lo stesso incluso poche linee piu' in alto) e' quello generato internamente in RTP verso il server stesso e da questo inoltrato in http dopo essere mediato (reverse proxed) da apache. Il video piu' in basso e' generato dalla telecamera del mio laptop, trasmesso in RTP al server collocato in cloud e da questo ricevuto dal laptop stesso. La latenza e' circa 24 secondi. (non e' una videotelefonata!)

Compatibilita' di questa pagina

Questa pagina (e in genere tutte le pagine di questo sito web) sono scritte in html elementare. Le prossime immagini mostrano la stessa pagina aperta da cinque browser ben diffusi:

apple safari (5.1.7 for windows), microsoft internet explorer 10

opera 12 e firefox 22.

Google Chrome (ho aggiunto questa immagine successivamente e non mostra lo stesso contenuto delle altre)

carico di rete

L'interfaccia utente standard del VLC http player non possiede alcun controllo VoD.
Semplicemente riproduce al meglio delle sue possibilita' cio' che riceve. Poiche' il video e'un flusso in loop, tu puoi solo fermarlo, ma quando lo farai ripartire, ricomincera' la riproduzione dove era arrivato fino allo svuotamento della cache.
Alla fine -- in base alle preferenze impostate -- in genere saltera' al video diffuso dal vivo in quell'istante.

Poiche' VLC come streamer genera un solo stream per tutti i players il seguente Apache streaming server semplicemente disaccoppia lo stream dalla sorgente, ma poiche' non e' possibile alcun controllo del generatore (perche' VLC non lo consente), l'erogazione nel suo complesso si comporta in modo molto simile al multicast, perche' l'unica informazione unicast specifica per ogni player e' quella relativa alla richiesta di ripetizione dei pacchetti corrotti generata dal player e che potrebbero essere serviti dallo streaming server (ma ancora, in base alle preferenze impostate, VLC semplicemente ignora questo tipo di richieste). Tutto (sembra) basarsi sulle cache http distribuite dovunque sul web.

Consumo di banda di PAL_1500, circa 1.5 Mbps. In realta' questo Transport Stream DVB era in esecuzione da diverse ore sulla rete ADSL di Telecom Italia (avevo dimenticato che stesse girando sotto)

Carico di rete dopo aver aggiunto un secondo player dello stess flusso, sul mio smartphone attraverso la rete dell'operatore mobile h3g. E' merito delle cache http se dopo pochi secondi il carico di rete per due stream ritorna (circa) a quello di uno solo?
La clip e' lunga cinque minuti, non e' possibile si sia caduti in un loop (La scala orizzontale e' circa 8 sec/div, cosi' l'intero grafico e' circa 320 secondi, meno di 4 minuti).
Se in uno streaming server il numero di flussi unicast equivale al numero dei client, 1.5+1.5 di solito fa 3: con la scala della rappresentazione 3 Mbps sono circa lo 0.30% di 1 Gbps. Perche' questo impegno cade sotto allo 0.12% (pari a 1.2 Mbps) dopo pochi secondi? Questo carico dovrebbe essere costante e pari allo 0.3%.


To know who is writing, click over the language you like

altri esperimenti in streaming

indietro