(puoi trovare questo testo in italiano al termine della sezione in inglese)
From this website I stream in http many video (see the list) through Videolan VLC proxed by Apache.
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.
|
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. |
Above, The same content stream as hls obtained by the stream http://www.iginomanfre.it/rtp_ext reproduced left after being segmented again by VLC. Even this embedded video is required VLC plug-in. Please note the delay between the two streams |
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?
|
|
To know who is writing, click over the language you like |
|
|
|
|
Da questo server erogo in http streaming diversi video (vedi l'elenco) erogati da Videolan VLC e mediati da Apache.
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.
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?
|
|
To know who is writing, click over the language you like |
|
|
|
|
