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 United States, and the personal video recorder (PVR).
Due to the convergence of technologies for reception at the home, the DVB branched out from their 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 are 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 system software is basically an abstraction layer. That is to say, 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 life cycle of all the applications. It is implementation-specific, that is to say 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. 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, 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.
In my view, far more interesting than interactivity is the fast-growing market of PVR. Basically, a PVR is an STB with an integrated hard disc drive (HDD). In part due to the much-talked-about “TiVo” in the United States, many countries and manufacturers are now considering what to do about PVR solutions. There are really 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 while the PVR is effectively under the control of the provider. The second type is the free market PVR, which can be for satellite or terrestrial (or for both). In this case the PVR can be freely operated to do exactly what the viewer wants. The third 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.
Many countries today are broadcasting digital terrestrial signals. The PVRs are 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 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).
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 include 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 and is author of the book “Digital Television, DVB-T COFDM and ATSC 8-VSB,” available at www.Amazon.com.