Comparing the MHEG and MHP Specs

Comparing the MHEG and MHP Specs
Streaming entertainment service throughout the home is being pitched as the big win for networking equipment designers. Clearly, to make this delivery come to life, designers need to build gateways that support digital TV, DVD video, MP-3 audio, and more.

Debates over the look and feel of the residential gateway have raged on for the past several years. While debates continue, set-top box developers are quickly putting together a set of specs that will 'multimediaize' their existing TV box designs.

Right now, two specs are vying to be the baseline protocol for multimedia-enabled set-top boxes. The first, adopted by ISO and commonly known as the multimedia and hypermedia information coding expert group (MHEG), is derived in part from DAVIC specifications. The second, adopted by ETSI and known as the digital video broadcast multimedia home platform (DVB-MHP), is based on contributions from the DVB consortium and the HAVi team. Let's see how these specs compare and contrast starting with a look at the MHEG-5 architecture.

MHEG-5 architecture
ISO defines a family of MHEG standards, from MHEG-1 to MHEG-7, that allow multimedia objects to be distributed in a client-server architecture across a variety of platforms. MHEG-5 is a streamlined, application-specific version of MHEG-1 for low-resource STBs that embeds an MHEG boot application in the MPEG-2 stream. The name and location of the boot application in the digital storage media command and control (DSMCC) object carousel is defined by parameters in a service information (SI) table.

The boot application is a self-contained, interpreted object describing: the layout of the STB on-screen display (OSD); hyperlinks to alternative 'screens'; the position of and links to content in embedded objects, such as graphics and audio streams; the resizing, retuning, and repositioning of the active video plane; and playback of time-dependent content, such as multiplexed audiovisual data.

Figure 1: Diagram highlighting the MHEG-5 software architecture.

Figure 1 illustrates a typical MHEG-5 software architecture. As shown, the boot application includes a core set of MHEG-5 classes. These classes are:

• Application, which contains a collection of scenes and ingredients. The application entry point is the initial scene to be interpreted
• Scene, which contains a collection of ingredients described in terms of presentation (OSD) coordinates
• Ingredient, an abstract base class for a series of subclasses
• Presentable, which specifies common attributes of information that can be seen or heard
• Visible, which extends the Presentable class to describe positioning and behaviour of variables like bitmaps, circles, rectangles, lines, text, and fill colours
• Stream, which controls presentation and synchronization of audio-visual data, such as compressed MPEG-2 streams
• Link, which, in its simplest form, provides a transition to another scene
• Interactable, which allows user interaction with objects in the following subclasses: switchbutton, hotspot, and pushButton; hypertext; and slider and entry field

In addition, MHEG-5 defines a set of resident program classes that include DAVIC day/date/time, OctetString manipulation, service tuning, and scaling and CI (common interface) communication.

Another important aspect of MHEG-5 is its graphics engine model, which defines minimum requirements for the final OSD rendering of MHEG objects. These requirements are for:

• Palette, a minimum of 256 colors
• Image Formats, only portable network graphics (PNG) and MPEG stills
• Colorspace, RGB for buttons, text, line art, and PNG graphics, and YCrCb (two chrominance, one luminance) for MPEG stills and DVB subtitles
• Transparency, 0% and 100% transparency on a per-pixel basis, and the nearest approximation to 30%
• Overlapping visibles, various approximations to the 'ideal,' including top-level punch through to lower-level objects
• Font Rendering, four font sizes as a minimum, using the Tiresius font.

Extending MHEG-5
MHEG-6 extends MHEG-5 by adding a Java API and J virtual machine (JVM).⁴ These components perform data processing, such as the interpretation and presentation of SI data in an electronic program guide (EPG), and communicate with local device drivers (i.e. java.util and java.io).

A key element of MHEG-6 is a mechanism that allows downloaded applications to 'execute' on the target, rather than being processed by an interpreter, such as an MHEG engine. This mechanism paves the way for applications that:

• Provide a return channel, via a serial modem IP link to a subscriber's phone line
• Parse, interpret, and display SI data in a variety of formats by directly accessing the system demultiplexer data streams
• Communicate directly with standard interface hardware to allow, for example, vendor-specific conditional access modules
• Provide a read/write file system and database modules for the efficient storage and caching of off-air data.

As illustrated in Figure 2, MHEG-6 is also backwards compatible with MHEG-5. This compatibility is achieved via the MHEG engine, which passes MHEG-6 Java byte code directly to the JVM. MHEG-6 Java byte code applications can be authored with embedded MHEG-5 content which, via the iso.mheg5 java class, can be passed as a block back to the MHEG-5 engine when required by the Java application.

Figure 2: Diagram of the MHEG-6 software architecture.

Detailing MHP
The DVB-MHP spec inserts an abstraction layer between applications and digital TV terminals. This allows applications to be carried over any DVB-compliant network, be it cable, terrestrial, or satellite, to a wide range of terminal types, including low- and high-end STBs, integrated digital TVs (iDTVs), and multimedia PCs. (Note: For more information on DVB-MHP, see The Multimedia Home Platform: Creating a Multimedia World in the STB)

Figure 3 illustrates the typical software components needed by an STB to support MHP.⁵

Figure 3: Diagram of the MHP software architecture.

MHP applications, called Xlets, are typically written in Java and compiled by the extensive range of Java classes defined in the MHP specification. These classes cover the following categories:

• Java media framework (JMF), for streaming video control
• Service Information, for program guide information
• Tuning, for channel changing and applications like picture-in-picture
• Conditional Access, for applications like pay-per-view
• XML Parsing, for XML interpretation
• Abstract Windowing Toolkit, for GUI (graphic user interface) rendering
• Internet Protocol and HTML, for a return path, web browsing, and email
• HAVi, for user interface compatibility
• I/O, for access to a limited number of system resources, like RS232 and IDE

The heart of the MHP stack is the application manager, which controls the full life cycle of Xlets, several of which can run concurrently. The application manger parses an application information table (AIT) via one of the transmitted MPEG-2 data streams to gain information about Xlets, including the application type, the control code (i.e. 0x02 = activated by the viewer), the application name, and the initial class to call.

Once an application has been called by the viewer or auto-loaded, it is moved from a 'loaded' to 'running' state. At some point, it can then be 'paused' or 'killed' by the Xlet itself or the application manager. The application manager is also responsible for overall memory management, code checking, and Java class/application data sourcing. Any data not already resident on the STB will be available from the DSMCC object and/or data carousels. Creative caching of these DSMCC objects by the Application Manager improves the efficiency of the MHP implementation.

MHP has the potential to be a very powerful technology. However, since many digital TV users will not require the full range of MHP applications, MHP defines three key service categories:

• Enhanced Broadcast—a unidirectional service that downloads off-air multimedia data in formats such as text, PNG, JPEG, GIF, and MPEG, delivers a smart card API, and provides local storage for application byte code and data.
• Interactive Broadcast—which adds extensions for an IP return path, and the downloading of Xlets via HTML or DVB-J classes.
• Internet Access—which adds extensions for Web browsing and an email client, such as POP3, as well as for Java APIs for Web email.

MHP is designed to allow a range of applications to be resident on the STB or available off-air, including EPGs, home shopping, DVD playback/recording, and digital teletext.

Spec Overlaps
Despite the two camps, there is actually a significant degree of commonality between MHEG and MHP. For example:

• Both use MPEG-2 (Moving Picture Expert Group, Standard #2)to encode video, audio, and other supporting information for transport over digital terrestrial channels.²
• Both use the open DSMCC protocol, a subsection of MPEG- 2, to deliver multimedia objects over distributed client-server networks.³
• Both describe Java classes supported by a 'resident' JVM.

The key to displaying multimedia content on a STB is the mechanism by which data objects are transmitted and received. MHEG and MHP both use the open DSMCC protocol to perform this function. The DSMCC has an object carousel that provides a filing system by cyclically transmitting objects such as images, boot applications, and page layouts (i.e. XML documents). An API defined by DAVIC describes a URL format for referencing elements in the carousel, allowing an object to be addressed in a manner similar to UNIX file/directory referencing (i.e. //d/a is a typical boot application in MHEG). Many MHP and MHEG implementations improve the speed of the DSMCC object carousel by caching most, if not all, of the data for a particular DSMCC stream.

In addition to supporting DSMCC, MHP and MHEG-6 each require execution of code on the target STB. For this reason, both specify Java classes that must be supported by a 'resident' JVM. By contrast, MHEG-5 does not use a JVM, as its applications are interpreted documents with embedded hyperlinks, which do not need to execute code.

For an object sourced from the DSMCC carousel to execute, it must have limited access to a variety of system resources, such as file systems and I/O paths. The main problem here, apart from security, is that broadcasters have no idea which OS these objects will execute. A JVM solves this dilemma by providing an abstraction layer between the low-level OS and the compiled Java byte code of an MHEG-6 or MHP application.

Sun Microsystems has defined a variety of Java implementation scenarios. The one most likely to be used in low-cost STBs is the J2ME connected limited device configuration (CDLC). J2ME CLDC defines a kilobyte virtual machine (KVM), a reduced-capability version of the JVM that does not support floating-point maths.

The CLDC specification defines a set of core classes that must be implemented. These are extended by both MHP and MHEG-6. MHP uses the DVB-J platform with additional Java APIs defined by HAVi and DAVIC. MHEG-6 extends a basic set of Java APIs, including java.lang, java.util, and java.io, to allow access to limited STB resources. MHEG-6 also provides a path to the services of a resident MHEG-5 engine via the iso.mheg5 Java package.

The most advanced MHP service category—Internet Access—is where the two specifications really begin to part ways. MHP defines additional extensions for web browsing, email clients, and web mail. MHEG-6 stops short of this, with IP extensions for only a return path. However, MHEG-6 needs only an alternative profile to deliver this capability.

Thus, there is significant common ground between MHP and MHEG. The difference is clearly in the detail, rather than the application. Both use the DSMCC object carousel off-air filing system and a JVM. Ultimately, they both aim to convey enhanced multimedia data to viewers, with additional specifications for interactivity.

Current Implementations
Currently, few digital terrestrial service providers are transmitting MHP or MHEG application data, although many STB manufacturers can demonstrate the technology. In the UK, the 'Freeview' consortium broadcasts MHEG-5 (UKProfile1) data. Several European countries are exploring this option in the form of EuroMHEG.⁶

Some European broadcasters that were leaning toward MHP are now preparing to use MHEG, at least in the short term, since MHEG is a readily available, proven technology. In the long run, however, MHP could win out because it sets out a longer roadmap for digital STB evolution by encompassing a wider range of multimedia devices, such as DVDs, MP3 players, and CD audio. It will be interesting to watch how the market evolves from here.

References

1. MHEG-5, international standard, ISO/IEC 13522-5
2. MPEG-2, international standard, ISO/IEC 13818-(1 to 7).
3. DSMCC, international standard, ISO/IEC 13818-6.
4. MHEG-6, international standard, ISO/IEC 13522-6
5. MHP, international standard, ETSI TS 101 812 V1.2.1 (2002-06).
6. EuroMHEG, MHEG-5 extensions, DTG 1999

About the Author
Anthony Daniels is a senior software engineer at Zarlink Semiconductor. He has a Bachelor's in Electronic Engineering from Liverpool University, UK and a Ph.D. from Sheffeld Hallam University, UK. Anthony can be reached at tony.daniels@zarlink.com.