The main feature of an interactive TV system is the ability to run applications that have been downloaded as part of the broadcast stream: this is really what makes the difference between an interactive TV system and a basic digital TV box that does nothing more than your existing TV. Supporting interactive applications requires a lot of support from the software in the receiver; not just in in terms of implementing the APIs needed to run the applications, but also in terms of the infrastructure needed to tell the receiver that applications are available and to how to run them.
MHP applications and services
Every application is associated with a service – there is no such thing as a completely standalone MHP application. This means that the lifecycle of an application is intimately connected with its parent service, and so when the viewer changes channel any applications that are associated with the previous channel will probably be killed. By saying this, MHP restricts the applications that can run at any one time to those that the broadcaster has decided are relevant to what the viewer is currently watching and makes it easier for broadcasters to test that applications will work well together. In the consumer world, this is an important step to making things as reliable as possible.
Typically, all of the information about an application will be carried within the MPEG-2 stream that carries the audio and video for the parent service. This information consists of two parts. The fist part is the files that make up the application, its assets, and its data. The receiver will load these from a broadcast filesystem or over the return channel. We will look at this in more detail in the tutorial on application loading.
Just broadcasting the files for an application is not enough: the receiver has to know that those files make up an application and it must be told how to start that application. This brings us to the second part of the information that is broadcast. MHP defines a new service information table called the Application Information Table (AIT) that tells an receiver what applications are currently available and how to start them, as well as some additional information for both the receiver and the viewer. More information about the AIT and the information it contains can be found in the tutorial on application signalling.
To help with the process of finding available applications and running them, the middleware in an MHP receiver contains a component called the application manager. This is responsible for monitoring the current services, tracking what applications are available as part of those services, and starting or stopping applications as appropriate. This application manager has ultimate authority over what happens to an application – the application manager starts it, the application manager stops it and any interaction between the rest of the MHP environment and the application that may affect its lifecycle is carried out via the application manager.
Before we look at the details of how applications are signalled and loaded, let’s take a closer look at the types of applications that we will see and the lifecycle of those applications. Applications for MHP can be written in either Java or HTML. In both cases, MHP defines a number of extensions and imposes a number of restrictions on what applications can do, and so an MHP application may not be completely compatible with either standard Java or HTML. To distinguish MHP applications from their pure Java and HTML counterparts, MHP uses the terms DVB-J application and DVB-HTML application to refer to Java and HTML applications respectively.
Java applications
As we have already mentioned, DVB-J applications are not like normal Java applications. Besides the differences in the APIs and the restrictions on what they can do, DVB-J applications do not follow the usually lifecycle of a Java application. Instead, they have a lifecycle closer to that of a Java applet – their lifecycle is controlled by the MHP middleware rather than by the user, and this lifecycle may be different from that of the Java VM that runs them.
Each Java application runs in its own virtual machine, which is started when the application is loaded and which terminates when the application quits. DVB-J applications and applets may be loaded into a JVM that is already running, and that JVM may continue running well after they are killed. There is also no restriction on the number of applets or DVB-J applications that can run inside the same JVM – all of the applets on the same web page will share a single JVM, and all of the DVB-J applications in a service may also share the same JVM (although this is not required).
Because of the similarities between DVB-J applications and applets, a DVB-J application is also known as an Xlet. This name is taken from the JavaTV specification that forms part of the MHP APIs, and which defines the basic application model used by MHP and related standards.
As well as the JavaTV APIs, MHP adds a number of other APIs for controlling specific STB functions. These include providing access to DVB service information and other data about the MPEG stream, decoding and displaying broadcast media, displaying graphics and user interfaces in a TV-friendly way, and many more that we will see in other tutorials on this site. On top of this, application developers can also use many of the usual Java APIs and so it’s fairly easy for a developer who is familiar with Java to begin producing MHP content.
HTML applications
The MHP 1.1 specification adds support for DVB-HTML applications (although some elements are present in MHP 1.0.x). The specification for DVB-HTML includes a modularized version of XHTML 1.1, CSS level 2, DOM level 2, ECMAScript and a number of extensions that DVB have defined to allow the receiver to mix HTML and broadcast media in a more flexible way. As you can imagine, the result is a sophisticated but very complex set of technologies for content authors to use.
This complexity means that DVB-HTML applications are not currently used in the real world: MHP 1.1 has not yet been deployed in a real market, and there is no pressure from the broadcasters to deploy it. The main reason for this is the state of the specification – there is no official test suite for DVB-HTML support, and not enough people have implemented MHP 1.1 to allow any real interoperability testing to take place. This makes it very hard to deploy DVB-HTML applications that work well on a number of platforms, or even to tell that a certain platform complies with the DVB-HTML specification.
There is no real pressure to fix this at the moment, and it’s likely that the current DVB-HTML specification will get thrown away in the future and replaced with the HTML specification from the ACAP standard. ACAP has far more reason to define a realistic specification for HTML applications, and MHP is likely to follow this in order to provide harmonize all of the major open middleware standards. In practice, it’s not clear how much change this will actually mean – the ACAP specification for HTML applications will use the same underlying standards as DVB-HTML, but some of the extensions are likely to be different.