The Multimedia Home Platform: Creating a Multimedia World in the STB

The Multimedia Home Platform: Creating a Multimedia World in the STB
Multimedia services are the mecca for equipment designers targeting the home. With that in mind, set-top box (STB) developers need to pack digital TV, MP-3, DVD, and a host of other multimedia services into their system designs.

To help accelerate these developments, industry members have banded together to produce the digital video broadcast multimedia home platform (DVB-MHP) standard, which will ease the development and implementation of multimedia content in set-top box designs. Let's take a closer look at this emerging specification.

Building an Abstraction Layer
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.

The current MHP standard¹ uses an application programming interface (API) based on HTML/Java. This API defines mechanisms for downloading applications, also called Xlets, that are embedded in digital broadcast data streams such as MPEG-2 or accessed over Internet protocol (IP) client/server connections. Most MHP-compliant home terminals include writeable non-volatile storage, allowing Xlets to be dynamically upgraded, replaced, or augmented from a remote location. MHP also defines tools for conditional access (CA), including the DVB common scrambling algorithm for the encryption of transport streams like pay-per-view programs.

Application Profiles
Since many digital TV users will not require the full range of MHP applications, the MHP specification defines three service categories, or "profiles," as illustrated in Figure 1.

Figure 1: Service profiles defined under the MHP spec.

The enhanced broadcast profile, which is similar to the UK's Multimedia and Hypermedia information coding Expert Group #5 (MHEG-5) standard², is essentially an enhanced teletext system with no return path. However, unlike MHEG-5, MHP allows off-air Xlets to execute by providing them with direct access to system resources in a limited and secure manner. Additionally, MHP allows Xlets to continue executing during channel changes. Xlets can thus query system resources like hard disks, change channels, and pipe data to other media, such as hard disks, DVDs, or VCRs.

The interactive broadcast profile is similar to the EuroMHEG profile now being readied for release. It provides extensions to allow user interactivity via an IP return path, such as a landline modem. This in turn enables such applications as instant response advertising (for example, "if you our product, press the red button for a free sample"), electronic voting, and interactive game shows.

The Internet access profile provides full Internet browsing and email capability. Since most web pages are designed for minimum resolutions of 800 x 600 pixels, this profile may have a future PC/TV convergence in mind.

MHP-Compliant STBs: A System Overview
Figure 2 shows the main hardware components in a typical digital TV set-top box (STB), and the additional components needed to support specific MHP functionality (shown in blue).

Figure 2: Typical MHP STB hardware architecture.

An RF input from a satellite disk, cable, or aerial is transported to a tuner/demodulator, which demodulates the signal into an MPEG-2 stream. The next component, the demultiplexer, splices MPEG-2 into its video, audio, subtitle, and data streams. Before being presented to users, video and audio are decompressed by either hardware or software modules. Subtitle data, usually image files with transparent backgrounds, is passed to a dedicated rendering engine with direct access to the STB's on-screen display (OSD). The data stream is parsed for content such as system information, digital teletext, or MHP data objects, then routed to hardware/software modules for interpretation and/or execution.

The CPU, via a specific operating system, controls all software and hardware modules on the STB. In addition to those mentioned, these include video/graphics engines, Java virtual machines (JVMs), and human interface components. Figure 3 shows the software components required for a typical MHP implementation.

Figure 3: Typical MHP STB software architecture.

The digital storage media—command and control (DSM-CC) stack (further described below) provides a mechanism for acquiring data objects from the transmission stream. This includes data specific to MHP, which is transferred to the application manager. MHP-specific data falls into two categories:

• Applications: comprised of compiled Java classes (Java byte code) and associated data components, such as content or images, that can be executed by the JVM. This type of MHP data is updated infrequently.
• Content: such as XML page descriptions and embedded data objects. If the content changes, DSM-CC allows previously downloaded data to be updated.

Xlets are comprised of either application data or combinations of application and content data. The application manager, usually written in Java, controls the lifecycle of resident or off-air Xlets, and ensures content is managed correctly through techniques such as caching. The JVM supplies an essential level of security by relieving the host OS of direct executions of application code, and by providing code portability between a range of CPU architectures.

MHP content, for example digital teletext, is usually transported in XML, mainly due to the inefficiency and inherent inflexibility of HTML. XML and HTML both enclose data within tags, but HTML limits the number of pre-defined tags. XML has no such limit. This allows broadcasters to evolve applications and content by adding/extending tag descriptions within an XML parser class.

Once an active Xlet receives a user request for a block of data, the application manager parses and displays the associated XML content. This parsing can be executed in two ways:

• Through a simple API for XML (SAX), an event-initiated parsing approach where the XML file is read in a linear manner from beginning to end. When sequential XML syntax constructions are recognized, these data blocks are fed back to the application manger.
• Through a document object module (DOM), where the entire XML file is read, translated, and saved as a document tree. Unlike SAX, DOM allows random access to specific data sections, making it far more efficient approach if the XML file contains a vast amount of data.

Xlets, primarily written in Java byte code, require access to system resources, which can compromise system integrity. MHP solves this problem by using a JVM to provide a secure level of abstraction between Xlets and the OS.

More on DSM-CC
DSM-CC is an open protocol for delivering multimedia services over distributed client/server networks. Because DSM-CC is open, it is not affected by underlying transport layers, and can therefore be used to convey a huge variety of multimedia content. MHP uses three areas of the DSM-CC protocol:

1. 1. Multi-protocol encapsulation, which broadcasts data by transmitting datagrams of communication protocols, such as IP packets. This permits IP data to be sent over the broadcast channel.
2. 2. Data carousel messaging, where messages are received via periodic broadcast, with no flow control. These messages provide lists and descriptions of data objects available on a particular broadcast channel and/or relatively primitive data objects. Since the data carousel provides no return path, client and server must have pre-defined broadcast/receive parameters.
3. 3. Object carousel— user-to-user, which provides a filing system for cyclically broadcast data, such as images or XML page layouts. This allows content data to be added, updated, and removed as and when required by describing an object's physical position in the broadcast stream, rather than by merely presenting the object itself. In this way, the storage data required for each application can be minimized, and service providers can structure the transmission of more complex applications.

DSM-CC allows STBs to be configured using "UNConfigIndication" information on a pre-determined broadcast channel. When matched with the download capabilities of DSM-CC, this approach is well suited to low-cost terminals. In addition, configuration information may be used to signal the availability of newer system software, and thus initiate a download.

JVM: The Heart of MHP
A JVM lies at the heart of the MHP system. This virtual machine provides a layer of abstraction between MHP Xlets and system resources, such as the demultiplexer and OSD, on the digital TV terminal.

In general, Java is very portable, allowing the same embedded Applet to execute whether its parent web page is viewed using a browser running on a Windows-, UNIX-, or Mac-based OSes. For STB manufacturers, this portability is attractive because it allows compiled Java Xlets, in the form of classes containing byte code, to be executed on any host architecture. Java Xlets do not directly access system resources, but are "executed" by the JVM using Java byte codes as instruction sets. The key function of the JVM is to load classes when required, manage class lifecycles, and free allocated memory when no longer required.

Java comes in three different editions. The Java 2 Standard Edition (J2SE) delivers the basic functionality required by any Java environment, including a low/middle-end PC. The Java 2 Enterprise Edition (J2EE) includes additional classes for server-specific applications, such as servlets. The Java 2 Micro Edition (J2ME) includes a JVM with reduced code size and memory requirements, and is targeted at systems with limited resources.

To accommodate a vast array of "micro" devices, the latter variant, J2ME, is actually a collection of specifications based around two core configurations. The first is the connected limited device configuration (CLDC), which is aimed at low-end products, such as cell phones, with about 512 kbyte of available memory. CLDC includes the kilobyte virtual machine (KVM) which, compared to the JVM of J2SE, has extremely limited capability. CLDC does not, for example, support floating point math.

The second variant is dubbed the connected device configuration (CDC). CDC is aimed at devices with about 2 Mbyte of memory. CDC's virtual machine (CVM) supports several attributes, including floating-point math, that make it better suited to STBs.

In addition to the individual requirements of their virtual machines, CLDC and CDC require support for a set of core classes, and for an array of device profiles, which specify support for further classes. MHP includes a profile for digital interactive STBs called DVB-J, which lists a series of essential classes, categorised by MHP profile. These include: networking and I/O (java.net, java.io); graphics (java.awt); TV user interface (org.havi.ui); streamed media (javax.media); system information; and Xlet lifecycle (javax.tv.xlet)

Java Xlets
Xlets can be either reside on the STB or be loaded from DSM-CC object and data carousels. The application manager oversees Xlet life cycles, code checking, and memory management.³ Unlike the JVM, which is typically passive, the application manager maintains full control over Xlet loading, running, pausing, and termination, as illustrated in Figure 4.

Figure 4: Xlet lifecycle diagram.

The application manager requires three things to launch an Xlet. First, it needs an application information table that is multiplexed and conveyed with audio and video in the MPEG-2 transport stream. This table contains such data as the application type, control code, application name, and the initial class to call. For example, Xlets can auto-run or called by the viewer. A control code of 0x02 tells the application manager that an Xlet is being activated by the viewer.

Next, the application manager needs Java classes that contain the Java byte codes required by the JVM. Finally, the application manager needs data objects, such as images and page layout information, for the execution of Java byte code.

Java classes and data objects are conveyed by the DSM-CC object and data carousels in the MPEG-2 stream, which can describe hierarchical directory structures required by Java classes. Once an Xlet is complete and signalled for activation, the application manager moves it to a "loaded," then "running" state. From this point on, either the application manager or the Xlet itself can pause or terminate the application. If the Xlet causes a change of state, the application manager is signalled via a call-back.

When selecting a JVM for a particular MHP implementation, the application manager is dependent on multi-threading to allow multiple Xlets to run seamlessly in parallel. Also, to ensure a reasonable level of viewer satisfaction, low application-launch latencies are imperative, which may require a large, efficient DSM-CC data cache.

MHP applications fall into three categories:

1. Broadcast only: Broadcast only apps, such as digital teletext and personal video recording (PVR), only support local interactivity and obtain required data from the broadcast stream.
2. Unidirectional Interactive: Unidirectional interactive apps, such as online voting and advertisement response, allow users to provide response data in a single direction, with no direct reply from the return path server.
3. Bi-Directional Interactive: Bi-directional interactive apps, such as email, web browsing, and online gaming, allows users to acquire data from sources outside of the broadcast stream, such as a return-path server.

Future Proof
MHP is designed to be future proof. Xlets are resident and downloadable, making software components, such as digital teletext, inherently upgradeable. Moreover, with Java as the application language, compiled code is portable between platforms and, thanks to the structured nature of resident Java classes, most functionality can be hosted on the STB.

If there is a downside to MHP, it is the level of system resources required to implement bi-directional interactivity. However, the three MHP service profiles allow even relatively low-end terminals to support limited subsets of MHP functionality. Table 1 outlines the approximate hardware resources required for each MHP service profile.

Table 1: MHP Resource Requirements by Service Profile

	RAM (Meg)	Processor Speed (MHz)
Enhanced Broadcast	≤4	> 50
Interactive Broadcast	≤8	> 80
Internet Access	≤16	> 150

Digital television, supported by MHP, will eventually encompass a huge range of applications, including video on demand, PVR, DVD and audio CD playback/record, Internet access, email, and online shopping. To accelerate thee adoption of this technology in STBs, chip vendors are now looking to implement MHP in their IC designs.

References

1. DVB-TAM232, "Multimedia Home Platform," European Broadcasting Union, February 2000.
2. "Digital Terrestrial TelevisionMHEG-5 Specification", The Digital Television Group, Liss Mill, Liss, Hants, GU33 7BD, United Kingdom. (http://www.dtg.org.uk/reference).
3. C. Peng, P. Vourimaa, "Digital Television Application Manager," IEEE International Conference on Multimedia and Expo, Tokyo, Japan, August 22-25, 2001.

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.