Implementing A Distributed DVB Stack With HeliosTv

What Is HeliosTv

The most basic definition of HeliosTv could be : HeliosTv is a DVB broadcast to IP streaming server. However HeliosTv is much more than that. It should become the army knife of DVB based services. It is a base component on top of which it is easy to implement DVB services. More specifically, when using HeliosTv do not need to struggle with:

• Frontends management.
• Demux management.
• Service priority.
• Integrating with other DVB components : No need to hook section filtering inside a DVB player.

All these tasks are no more necessary. This allows to easily implement DVB services that are independent from each other.

Aims

We want to address two use cases with HeliosTv. The first one is to Implement a distributed DVB stack. As shown in the picture below there are many components in a DVB stack.

The parts needed to implement a player or a recorder are only a subset of a full DVB stack. In order to display an EPG (Electronic Program Guide), the EIT sections must be retrieved and stored in a database. If an OTA (Over The Air) software upgrade or the HbbTV standard are supported then there is also a DSM-CC downloader. With HbbTV, the AIT sections must be monitored to display the application associated to the current channel. On a broadcast box, the time and date are also received via sections. Feature wise, several of these components can be implemented independently from each other. However as the DVB stacks are often built from a DVB player, all these components trend to rely on the DVB player component. As show in the figure below, HeliosTv allows these components to be really independent from each other. They may even run on different devices.

The second use case is adding Broadcast to an IP only device. This idea emerged from the fact that IPTV SetTopBox usually also include broadcast tuners. This allows customers to watch free to air channels with better quality if their DSL line does not support HD video data rate. There are also some cases where the same box has different kinds of tuners so that a maximum of potential customers are supported. This adds extra cost to the hardware while only a small percentage of customers will use it. So instead of providing hybrid SetTopBox to several millions of customers, it may be less expensive to have a single IP SetTopBox, and provide an additional device only to customers that need it. This also allows to split the lifecycle of the broadcast and IP features: The STB can be upgraded while the tuner devices stay the same. A typical example is when a new STB is developed to support new video features (codecs, resolution, or quality). On the other way the tuner device can be upgraded if the kind of tuner or transmission standards evolve. This is the case in several countries in Europe where DVB-T is replaced with DVB-T2. The figure bellow shows this second use case, easily implemented with HeliosTv. Note that the client are not only STB, but any device connected to the LAN.

These are the two use cases that we want to cover, but HeliosTv should be also adapted to other things. It acts as an abstraction layer for the MPEG TS demux, and manages the available tuners. So the client applications do not have to deal with these resources, and any client handling DVB data can be based on HeliosTv.

Design

Before starting this project we considered existing solutions on top of which we could add additional features. From a hardware point of view, the HD HomeRun corresponds to the \"Add broadcast to IP box\" use case. Although its SDK is available, the specifications are proprietary to silicon dust and not documented. An available public specification is SAT>IP. The SAT>IP standard defines how to transport DVB-S content other an IP network. However its main aim is to help install dishes on building and route the signal to all flats. It is based on RTP or HTTP as a transport protocol, which is too complex for our needs.

Then there are some software solutions. Initially I wanted to use TvHeadend, and add features to it. Unfortunately its GPLv3 license prevents us to use it in our products. The license may change in the future, but this can take some time since they need the approval of all contributors. Finally GStreamer also has some DVB support with the tsparse, tsdemux, dvbsrc, and dvbbasebin elements. They are good enough to implement a player or a recorder, but they do not allow integrating the typical components that are present in a DVB stack.

All in all we ended up starting this new project, but based on several open source components. We do not want to re-implement existing features when we can just use them and build new things on top of them.

Although HeliosTv is a streaming software, it is not only composed of a server : The server is one major part of the software since it translates the broadcast content to an IP one, but we also want clients to be available on many different kind of programming languages and operating systems. The following figure shows the global design:

The server is using GStreamer for all the data flow management. It is written in C++. Boost is used, especially the asio APIs to implement the TCP servers asynchronously. Two TCP servers are present on the server : The first one acts as a control channel (to request data), and the second one as a data channel (to receive the requested data). This is similar to other streaming protocols such as RTSP, but dedicated to stream all data types available in a MPEG2 transport stream. The pipeline manager is in charge of building the streaming pipeline. It is a dynamic pipeline where branches are created and deletes depending on the clients that are connected and the type of data they requested. This pipeline is using existing elements such as dvbsrc to receive the broadcast content, and multisocketsink to stream the data on the TCP sockets. We also developed an element to filter the transport packets from the multi-program transport stream. The following figure shows an example of the streaming pipeline with 4 clients receiving 3 services.

The heliostv library is a C++ client implementation. This client library does not depend on GStreamer, so it can be used in any client application. On top of it we developed a GStreamer source element (heliostvsrc) to easily receive DVB services served by the server. Another important part of the project is that the network protocol is specified. It is based on technologies that are available on virtually every operating system and programming languages :

As already said, TCP is used as the transport protocol. We used msgpack as a message serialization protocol. I already talked about it in previous articles. It is a binary serialization protocol with implementations available in many programming languages. This design should allow to write client libraries for many different environments.

Current Status and Next Steps

The project is still in a prototyping phase. It is however fully functional and can be used to stream services. Streaming sections is the next step to achieve. In order to do this, I think that we will use the mpegts packetizer class present in the tsdemux plugin as well as the mpegts library. This will allow to use existing code as much as possible, while implementing an element that we can map on the drivers APIs that are available on a STB. We also need to cleanup some parts of the code and add unit tests.

Try It

The whole project is available today, and open source. All the code is licensed under the LGPL v2 license. The client library is also licensed under Apache 2 so that it can be embedded in software not compatible with LGPL v2. The different repos are available on github: https://github.com/heliostv. Feel free to try it, submit issues, and contribute!