Important note: References to any products in this tutorial should not be taken as recommendations for or against those products. There are a lot of suitable products in this area, and you should choose the ones that suit you best.
As you will notice when you start seriously looking, head-end equipment can be extremely expensive. Modulators can cost several thousand euros, and other head-end equipment can cost well in to five figures. Building a head-end can cost a great deal of money if you’re not careful. Luckily, if all you want to do is test applications or run simple demos then you don’t need a complicated solution. Most of the basic process of producing and playing out a transport stream can be done on a standard PC with an add-in modulator card. While this is still not a cheap solution (the modulator card and software for producing a transport stream is still quite expensive), it’s an awful lot cheaper than buying a set of standalone components for generating the transport stream and playing it out. Solutions such as the Tektronix AD-952 system include almost everything that you need to record, create, analyse, and play out a transport stream, and these can be ideal for a test environment.
Solutions based around a standard PC chassis such as the AD-952 have a number of advantages in terms of saving space, flexibility and overall cost, but they do have some disadvantages as well. They are designed as test equipment, and are not really designed for use in a real head-end. Despite the fact that many of the standalone head-end devices are based around a PC, there are a number of significant differences in the way that they are designed and put together. The main differences in the requirements between a test setup and a head-end are:
- Reliability. Equipment in a real head-end must work 24/7 for 365 days a year, with no interruptions. This means that the equipment must be highly reliable to start with, and must support features such as redundant power supplies, failover to a redundant device in the event of problems, etc. Solutions designed for lab use are not typically engineered to this level of reliability because there is no need.
- Interfaces. Test equipment will be connected to one STB at a time, usually of a known type. Equipment in a real head-end will be connected to other standalone devices and must use the standardized interfaces such as ASI or SSI for doing this. Equipment in a real head-end may also support a higher number of interfaces, for connecting to several different pieces of equipment simultaneously. For instance, a multiplexer in a real head-end may be connected to both a live output that is connected to the real network and a secondary output for monitoring purposes in the head-end.
- Mounting. Space is at a premium in many test environments, and test equipment is often designed to be portable. In a head-end space is less important, and so equipment can be physically larger. Equipment in a head-end will almost always be rack mounted and so equipment designed for use in a real head-end will usually come in a rack-mountable case.
- Flexibility. A real head-end is usually set up once and then left alone. The configuration of equipment within the head-end is not changed very often, and so it does not need to be as flexible as a test system, which will be reconfigured much more often. This doesn’t mean that standalone head-end equipment is hard to configure – it just means that ease of use may be a lower priority than reliability, although this is less common with modern head-end equipment.
- Integration. A test system will often do many different things: stream analysis, recording, playback, multiplexing, and many others. A typical piece of standalone head-end equipment will do one task only.The main reasons for this are portability and flexibility: a test system often has to be portable, so integration is important. A real head-end system is more concerned with choosing the best equipment for a given task, which can mean choosing equipment from many different vendors. It also means focussing on doing one task extremely well, rather than trying to be merely ‘good’ at a range of tasks.
- Performance. While this is less important as PCs get more powerful and disks get bigger, we still have to remember that head-ends deal with enormous amounts of data, which means that there is a big need for high-performance storage, connectivity, and processing. Dedicated hardware may do a better job of this than a PC built from off-the-shelf components.
This doesn’t mean that a cheaper solution designed for lab use is the wrong choice – that depends entirely on your needs. If you are doing application or middleware development, or even testing g applications before rolling them out on a real network, then equipment designed for lab use will probably suit your needs better than equipment designed for a full head-end. Some vendors will sell either a software package for test systems, or a software/hardware package for real head ends: in this case you can get the best of both worlds.
Using open-source solutions
To make things even cheaper, some open-source software may provide you with some of the tools that you need. One thing to be careful of, however, is that this may not be as compliant with the standards as commercial software. When dealing with complex standards like DSM-CC, this is an important consideration. Similarly, open-source software has often not been as reliably tested as commercial solutions, simply due to the size of the market and the number of different combinations of equipment, parameters, and streams that are possible. Between these factors and the lack of integration between the various open-source solutions on the marketplace, we do not recommend that anyone looks at open-source software for building a complete head-end system any time soon.
If you’re interested in the open-source software that is available to see which parts may be useful to you, take a look at the section on generating a transport stream.