But the internet is not a broadcasting technology, it will never beat FM radio nor terrestrial TV. The quest for video built some of the best monsters of Internet : Real, Quicktime, Windows Media, Flash and VLC.
Displaying offline video is pretty easy, lots of disks, some replication tricks and you can build Youtube. But live streaming is a chimera, even digital TV, with its dedicated network has a few seconds of latency. With Internet, for realtime stuff (like online gaming), you need to use UDP, the fire and forget variant of TCP. UDP doesn't like firewalls, it needs a clear way from the server to the client. With phone networks, it's worse, telephone operating companies hate huge data flow like streaming.
Http is the king of Internet. Http should solve anything, even bad faith. Apple, after some ugly tricks and half baked technologies, suggests something simple : http live streaming . Using simple and firewall friendly http connections to display live video streaming. Real Technology is now dead, Flash, even with its streaming server is dying, MPEG rules (and licences) the world, there's a place to put a simple standard.
The video is cut in 10 seconds packets, each packet is served with your favorite http server (apache, nginx, IIS...), and a playlist indicates the name of the packets. When the playlist is read, the client re-reads the playlist. The server just has to build video packets (from a card, a video camera, another video stream...), and dynamically write the playlist. No dynamic web technology, just plain old static delivery. It's http, you can add cache proxy, ssl, authentification, any of the http wonders.
The packets are MPEG-TS packets, boring, but standard and documented format. You can use MP4 or H264 compression (or classical mpeg for the fun) and MP3 or AAC for the sound. Just like your network television.
The delivery tactic is dummy, the compression formats are well known (and even hardware accelerated), so, it's easy to implement a client. All iStuff from iOS 3 and upwards handle it, Safari and Android (Honeycomb), VLC and Mplayer. Maybe Flash can handle that, but who cares? Firefox doesn't like MPEG untrustable patents, and Internet Explorer doesn't like anybody. Firefox handles H264, after an arm-lock, and its javascript API can handle this simple protocol. Anyway, it's clearly a smart phone ready protocol. More than half of the world's internet connections come from smartphones.
VLC is not an ultimate Divx player. This true fact is just a coincidence. VLC is born to play video from a LAN network. Video, LAN, like in videolan.org .
You have got a packet format, some compression and a delivery method, all that stuff almost realtime (few minutes of latencies, it's smooth realtime, just don't phone the TV show), now, you need bandwidth. Each client needs its own bandwidth, nobody can wait its turn, with streaming, everything happens here and now. Your nice DSL cannot provides such flood. You will need a server and not too many clients. The simplest way is to unicast data from the source to the server and and use http live streaming to deliver it.
VLC can do all the needed steps to stream live videos. Except on Mac, a known and old bug breaks sound when using quicktime source. Only pictures are handled. Linux, with video for linux, and Windows with directshow got pictures and sounds. Annoying. But unicast sending is a standard, and QuickTime Broadcasting, an old and forgotten application which still works with Mountain Lion. Add CamTwist Studio to your workflow to show to the world how your Mac is the ultimate hipster computer.
Unicast from a Mac
Quicktime Broadcaster, from 2009, was a front-end to the already forgotten Darwin Streaming Server. Select a source, try the DSL compressions, and, in the network panel, select "manual unicast" and set the ip of your server. Launch Twistcam Studio before QuickTime Broadcaster, and try some hugly and pretentious filters.
File/Export/DSP... and put the sdp file on the server, it will be its source.
Unicast flow from a Linux or a Windows
vlc -vvv v4l:// --sout='#duplicate{dst=display, dst="transcode{width=320,height=240,fps=25,vcodec=h264,vb=256,venc=x264{aud,profile=baseline,level=30,keyint=30,ref=1},acodec=mp3,ab=96}:standard{mux=ts,dst=MYPUBLIC_SERVER,access=udp}"}' Choose your live source, v4l:// is for Linux, dshow:// for Windows and qtcapture:// is for Mac. You should read the videolan wiki and play with the streaming assistant, to find the right options. In this example, the stream is sent twice, one to the display, as a preview, and the other is transcoded : a small 320x240 pixels, with h264 compression, small MP3 sound. Encapsulation is done with ts format, and sent to MYPUBLIC_SERVER, with udp packets.
The server will use udp:// as source.
Http Streaming
On your server, another VLC will receive packets and write m3u8 playlist with 10 seconds ts packets. Debian/Ubuntu packet is vlc-nox, the headless variant of VLC.
vlc -I dummy mystream.sdp -vvv --sout='#std{access=livehttp{seglen=10,delsegs=true,numsegs=5,index=/data/streaming/mystream.m3u8,index-url=http://MYPUBLIC_SERVER/mystream-########.ts},mux=ts{use-key-frames},dst=/data/streaming/mystream-########.ts}' VLC uses the dummy interface (the headless one), your source, a SDP file or udp://, no transcoding, job is done on the source, delivery is one with livehttp, with 10 seconds packet, 5 packets are kept, playlist path, hardcoded packet url, and playlist path.
Configure your favorite webserver and don't forget to add two exotic mime-types:
- application/x-mpegURL m3u8
- video/MP2T ts
You can now try to open the playlist URL with different players. None of them will be synced, and you will something see up to one minute latency, like a late mirror.
Http live stream can do more, like multiple compression for the same source or meta data announce. Good luck with different and closed client implementations.
In this example, video udp upstream is not secure, and be careful, bandwidth is not free, try not to explode your quota too soon.
This is a technical article, making movies is a job, ask help from someone with taste, use some light, find the right camera (maybe a nice USB one) and use a microphone.
