As the STB matures and technology gets faster, smaller, lower power and lower cost, the consumer reaps the benefits … or does he? This article will focus on two main growth areas in STB design: the software stack known as Multimedia Home Platform (MHP), which has now been adopted by Cable Labs in the USA, and the personal video recorder (PVR).
Due to the convergence of technologies for reception at the home, the DVB branched out from its traditional role and looked at the commercial requirements for future interactive receivers. This culminated in the MHP definition, specifically the API. The main driving force behind MHP was to offer interactivity to the end user.
The standard specifies the functionality of applications rather than the full detail of the middleware itself. Hence, the APIs are well-defined, but how these APIs are put together in a real architecture is not. The specification defines the following three profiles:
P1) Enhanced Broadcast: Enhanced middleware features, i.e., digital broadcast of audio/video services including downloaded applications for local interactivity, but very limited interaction with just an optional telephone or cable modem return channel. (MHP 1.0)
P2) Interactive: Ability to run more interactive applications across the return path, i.e., a more sophisticated interactive channel is needed. (MHP 1.0)
P3) Internet: Allowing HTML and other protocols to run via a direct connection to the Internet. (MHP 1.1)
The resources relate to the hardware functions and, therefore, the drivers associated with them. A resource could also be a pure software resource. There is no restriction in the MHP model of the number of hardware resources. Hence, more than one processor is possible. However, the resources must be seen by the layers as a single entity.
 The Multimedia Home Platform architecture provides a flexible, stable platform for both legacy and new applications. |
The system software is basically an abstraction layer; any software above this layer is totally hardware-independent. This means the applications above can be ported to new hardware with no modifications. The function of the API is to offer a clean interface between the system layer and the ones above. It defines a list of function calls into the system layer. The system layer presents an abstract model to the API that consists of (i) streams played from different sources and pipes for connecting them, (ii) commands and events, (iii) data records or files and (iv) the hardware resources.
The application manager software manages the lifecycle of all the applications. It is implementation-specific; it depends on the underlying hardware.
The application layer realizes the actual applications’ functions, e.g., the code necessary for the user to have some interactivity with the system.
MHP doesn’t define but allows plug-ins to enable older legacy software to be used within the MHP environment. The legacy system, when integrated into MHP, must work in exactly the same way as it did in its own legacy environment.
From the applications’ point-of-view, the most important aspect of MHP is the API. For MHP, one of the most important APIs is the Java API, known as DVB-J. So all applications interfacing to this (other than type-B plug-ins) are implemented in the Java programming language. Java applications must run the Xlet interface to be DVB-J compliant. This allows the application and the application manager to communicate bi-directionally. Applications run on the Java virtual machine (VM) can either be resident on the STB or more generally will be downloaded from the broadcast channel inside the transport stream.
This VM (first developed by Sun Microsystems) is essentially a software CPU (although it can quite easily be implemented in silicon). It has an instruction set and manipulates various memory areas at run time. Whereas a compiler of the C language, for example, would compile to produce a machine code specifically for the processor it must run on, Java source is compiled into byte-code or sometimes called J-code. This is a universal code, which is interpreted by a run time interpreter. Nothing regarding the Java specification is left undefined; hence, no implementation specific cases exist. Java applications are, therefore, truly platform-independent and universal.
Far more interesting than interac-tivity is the fast growing market of PVRs. Basically, a PVR is an STB with an integrated hard disc drive (HDD). In part due to the much-talked-about ‘TiVo’ in the USA, many countries and manufacturers are now considering what to do about PVR solutions.
There are three types of PVR that can be purchased. The first is one that comes with a service provider. In this case, the consumer will generally pay extra. The advantages of a PVR, however, may not be fully realized. Additional charges may be imposed to allow the skipping of advertisements, for example, or the service provider may not allow this feature at all. The PVR is effectively under the control of the provider, and he may also spool dedicated advertising to a particular group of viewers.
The second type of PVR is the free market PVR, which can be for satellite or terrestrial (or indeed for both). In this case, the PVR can be freely operated to do exactly what the viewer wants. This type of system works for the free-to-air market as well as the conditional-access market, where decoding via smart cards plugged into a CI or POD slot is possible. This PVR generally offers all the advanced features of full Electronic Program Guide (EPG), excellent recorded program management software, still picture support, easy installation features, and recording from timer or directly from the EPG. It also offers the ability to skip portions of a broadcast (advertisements) at the touch of a button, and to smoothly move fast/slow and forwards/backwards. JPEG decode is also being integrated for the decoding of digital camera images (with input via USB). This then enables the slide show feature.
The third type of PVR has CODEC technology on board. This means that an analog input can be brought in, digitized and MPEG-2 compressed, prior to input to the PVR main processor. The benefits of such a solution mean that even a consumer in a closed vertical market model can make use of such a product. The quality won’t be quite as good as a pure digital one, but all the benefits of the PVR are realized with no additional funds going out to the service provider. Many countries today are broadcasting digital terrestrial signals.
The PVRs are now starting to become available for these markets, too. The low-cost versions have a single tuner for recording one channel, although another channel can be watched that has previously been recorded to HDD. (It is also possible to watch one channel and record another live one, provided both channels are being transmitted on the same multiplex). The low-cost benefit is due to the fact that the main demux processor does not need to have multiple demux engines onboard. The trend, however, will be to move to dual tuner systems, thus giving the full feature of recording one channel while watching any other one (even in time-shift mode). To facilitate the manufacture of such systems for the DVB-T market, Zarlink in the UK has integrated two COFDM decode engines onto its back end demux chip.
Real combination STBs are also emerging, proving the technology convergence is real. More and more STBs are now implementing much more user-friendly features such as weekly program guides, program management lists, satellite databases for easy installation and USALS for the easy acquisition of satellites. Other additions coming into STBs are various games to keep both kids and adults amused.
Mark Massel works for Highgate World Wide, www.highgate.tv, in business development of STB software solutions. He is author of the book Digital Television, DVB-T COFDM and ATSC 8-VSB, available from Amazon at www.amazon.com.