Home » Tutorials » An Introduction To MHP  

An Introduction To MHP

The concept of middleware for digital TV receivers is not new. Companies such as OpenTV, NDS, Microsoft, and many others have been selling interactive TV middleware for a number of years, and standards bodies have been developing open standards for middleware for almost as long.

Using middleware for interactive TV development has a number of advantages. It makes it easier for manufacturers to hide differences in the underlying hardware, which in turn makes it easier for network operators to buy receivers from more than one vendor. It also offers a standard platform for application developers – one that provides support for those special features that are needed in the digital TV world such as low-level access to the broadcast stream, service information access, and support for the specialized graphics model of a digital TV receiver. Without these, developing interactive TV applications is much harder and the number of available applications would be significantly smaller.

While open middleware solutions have been available for a while, MHP is the first that is showing real signs of taking off. Previous open middleware platforms had very limited deployments, while more and more companies and broadcasters are showing an interest in MHP. This is partly because of the approach that MHP is taking towards the market: no one sees MHP as a replacement for all of the proprietary solutions that exist today. Those have their place and are better suited for some tasks than MHP will be. The purpose of MHP is to provide a common platform for digital TV and to avoid fragmenting the market too much. It’s not about ‘open vs. proprietary’ or ‘new vs. old’. It’s about creating one big market or creating lots of small ones. The economies of scale of a single big market are very obvious, especially in a global industry such as television. This is one of the reasons why other standards bodies have taken MHP as the basis for their own standards and created a truly global ‘common platform’.

So what does MHP do in order to establish itself as this common platform? There are a number of ways that it is doing this:

  1. Anyone is free to implement the middleware. The specification can be downloaded for free, and the only costs are a small fee for compliance testing and the fees for licensing the necessary IPR from DVB.
  2. Applications are written in Java or HTML, so they don’t depend on any single hardware platform or operating system. The MHP specification says very little about the underlying platform and the hardware that is needed in order to give implementers as much freedom as possible.
  3. MHP has defined the GEM (Globally Executable MHP) specification that allows other standards bodies to build iTV standards that are compatible with MHP while meeting the technical and commercial needs of local markets.

We’ll take a more detailed look at what makes up MHP in a moment, but first we need to understand why MHP came into existence.

This tutorial is designed for people who already have a knowledge of Java and of the basics of digital TV. If you’re not sure that your digital TV knowledge is suitable for this tutorial, please take a few moments to review the introduction to digital TV elsewhere on this site.

Some DTV History

Up to now, almost all digital TV services have been run by pay-TV operators. In this case, the operator has owned the receivers and given them to customers when they subscribe, which means that the operator controls every aspect of the network. This means that each operator can choose a different hardware platform, different middleware and different encryption system than their competitors; they can even choose to use a fundamentally different standard for broadcasting their signals if they choose to do so.

This has been fine up to now, but recently public broadcasters have started offering digital services, and governments in many countries are trying to move from analog TV broadcasting to digital broadcasting. In this case, the pay-TV model doesn’t apply: people are used to buying their TVs from an electronics store and having it work with any TV broadcast, and they don’t want to buy a digital TV receiver that will only work with certain channels. For basic TV broadcasts, standards bodies like DVB, ATSC and SCTE had already developed standards for digital broadcasting that provided a way for all broadcasters in a region to make sure their signals were compatible.

Since these standards were developed to provide a common basis for the entire industry, they are all open – no one company controls them, and the specifications are often freely available over the Internet (although in some cases there may be a nominal fee). On the whole, these have been pretty successful and most digital broadcasts, both pay-TV and public, use these standards.

Of course, this isn’t always good enough. Public broadcasters want to add interactive features to their broadcasts (either to compete with pay-TV operators, or for other reasons), and so there is a need for a similar standard for interactive TV applications. As with the other standards, this has to be an open standard in order to avoid creating a monopoly situation and giving one company too much control over the industry. Similarly, it has to be cross-platform to avoid forcing everyone into a single hardware platform or operating system.

While there had been attempts to develop open-standard middleware platforms in the past, these had not been very successful because they were too limited or because they were too complex. These standards could be quite hard to implement and develop for because most developers were not familiar with them, and the hardware platforms of the time were not really capable of running them fast enough. They have been adopted in a couple of places (such as the UK’s free-to-air digital broadcasts), but have not been very successful on the whole.

Around the time that people were talking about developing a new standard, Java became popular and seemed like an ideal choice – it was easy to develop for, people were familiar with it, and several companies were selling Java virtual machines. After some thinking and legal wrangling over whether Java was open enough, it formed the basis of the MHP standard developed by DVB.

The force behind MHP

The Digital Video Broadcasting Project (usually known simply as either the DVB Project or DVB) is a consortium that is responsible for developing specifications for digital TV. Apart from this main role, it also takes part in lobbying efforts to promote the interests of its members and to promote the growth of digital television. DVB was originally a body for promoting digital television within Europe, but its specifications have been adopted worldwide and so it is now a truly global organization.

At present, the DVB Project has around 300 members. These include broadcasters, receiver manufacturers, universities, and any other organization with an interest in digital TV – members include companies such as Microsoft, Intel and Sun Microsystems, as well as more familiar faces in the digital TV world. DVB itself has very few staff, and so most of the work on developing new standards is carried out by people working for the member organizations. This has a number of advantages, not least that the wide membership of DVB means that the final standards usually reflect a broad consensus from within the industry. It is difficult for one company to push its agenda too much, which makes for balanced specifications that are generally broadly accepted within the industry.

The standards development process at DVB

The entire process of developing DVB standards is driven by the organizations that make up the DVB membership, and this is one reason why the standards process focuses firmly on the commercial aspects as well as the technical ones. The importance of the commercial aspects is reflected in the way that DVB is organized as well as in the standards process. DVB consists of several different groups, each having their own place in the standards process:

  • The Steering Board. This group is elected by the DVB members every two years and is responsible for defining the overall direction of DVB. Amongst other things, it is responsible for deciding what items DVB should work on, and what the priority of those items should be. The Steering Board is also responsible for final approval of DVB specifications, and for working with standards bodies to publish those specifications.
  • The Commercial Module. The Commercial Module is responsible for discussing the commercial issues around a specific work item, and for preparing a set of commercial requirements for that work item. Each DVB standard starts from a set of commercial requirements, which are agreed upon before any technical work on a standard begins. Once a technical specification is complete, the Commercial Module must review it to make sure that it meets the commercial requirements before the Steering Board can approve it.
  • The technical work of creating the text of the standard is carried out in the Technical Module. This is where the technical experts from the member organizations get together to work on the text for a specification for a given work item. Working from the commercial requirements, they will come up with a technical solution that the members can agree on. Once a specification has been finalized in the Technical Module, it is passed back to the Commercial Module for approval before going on to the Steering Board.

Besides these groups, there are two other groups that support the work of DVB. The IPR Module is responsible for setting DVB’s policy on Intellectual Property Rights, and for dealing with any IPR issues that concern DVB. The Promotions & Communications Module is responsible for any promotional activities such as participating in trade shows, and to act as the public relations arm of DVB.

As you can see, developing a DVB specification involves a strong focus on the commercial aspects, but this does not mean that the technical aspects are less important. Many companies participate in the technical side of things, and there is no shortage of expertise that can be called on when developing a specification. By separating the commercial and technical aspects so clearly, the technical module can get on with the business of solving the technical problems without having to worry about the commercial impact. This is not to say that there is not some overlap and dialogue between the Commercial Module and the Technical Module – the use of Java in MHP is both a commercial issue and a technical one – but maintaining a clear separation between the two helps to avoid too much politicking in the technical group.

It’s important to remember that DVB is not a standards body. While it creates the DVB specifications, it does not actually publish them as standards, and while this may seem like a fairly meaningless distinction it does mean that DVB works closely with standards bodies such as ETSI, the ITU, and ISO and that these bodies are ultimately responsible for publishing the DVB specifications as international standards.

What does MHP define?

Now that we’ve taken a closer look at how MHP came to be, let’s talk a little more about what it includes. The most basic thing (and the most important) is a basic model for applications: how they behave, how a broadcaster can tell a receiver that an application is available, and how the receiver can load the files needed to run the application. MHP uses the application model defined by JavaTV, and defines some additional service information to tell the receiver what applications are available. To provide access to the files needed by the application, MHP uses DSM-CC object carousels, where were defined in a pre-existing DVB specification for data broadcasting.

Telling a receiver about your application is only the first part of the picture.  An application has to be able to do useful stuff once it is running, and so MHP defines a number of APIs that allow an application to access the various features of the receiver. MHP applications can be written in either Java or HTML (with Java being the most common by far), and so MHP includes Java APIs for accessing service information, drawing objects on the screen, controlling video and audio, communicating with remote servers, and a whole range of other features. The tutorials on this site should give you some idea of the Java APIs that are available.

For HTML, MHP defines some additions to the Cascading Style Sheets (CSS) specification, as well as a few new additions to ECMAScript, the open-standard version of JavaScript. These let HTML applications work better in a TV environment, and do things like setting where the HTML application should appear on screen, allowing it to refer to broadcast video and audio, resize and position the video, and so on.

One of the most important things that makes up MHP (although it’s not included in the specification document itself) is a set of compliance tests that help to verify whether an MHP implementation follows the specification properly. While this on its own isn’t a thorough way of testing whether a given application will run on a given box (different receivers will have different hardware features, testing can’t cover everything, and there are always ambiguities in a big specification), it’s a good start. When this is combined with the less-formal interoperability testing that goes on in the MHP community, it’s a fairly good way of ensuring that applications will work in a given network.

MHP And The Rest Of The World

Since MHP is a DVB standard, it’s built of top of earlier DVB standards for digital broadcasting such as DVB Service Information and the basic standards that define how video and audio are encoded and transmitted. This is fine if you’re using MHP in a DVB network (e.g. most of Europe and many countries in Asia), but not so good if your network follows the American standards for digital broadcasting. Most people in the industry recognise the value in a common middleware solution in these days of global broadcasting (especially after the dismal failure of earlier iTV standards), and so there was a strong feeling among the various standards bodies that interactive TV standards should be harmonized where possible.

For this reason, CableLabs asked DVB how easy it would be to remove the DVB-specific parts of MHP. After a lot of work, DVB published the Globally Executable MHP (GEM) specification. Based on MHP version 1.0.2, this removed any elements (e.g. the DVB service information API) that were specific to DVB standards. It also added a way for other standards bodies to replace elements of GEM with technologies that are more relevant to their own markets. For instance, the Japanese standards body ARIB has used this to replace DSM-CC object carousel support with support for DSM-CC data carousels which are used in other ARIB standards.

GEM is not a standalone specification – it’s intended to be used by other standards bodies as a basis for their own standards, and so far ATSC, ARIB and CableLabs have taken this approach. GEM now forms the basis of the ACAP, ARIB B23 and OCAP standards. This has a number of advantages for everyone, because application developers can build applications that work on any GEM platform, and middleware developers can use GEM as the core of their products, with some customisation to provide MHP, OCAP or ARIB B23 versions of their middleware. Between GEM and JavaTV (which forms part of the GEM specification), it’s now far easier to move content between broadcasters that use different standards. It’s still not completely smooth sailing, of course, but things are definitely easier than they were.

With the use of GEM in both American and Japanese iTV standards, MHP is rapidly becoming a worldwide platform for interactive TV applications.

Where Next?

Work on the MHP family of specifications is still ongoing, and there will undoubtedly be a number of changes to MHP in the future. At the time of writing, MHP has just published version 1.1.2 of the MHP specification, as well as a set of extensions for adding PVR functions to an MHP receiver. Some of the future changes to MHP will be to add new functionality that companies using MHP want to see, some of them will be to fix problems in the specification or to fix areas that currently have problems, and some of them will be to increase interoperability with other standards that use MHP.

When thinking about future developments in MHP, it’s important to remember that MHP is not trying to take over the world. MHP does not see proprietary middleware solutions as a threat: these solutions have their place in the market, and they will continue to have a big part to play in the industry for a very long time. MHP is about providing a common platform so that we can avoid some of the fragmentation that we’ve seen in the past (a not-too-scientific survey of European DTV operations showed over 25 different combinations of middleware and CA system in use, with some countries using four different combinations. Make your application work on that lot).

While public broadcasters have a strong incentive to use MHP (usually because it’s the only good solution that’s not proprietary), pay-TV operators may choose not to use it. Some are already seeing that harmonization is a good thing and are choosing MHP, while OCAP in the USA is bringing together the cable companies who see the advantages of being able to share content easily without having to completely control the hardware and software specifications of the receivers.

The television industry moves slowly, and it’s still early days for MHP, but the next few years will shape the future of the industry as more public broadcasters in more countries start to offer digital services and interactivity.