Globally Executable MHP

The TV industry is very much a global industry where a great deal of content is shared across national boundaries. Content from the USA is often seen around the world, while viewers in parts of Asia may be able to see content from seven or eight different countries on their local networks. As more countries deploy large numbers of channels, they are importing cotnent from other places to fill them.

As well as the usual PAL/NTSC differences, digital TV introduces some new differences in signal modulation and service information. For basic digital TV services, many of these differences are easy enough to overcome – all DTV systems use MPEG-2,and so many changes in can be fixed by remultiplexing and/or re-modulating the signal. Converting between PAL and NTSC is usually the most difficult part fo the proces (if it is needed), and this may involve re-encoding the content. Even in this case, it’s possible to automate the process relatively easily and so changes to basic services can be handled completely automatically.

For applications, the job may be much harder. If the two parties use different middleware platforms, then the application must be ported. Independent content providers may have to maintain several different versions of an application, for each of the common middleware platforms. This obviously adds a great deal of work to the content production process, and so it would be useful if there was as much similarity between middleware platforms as possible.

The driving force behind GEM was an attempt by CableLabs to make sure that their OCAP standard was as compatible with MHP as possible. CableLabs asked DVB to investigate how easy it would be to remove the DVB-specific parts of MHP, and GEM was the result of that process.

So What is in GEM?

GEM itself is based on the MHP 1.0.2 specification, and includes most of the basic elements from MHP. The main thing that is missing is the DVB SI API, which as its name suggests is specific to DVB systems. GEM also removes other references to DVB service information, and describes the application signalling in a slightly more general way. One other element that is removed is any reference to screen resolution or video frame rate, since these are different on NTSC and PAL systems.

A full list of what is and is not in GEM is beyond the scope of this tutorial, but the GEM specification makes it fairly easy to identify what has been removed from MHP.

One thing that has been added to GEM is a way of replacing elements of GEM that conflict with the requirements for a particular standard. Elements may be replaced for technical reasons, such as the use of DSM-CC data carousels and the addition of Japanese language support in the ARIB B23 standard, or they may be replaced for commercial reasons. In the USA, for instance, cable operators typically have much more control over the STB than their counterparts in Europe, and so OCAP has replaced the MHP navigator with a downloadable ‘monitor application’ that has far more influence over the policies of the receiver towards resource management, application management and similar functions.

The GEM specification includes a list of these ‘functional equivalents’, together with an explanation of which elements must have a functional equivalent defined and which are optional. Other specifications may choose to use the MHP features that map on to these ‘functional equivalents’, but if they do so then they must explicitly state that this is the case.

The overall result of this is that while standards from different bodies will take into account the local market conditions, they will have a common core that makes life much easier for application developers. A content provider can build an OCAP application and be relatively confident that it will take only a few changes to get it working in MHP, ACAP, and any other GEM-based standard. There are still some porting considerations, of course, and developers need to pay attention to their design in order to maximise compatibility, but in general it’s a lot easier than it would be otherwise.

The Future of GEM

While GEM is fairly stable for now, there are still some issues to be resolved and it’s likely that there will be other versions of GEM in the future. All of the parties that are involved in developing GEM agree roughly on what it should be, and so its purpose is pretty clear. There are good reasons for keeping things relatively simple and not including too many optional elements in future versions, and so GEM will probably keep evolving without adding anything too radical in the near future. It will probably be updated to refer to MHP 1.0.3 at some time soon, but that is a relatively minor change.

More radical changes may also be in the pipeline, but these are likely to take much longer. These changes may include support for additional functionality like HTML applications, once enough common ground has been established between OCAP, ACAP, and MHP. It may also include additional functionality such as smart card APIs and other elements from MHP 1.1 or from OCAP, but these are less likely since the usefulness of GEM decreases as the number of optional components increases.

One of the more likely changes involving GEM will be the addition of more standards that explicitly use it. At the time of writing, only the SCTE profile of OCAP 1.0 is listed as an official GEM ‘user’. Both the ATSC ACAP and ARIB B23 standards are also based around GEM, however, and so these will also be listed once final versions of those standards are available.