On the 18th of September 2012, we started up our own Internet broadcast of several new channels from different countries on http://www.ontvtime.ru. All of them are live streaming.
As the leading developer of this live streaming system, I decided to write some notes, covering organization questions of own broadcasting through the Internet, the difficulties which we had to encounter, and ways of their solution, as well as emphasize advantages and disadvantages of this system compared both with the Open Source software, and professional decisions. Considering the fact, that is not much information on this subject in free access, maybe it would be useful somehow.
About the technology.
As the signal source we use a signal from the satellite antenna, then we decode audio and video streams and so we get uncompressed video and audio. And then we code video data by video codec H.264, and audio data by audio codec AAC. Then these results are multiplexed in real time into so-called fragmented mp4 files and then these files are sent through the HTTP protocol to the audience. Broadcast viewing is available through the flash player.
Let me enumerate key points that mark out this development from any other similar solutions, from the Open Source software, as well as commercial solutions:
We use Adobe dynamic HTTP streaming technology. Questions on the choice of broadcasting format I posted here – the choice of broadcasting format.
Own video codec of H264 standard was developed. It codes video in real-time mode. It is precisely this video codec, by which all video streams are coded. About what was the need to develop our own video codec, and why it was not better to use the open video codec x264, read in the note “choosing video codec”.
Our own packager was developed. We multiplex audio and video data in format, similar to the format of f4f files from Adobe. About why we are not using finished packager from Adobe, read in the page why do we need to create our own HTTP server.
Our own live streaming http server. It sends fragmented video to customers. Why it is not Apache or nginx - you can read here as well - why do we need to create our own HTTP server.
Our own relays of video streams are used (how relaying works or building your own CDN), allowing to organize distributed network of content delivery or peer-to-peer network topology (Does peer-to-peer television has the future?) and relay any number of channels.
All code is written in Ñ++.
High operation stability, absence of so-called segmentation fault and memory leaks (development methodology).
The system works stable at any, even the most severe conditions - in the absence of a signal, low level of the signal, failures in network’s work. In all these cases, the system works stable and automatically resumes correct functioning, as soon as the signal is normalized, i.e. there is no need to exercise any control over the system’s work.
The possibility to receive, transcode and broadcast by one broadcaster any number of channels, depending only on the server performance is realized.
All of enumerated features allow to put this system in one row with professional solutions for live streaming, as well as to use it by television companies for organizing their own broadcasting.
Within the framework of this cycle of notes, I tried to touch upon practically all major issues that arose. Except the technology of decoding and coding audio, as well as the work of tuner driver’s correction for possibility of simultaneous reception of unlimited number of channels. I hope that in the future I will write about this at greater length.
Do you have any questions, comments, or suggestions? Write me, I will be glad to answer. You can always contact me via the feedback form on the website.
Igor, October 2012.
|
