Initially This page embeds a stream coming from my studio through its 500 Kbps upload ADSL connection. Now I decided to stop that CIF streaming, but in the mean time can be interesting to take a look to this experimental page where a stream is pointcasted through the web toward a cloud reflector that will reflect it in http the the entire world.
All is done through web basic http streaming made possible by videolan and the intelligence of the network that cache all the streams

I'm not a programmer, but at the end I've found a compatible way to produce a unique compatible call.


The first part (Object...) is used by Internet Explorer, the second (Embed...) by the others.

The video is stream in http on port 80 in order to be accessed everywhere.It comes from a cloud server that -- depending on my budget -- could be down.
It may be useful to try to open the stream http://95.110.164.61/Mpeg2 with a Web Transport stream player (not a browser) . I use Videolan VLC.
If you do not know it, I can only say that it is a fantastic open source program (under GPL2 license) to play video, but you can use it to do much more things, such as stream, dump and convert media... You can freely download it from videolan website. It is available for many operating systems, last for Android (currently in beta).

Using Internet Explorer, depending on the the safety settings, you could be prompted for a grant to install the required active-x module I indicated in the webpage. With the other browser you must have had installed the VLC Mozilla plug-in (from version 2 this is done by default during VLC installation).

The video is overvoiced in Italian, because I think it is extremely important to spread its message even in my language.
In any case you can find the entire collection in english on the "the story of stuff project" website and/or looking for it in your own language.

The stream is generated by VLC running on a virtual server in cloud, from a PAL 16:9 MPEG transport stream file.
With a double click over the video area (or clicking the button on the extreme right), it extend to full screen.

The stream is a VBR mean 1,3 Mbps precompressed Mpeg Transport Stream that carries one mpeg2 PAL video (720x404 pixel, 25 frames per second) and one 128 Kbps mpeg1 layer2 audio sampled at 44.1 Khz.
The file is precompressed in the streaming format because I've rent a single core Xeon virtual server. What is important here is the network bandwidth of the virtual server: 1 Gbps!
If you do not see the video correctly it is probably caused by the network speed of your connection: being compressed in MPEG2, any pc/mac/smartphone is able to decode it, while 3g internet connection (and also wi-fi in congested areas) easily do not supply more than 700 Kbps.

It is a live stream: VLC streams only one stream and everyone access the same stream reverse-proxed by Apache.
Indeed you cannot control it: the timeline that appears passing the pointer on the video area is dummy.
If you stop it, after dewnloading the cache, it will skip to the point where the video is arrived in the meantime (the video loop is about 1 hour long).
It is surely more sustainable than the pure unicast approach (used in VoD services as YouTube), because the only unicast informations here are the relayed packets required by the player after receiving a corrupted version.
Joking, I say that this is the Igino Manfre' international Broadcast, and really it is viewable worldwide because its TTL is set to 100.

But it is an http stream (so tcp/ip), that is all but the ideal streaming method.
At infinite time the stream is perfect, streamed and delivered as it is. Some problem may be in the uneven flow of information, not delivered to the player in time to be decoded and presented at the right time.
This can be metered by Media Delivery Index, introduced in 2006 with RFC 4445 by Welch (Ineoquest) and Clark (Cisco). It is explained in the Wikipedia's lemma but perfectly shown by the following graphic taken from Ineoquest's document Media Delivery Index Application Note

.
It shows why a player may be unable to show correctly a flow of 3,75 Mbps despite it get all the required bits: all but not at the right time
The image refers to UDP video delivery (where no repetition is possible): in this case, moreover, you could rely on TCP safe delivery.
Using VLC you can capture the stream creating a file with the following command line

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

The default VLC path is c:\program files\videolan\vlc. In any case you can discover it from the link properties
Beware: the stream is live, it never starts and will never ends. At the pace of about 1.5 Megabit per second, if you forget it, the file can become quite big. After one hour about 700 MB.


This is a live streaming, originated from a loop, but it could be a live stream transmitted from a remote site and mirrored by the cloud server.
On the contrary, in the case of Adobe Streaming Server, Apple Http Live Streaming, Silverlight or the next MPEG DASH (Digital Adaptive Streaming over HTTP) the video is transferred from the server to the viewing PC in thousand slices, each one few kiloByte small files, reproduced as a playlist.
Luckily being delivered as HTTP, they use the http caches of network. But even my streams -- as any http delivery -- exploits these caches, but my audience is quite limited.
It is important to understand that there is no magic in the correct delivery of video over the web.
The approach of VLC, broadcast oriented is more sustainable and cheap: not powerful arrays of servers, because there are not millions of slices to copy to the clients.
The basic system (like the one I'm using) can be a single core cloud server rentable at 40 euro per month so that anyone can deliver a livecontent worldwide.