Worldwide live web broadcasting through a RTP gateway in cloud

The scope of this page, is to demonstrate how is possible to set-up a worldwide live web audio/video broadcasting originated from everywhere in the world with an extremely limited budget using the public Internet

The following drawing show the architecture of the system running behind this webpage

.
The external stream source, here represented with a laptop, can be whatever video source.

The next embedded video is generated internally to the cloud server, stream in RTP (Audio/Video) by VLC with a very short TTL (despite the RTP (audio/video) transmission is pointed to the server itself, in this case it would not propagate after few hops) then received and re-stream in http on a "strange port" (usually not open on firewalls). This reflexed stream is then proxed on port 80 by Apache, to become WAN prone: receivable worldwide.
This webpage with embedded video has been designed to be viewed through the browsers of personal computers (PC/mac/linux) where VLC player have been installed.
On ARM based smartphones and tablets (not x86 based net PCs), instead of the video, you'll get an empty placeholder with the warning plug-in not installed/available (in italian Plug-in non presente/non disponibile). This is caused by unavailability of video plug-ins for mobile browsers. Also at commercial level, Adobe or Microsoft do not support the flash or silverlight plug-ins, so the browsers must includes an internal capability to handle, decode and present some video formats or are specific decoding applications.

The above video is a full functional but internal webserver simulation (see below).

While the above video is a few minutes video segment in loop, below these lines you probably see two empty rectangle showing the VLC icon on a white or black background: the left one is an embedded player the rightmost is a static image.
They will be both empty until someone will stream toward the cloud server on the right port with the right protocol where the re-streaming engine is listening (tuned, it should be said in analog contexts). If the required kind of stream is found, it is re-transmitted in http and reverse-proxed by Apache on port 80 in order to pass any firewall.

The cloud server has a 1Gbps bandwidth, while the external generator could connected to the web through the upload channel of an ordinary ADSL line (Asymmetrical Digital Subscriber Line), which bandwidth is usually a fraction of Mbps.
This show that is possible to transmit worldwide an anywhere generated RTP stream.
These retransmissions are embedded in this page as 16:9 CIF (352x200), but they could be of any size at the bitrate available by the connection upload speed. I've made tests using a 20 Mbps HD stream where a true broadband connection was available.

This last stream is usually not available. As of writing (mid june 2013) for test I'm often re-transmitting RAI News24 DTT channel pointcasted to the cloud server that reflect it worldwide in http.
So its quality is quite poor due to the narrow uplink bandwidth and to the computational power of my receiver/trascoder. Dealing with h264 computational power is really important. When I use - as I often do - a net PC to squeeze in h264 at about 100 Kbps a CIF video (my house ADSL upload of Telecom Italia's Alice do not allow me more) the overall result is all but fantastic. The Atom processor of the net pc is charged about at 100% (h264 is an extremely complex compression algorithm).
I test this same uplink with an h264 PAL video at 2 Mbps (using a lucky HSDPA mobile 3g connection) and - as I wrote above - much more through a true broadband geografical connection.
But comparing the DTT broadcasting with my retransmission and with what diffused by RAI on the web (www.rai.tv, of which availability I'm sure only in Italy) it is evident how the broadcasting chain adopted by RAI (Silverlight based) delays the simulcasting of about 2 minutes, 120 seconds.
If you see this second video embedded in the page, you can directly recall it using VLC player (not with a browser) the rtp stream http://iginomanfre.it/rtp_ext (or http://95.110.164.61/rtp_ext), even on a smartphone.
The same chain is simulated by the other video of this page, where the cloud server pointcasts in rtp toward itself a stream produced playing a clip in loop. You can always recall this reflected stream as http://iginomanfre.it/rtp_int.

Please note that this html page do not refresh automatically the state of the players, so you must refresh it in order to check if a new RTP stream has been found. The same happens for the VLC on Android (beta), while VLC player on Windows (2.0.4), automatically open the stream as soon it is available.

The usual condition of this second (live) stream would should be an empty placeholder , unless there is a RTP video stream on the right port where the re-streaming engine is waiting.
What described should be what usually shown, the ordinary state (this webpage is a demonstrator). You could generate it by your own from wherever you want (the only condition is to have a broadband connection with a bandwidth upload about double than the stream you are going to transmit).
Obviously you must know the port where the reflector is waiting for the stream: please contact me by mail or by phone (+39 3358235346) or through skype (igino.manfre).
The video shown is an mpeg4 video CIF format 16:9 (352 by 208 pixels) extremely compressed (mean 100 Kbps). But it is evident how this allow to arrange the usage of public internet to transmit a live event to the server in order to let it broadcast worldwide.
All with a very limited budget.

This page in different times (in the meantime it has been slightly modified) while the rtp_ext stream was available because generated by my laptop using its camera (exactly as shown by the top schematic)
The last on the right has been taken on october 9th, 2016. The lower stream therein was an h264 VBR TS ranging from 60 to 200 Kbps trasmitted from my laptop at home.

To view the stream as it is (e.g. to reproduce it through a video output board) or over smartphones you can open directly the stream http://95.110.164.61/rtp_int as proxed by Apache.
Instead of looking this webpage, try to open by your own the stream with VLC available and working fine on Android as well ios7 (iPhones). But you can use any Transport stream player. For Android, after VLC, I've found Stream media player for android by whiztools (to mention the free ones). For iPhone you can use VLC (free) as well or other applications (I do not own nor like iPhones, but I tested the iOs7 porting of VLC) or Goodplayer (sold on app market at 2.99 US$) that should be able to open http streams. But beware: I do not tested it.

The next three screenshots has been taken on my Samsung Galaxy Note2 (android based) playing the internal stream.

loading and playing the stream with VLC for Android


Playing the stream with Media Player
Please read the disclaimer about this video (related to the dyson air multiplier)

My laptop with 4 browsers opened on this page and two versions of VLC (1.1.9 and 2.0.4) opened on the the stream http://95.110.164.61/rtp_ext. From top left: Internet Explorer 9, VLC 1.1.9, Opera 12, Google Chrome, Mozilla Firefox, VLC 2.0.4

network load

As know VLC in basic http streaming do not implement any VoD control. So it generates one only stream for all the players. It sound very similar to multicast, because the only unicast informations are the corrupted packets repetitions requests issued by the players. All (seems) to rely on the web caches scattered everywhere on the web.

This is the server load while there where 4 browser, 2 player and one Android smartphone connected on the 3g network (a completely different route): Any page includes 2 different video objects (rtp_ext and rtp_int) while the players recalls a single stream. Considering the lowest bandwidth of any object in 80 Kbps (they are really VBR, sometimes reaching 130 Kbps) 9 streaming objects would require a total"unicast" traffic of 9x80=720 Kbps (0.72% of 1 Gbps network connection), while the mean request is in the range of 0.20%. Even considering the running of the greater part of clients on the same PC, the caching of the laptop cannot justify such low network drain.


Here is highlighted the spike to about half Mbps noticed when I change the video streamed (8 total video streams).


The above image shows the delay of this chain: about 6 seconds of delay between the watch and the target player. The watch is shooted by the mobile phone with the free app ip webcam while it is connected to my home wi-fi router. On the laptop VLC receives the http stream generated by the phone, transcode it in h264 and transmit it in RTP to the well known port of my aruba server. There the stream is gatewayed in http and reverse-proxed via Apache that trasmit world, as well to the laptop that behave as transcoder. All in 6 seconds of delay.
This feauture is simply impossible using HLS-Silverlight-Dash transmission!
I've tried to use the mobile network of mobile network of h3g but the phone is unreachable (even because the fake ip address 1.176.5.134 is probably a system in United States).
Sorry for the quality of the picture, but it is not simple to hold the phone and take a screenshot (pushing two keys) while shooting the laptop itself.


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

back

much more things