I use multicast.
This sends one stream to all receivers simultaneously.
The network has wired and wifi segments.
With multicast, the stream uses only one time its bandwidth on each segment
That means also that all computers receive the same packet at about the same time, less propagation delays through my switches.
The propagation delays are negligible for sound and human visible video (30fps).
The only thing that can happen is that different computers work at different places in their network cache.
To keep them as near as possible I turned down the caching until the slowest system (a 32bit laptop on wifi) starts to cut out sometimes, then give it a little more.
Reason: once vlc starts to eat buffer it takes a long time to come back to the beginning of the buffer, it seems that the coding does not prioritize to get back to 'zero buffer' but is comfortable to stay up there.
I do also use on the 'server' two vlc clients:
one generates the stream and does not locally display.
The other is the displaying client that listens to the stream like all other systems, with the same network cache setting.
In command line:
stream generating client that connects to the Internet stream (this one has a big cache so it does not cut out and delivers a constant stream into my multicast network):
vlc -vvv http://yp.shoutcast.com/sbin/tunein-station.pls?id=154 --sout udp:239.0.0.1 --no-sout-display --sout-keep --ttl 4
(that is supposed to be on one line)
As you see, --no-sout-display is given: the stream output is generated, but no local output. I do the same, no matter if I play local files/DVDs or network content.
And make sure you have that --ttl set to >1 if you have a wireless router somewhere. I always set it to 4 as not to get 'surprises'.
However, if you have a multi-router network and hosts on one network cannot see the multicast then you might need to turn up that ttl a notch or two (or check if your router does let multicast through at all, not all wireless routers are set to that by default).
On every system, including the one that generates the stream and has the non-outputting vlc running, I have the following vlc:
vlc udp://@239.0.0.1 --network-caching 60 --sout-keep
This sets the network caching in my network and with the performance of the slowest system to max. .06 seconds worth of cache.
For sound, this corresponds to a propagation distance to about 100 feet, which means if the cache is eaten to the max then the slow system sounds as if it would be 100ft away.
My network delay is .5ms or better (not ping, that's a low priority stack round trip and several ms).
In my place, where I never see or hear simultaneously two systems that are >100ft apart (I don't blast upstairs and basement, the advantage of doing it this way is to have the same everywhere without blasting the living room amp).
The laptop in the bedroom: if it cuts out too often I just turn its cache up locally, I don't hear it in the basement or upstairs, and when I am there I have probably shut off the others :-) .
Very important: whenever I need transcoding I have all receivers on the same protocol and encoding, and I do the transcoding on the non-outputting vlc that generates the stream.
I do not transcode on the multicast clients. That would result in bad delays since each system is different in performance.
For this audio example there is no transcoding at all, all can understand the shoutcast originated encodings. (actually, I don't need to transcode for vid ever either... all have the full codec sets).
Does this help?
Yep, there are examples on the net to do synchronized vlc using the --network-synchronization master/client and multiple unicast streams (a 10 mile long target string on the server :-D ).
However: streaming unicast to n clients on a segment makes the stream appear n times on that segment, and the higher up you go towards the originating server, the more multiplications of the same stream eat bandwidth. I would not be able to see my 1080p video. My wireless can barely handle one of those, not always (56Mb).
Oh, you ask how in the GUI:
in the streaming window click 'more options' and deselect "play locally" for the vlc instance that generates the stream (has as input a local file, playlist, or an Internet stream). Leave the caching at the default (1000ms worth of cache). If any of the other clients cannot understand your codec then decide for one that all understand and transcode to that on this same system.
On the options of the destinations you leave the default 'display locally' on, and change the caching: play with this (start at 100 and turn it down) until your slowest system cuts out, then set all the faster systems to the same.
With short buffers: when a client starts up it takes about 10 to 15s of sputtering until it 'gets it'.
My clients are up 100% of the time, whenever I stop streaming they just keep listening to the multicast address.
No port given: default is 1234 everywhere, I run one originating server.
If you run more than one, then you need to give a port number like so: ...239.0.0.1:65535 .
My example numbers: choose any multicast address in 239/8 . Ports: chose any above 1024 (yes, 1024, because Microsoft uses 1024 also on MC).
If nobody is listening then the the stream does not show up on the network at all, it only starts once the first listener joins the multicast session.
So if you have ten defined and listen only to one, then you have one stream eating bandwidth.
If you listen to different streams then you get n times the bandwidth eaten for n streams.
Multicast: bandwidth used is the same for one or 10000 clients per stream.
Using unicast: each client hops on the sender's stream at a different time, which means your lags are still present even if you would tighten down the caching.
Unicast and multicast work entirely different. That's why unicast has the sync feature.
There is a different way if you stream the same to say an entire Target store: then you would stream unicast with synchronization to satellite vlc clients, and serve those that are within 'acoustic range' from there. In offices I do one or two per floor, so all floors are tightly synchronized using unicast and network-synchronization. Within the floor usually the network propagation delay is much shorter than the acoustic delay, and acoustic is turned down so you don't hear all speakers but only the ones near you.
email me at sirhelpsalot@gmail.com if you need help, I might put this on youtube too.
:-)
Best Answer
No (official) information exists yet for HTML5, but I suppose that if the default player is changed in the browser, then HTML5 will use it as well. Below are some sources for installing the VLC plugin in various browsers and OS.
The "The Mozilla plugin" section in the Videolan manual, Chapter 4. Advanced use of VLC, explains the process for Windows/Firefox and OSX/Safari.
For Linux/Firefox see Howto: Firefox Install Multimedia Player VLC with plug-in.