13.2 Digital Video Broadcast (DVB) Multimedia Home Platform (MHP)

Although ATVEF is a powerful tool for creating and deploying interactive TV, it provides for only a limited computer-programming model. In an effort to provide a richer environment for developing interactive content, the MHP solution was developed, which covers the whole range of implementations including Integrated Receiver Decoders (IRD), integrated TV sets, multimedia computers and local clusters of such devices connected via In-Home Digital Networks (IHDN). MHP builds on MPEG-2 transports and adds a technical solution that enables the reception and presentation of applications in a vendor-, author- and broadcaster -neutral framework [MHP]; the first release focuses on single terminals and does not include clusters.

To guide the development of the MHP specification, three profiles were defined: enhanced broadcasting, interactive broadcasting and Internet access:

• Enhanced Broadcasting : This profile combines digital broadcast of audio and video services with downloaded applications that can enable local interactivity. Basic receivers need not be connected to the Internet nor have a return channel.

• Interactive Broadcasting : This profile enables a range of interactive services associated or independent from broadcast services. This application area requires an interaction channel.

• Internet Access : The application area of Internet access is intended for the provisioning of Internet services. It also includes links between those Internet services and broadcast services.

MHP extends the existing, successful DVB open standards [DVB] for broadcast and interactive services in all transmission networks including satellite, cable, terrestrial, and microwave systems. It standardizes a generic interface between interactive digital applications and the terminals on which those applications execute. This interface decouples different providers' applications from the specific hardware and software details of different MHP terminal implementations. It enables digital content providers to address all types of terminals ranging from low-end to high-end set-top boxes, integrated digital TV sets and multimedia PCs.

The MHP was designed to support a wide range of applications including the following:

• EPGs,

• Information services (e.g., super teletext, news tickers, stock tickers),

• Applications synchronized to TV content (e.g., score cards, local play-along games ),

• TV-commerce and secure transactions.

Some key elements of the MHP specification are the following:

• MHP architecture,

• Detailed definition of enhanced broadcasting and interactive broadcasting profiles,

• Content formats including PNG, JPEG, MPEG-2 Video/Audio, subtitles and fonts,

• Mandatory transport protocols including DSM-CC object carousel and IP,

• DVB-J (Java) application model and signaling,

• Hooks for HTML content formats (DVB-HTML application model and signaling),

• DVB-J platform SDK includes JavaTV, HAVi L2 GUI and DAVIC APIs,

• Plug-in specifications (version 1.1 only)

• Event model

• Security framework for authentication (signatures, certificates) and encryption (TLS),

• Graphics reference model,

• DSM-CC object carousel profile, text presentation, minimum platform capabilities.

13.2.1 Basic Architecture

Intuitively, the MHP is the meeting point of video stream input, data stream input and viewer input (see Figure 13.1). The MHP middleware has access to the stream flows, and may write some data to local storage. The platform may be able to route streams and data outwards to a sink or a store.

Figure 13.1. A simplified MHP context diagram.

The platform receives inputs from broadcasted bitstreams, DSM and viewer input devices, such as Remote Control (RC) or Keyboards and produces output communications through a display or other outputs like loudspeakers to present to the viewer. Optionally, the MHP may communicate with remote entities via a return channel or other external interfaces.

The architecture comprises three layers (see Figure 13.2): Resources, System software, and Application. The MHP specification standardizes the application view of the APIs that lie in between the Applications and the system software layer. Typical MHP resources are processing of MPEG data, I/O devices, CPU, memory and a graphics system. The system software uses the available resources to provide an abstract view of the platform to the applications. Implementations include an application manager to control the MHP and the applications running on it.

Figure 13.2. The basic MHP layered architecture.

The core of the MHP is centered around a platform known as DVB-J. This includes a JVM as defined in the JVM specification from Sun Microsystems. A number of software packages provide generic APIs to a wide range of features of the platform. MHP applications access the platform only via these APIs. MHP implementations are required to perform a mapping between these specified APIs and the underlying resources and system software.

• Applications : Applications implement interactive services as software running in an MHP execution environment and utilizing the MHP middleware APIs. These APIs are the top view of the MHP system software. No assumptions are made on the grouping of applications.

• Middleware Implementation : The MHP was designed to use a middleware to decouple rapid evolution of hardware form rapid evolution of applications and enable their cross-platform portability. Key middleware components are an AEE responsible for executing applications, Application Manager responsible for managing the applications,.a resource manager responsible for managing resources, and the PE responsible for managing the audiovisual output.

• Resources : Resources are the representation hardware or software entities providing functionality common across applications. There is no assumption about how resources are grouped: Resources may have no external interfaces or may provide input or output, they may be pure software or data resources, or they may be associated with hardware components. The mapping of resource representation to the physical hardware resources or to the files representing software resources is transparent and implementation dependent. An application should be able to access all local resources as if they were elements of a single entity.

A hierarchy of control is assumed in which each layer controls the processes in adjacent layers. The top layer is responsible for providing the viewer control through the operation of interactive applications. The middleware implementation, through the application manager, presentation engine and resource manager, controls the use of hardware resources. This control is achieved through many APIs that implement distinct platform services supporting streams played from different sources and pipes for conducting them, as well as commands and events, data files, and hardware drivers.

13.2.1.1 MHP Middleware APIs

Applications use the middleware API to access the actual resources of the receiver, including data files, streamed media decoders, static content decoders, and communications. These resources are functional entities of the receiver and may be finally mapped onto the hardware of the receiver in some manner.

The diagrams in Figure 13.3 illustrates these interfaces and their relationships to media and information flows within the MHP. The enhanced broadcast or interactive TV profile is shown, with optional additions or an IP-based return channel. The MHP specification is concerned only with the interfaces of the application module, whose border is highlighted in bold. Other modules are depicted to illustrate the context within which the MHP application interface.

Figure 13.3. Interfaces between MHP applications and the MHP system.

13.2.1.2 Plug-ins

A plug-in is a set of functionality that can be added to a generic platform to provide interpretation of application and content formats beyond what is specified by the MHP specification. Some plug-ins are added at the time of manufacturing, whereas other plug-ins are added after the MHP terminal is shipped or even after it was already installed at the consumer's home (e.g., PCMCIA cards). The burden of proper plug-in specification and interpretability is on the organizations concerned with interfacing with hardware plug-ins or other platforms.

The choice of which plug-ins to use is implicitly (and sometimes explicitly) in the hands of the TV viewer; this choice is made through selection of the iTV service or by the hardware devices plugged into the MHP terminal. Some of those devices and their supporting plug-in may downloadable as needed, from the data broadcast push or an Internet pull.

When the plug-in is used to support special purpose content formats (e.g., Macromedia Flash), the plug-in should stay resident whenever possible; specifically , they can stay resident after the application is terminated or the service introducing it is no longer available. Once the plug-in is loaded and operational, the system should operate in the same way as a platform supporting the format natively.

MHP specification groups plug-ins into two classes:

• Implementation- agnostic plug-ins, which are essentially interoperable MHP applications, illustrated as plug-in "A" in Figure 13.4.

  Figure 13.4. Plug-in implementation options.

  

• Implementation-specific plug-in code (e.g., in native code, or implementation-speci.c Java APIs) illustrated as plug-in "B" in Figure 13.4

The MHP specification standardizes only plug-ins of type A, which are essentially a special type of MHP applications that can provide services to other MHP applications. Plug-ins of type B may include additional hardware and drivers and are outside the scope of the MHP specification.

13.2.1.3 Security Model

The MHP architecture heavily relies on the Java architecture and therefore, the MHP security model is almost exclusively based on the Java fine-grained security framework. Care is taken so that plug-ins have sufficient permissions to access the platform resources to perform their functions and implement the applicable interfaces. While an implementation independent plug-in runs within and depends on, the MHP security sandbox, an implementation-specific (e.g., native-code) plug-in may have access to many of the platform resources irrespective of the MHP security model. All plug-ins are responsible for managing the security of the applications they execute. If a plug-in needs privileged access to resources not available to all downloaded applications (i.e., not in the sandbox) they require the appropriate authentication to provide the equivalent of the 'legacy' functionality.

13.2.2 MHP Transport Protocols

To be able to communicate with the world external to the MHP terminal, it has to support various network types. The MHP specification is concerned only with the network independent protocols available within the DVB framework, as specified in ETS 300 802 and EN 301 192. The protocols defined in these standards provide a generic solution for a variety of broadcast only and interactive services, support DSM-CC U-U data and object carousel protocols (as per ISO/IEC 13818-6) and IP-based protocols; interestingly, IP-based protocols can also be used over the broadcast channel through the MultiProtocol Encapsulation (MPE) (as per EN 301 192). Supported network configurations includes satellite, terrestrial and cable broadcasts using Satellite Master Antenna Television (SMATV) and Multi Media Data Service (MMDS) in conjunction with PSTN, Integrated Services Digital Network (ISDN). These configurations are groups into two classes:

• Broadcast only services are provided on systems consisting of a downstream channel (e.g., via a modem) from the service providers to Service consumers.

• Interactive services are provided on systems consisting of a downstream channel together with return channels (e.g., utilizing a modem).

Figure 13.5 illustrates the set of DVB defined broadcast protocols that are accessible by MHP applications. The underlying protocol is the MPEG-2 transport stream. Data files are delivered either using the DSM-CC or IP encapsulated within MPEG-2 packets according to the DVB MPE specifications. The DVB SI protocol is used for signaling the bindings as well as announcement of the data service. These protocols are as follows :

• MPEG-2 transport stream is defined in ISO/IEC 13818-1

• MPEG-2 private sections as defined in ISO/IEC 13818-1

• DSM-CC private data protocol as defined in ISO/IEC 13818-6

• DSM-CC data carousel as defined in ISO/IEC 13818-6

• DSM-CC U-U object carousel protocol as per ISO/IEC 13818-6 with the restrictions and extensions as per EN 301 192, TR 101 202 and annex B, "(normative): Object carousel".

• DVB MPE as defined in EN 301 192 provides support for IP and is based on the DSM-CC private data protocol.

• IP as defined in RFC 791.

• UDP as defined in RFC 768.

• DVB Service Information (SI) is as defined in EN 300 468 and ETR 211.

Figure 13.5. Broadcast Channel Protocol Stack.

13.2.2.1 Application Information Table

The AIT is an MPEG-2 private section that provides full information on the applications embedded within the data broadcast; see Table 13.2 for the structure of this table. Broadcasters may insert data in the AIT that indicates to a receiver to activate or deactivate an application.

The AIT comprises an application descriptor loop nested within the common descriptor loop. Each application in the application loop has an application descriptor loop containing the descriptors (often pointing to individual resources) associated with that application. Like DVB SI tables, the scope of common loop descriptors is the subtable.

An error in the resource loop of a specific application results in that entry in the application loop being silently discarded. An error in an application information section applicable to all the application results in that entire AIT being silently discarded.

The AIT is transmitted repeatedly. Therefore, application states may be changed and all errors may be corrected at subsequent AIT occurrences. The minimum repetition rate for each AIT is 10 seconds. Assuming that AITs for a service are delivered on 3 or fewer elementary streams implies that the maximum time interval between the moment the AIT is updated and the moment the new version is detected by the MHP is no more than 30 seconds. If broadcasts use more than 3 elementary streams to deliver AITs then receiver response time may degrade in an unpredictable way.

In the absence of an AIT, the activation state of applications persists. For example, when an application or the viewer tunes away from a transport stream into a transport stream whose signaling does not indicate the selection of a new service, the application continues running although the AIT is not visible. In MHP terminals with multiple network interfaces, if the AIT of the selected service is visible via any of them, then the AIT signaling is used as normal.

Table 13.2. Application Information Table Section Syntax

Field				Value	Description
application_information_section() {
	table_id			0x74	A unique identifier for this table.
	section_syntax_indicator			1 bslbf = 1	Always set.
	reserved			3 bslbf
	section_length			12 uimsbf	MPEG-2 Section length.
	application_type			16 uimsbf	See Table 13.3 for application types.
	reserved			2 bslbf
	version_number			5 uimsbf	MPEG-2 section version number.
	current_next_indicator			1 bslbf = 1	Should be set to 1.
	section_number			8 uimsbf	Allows using multiple sections for the AIT.
	last_section_number			8 uimsbf	The index of the last AIT section.
	reserved			4 bslbf
	common_descriptors_length			12 uimsbf	Length in bytes of the descriptors.
	for(i=0;i<N;i++) {
		descriptor()			An MPEG-2 descriptor structure.
	}
	reserved			4 bslbf
	application_loop_length			12 uimsbf	Number of applications in bound service.
	for(i=0;i<N;i++) {
		organization_id		32 uimsbf	Globally unique organization identifier.
		application_id		16 uimsbf	Unique within the org. (see Table 13.4).
		application_control_code		8 uimsbf	Controls application state (Tables 13.7 and 13.8)
		reserved		4 bslbf
		application_descriptors_loop_length		12 uimsbf	Number of descriptors for this application.
		for(j=0;j<N;j++) {
			descriptor()		An MPEG-2 descriptor structure.
		}
	}
	CRC_32			32 rpchof

Table 13.3. MHP Application Types Signaled in the AIT

application_type	Description
0x0000	Reserved
0x0001	DVB-J (JavaTV) application
0x0002	DVB-HTML application
0x0003 0xFFFF	Subject to registration with DVB

The application_id values are unique within the organization; that is, the pair <organization_id,application_id> forms a globally unique combinations. The values for application_id are divided into ranges for unsigned and signed applications. Signed, unsigned applications use an application ID from the signed, unsigned range, respectively. When the application_id is not within the appropriate range, the receiver's behavior is unpredictable (see Table 13.4).

Table 13.4. Value Ranges for Application_id

application_type	Description
0x0000 “ 0x3FFF	Application_ids for unsigned applications.
0x4000 “ 0x7FFF	Application_ids for signed applications.
0x8000 “ 0xFFFD	Reserved for future use by DVB.
0xFFFE	Special wildcard value for signed applications of an organization.
0xFFFF	Special wildcard value for all application of an organization.

The AIT is extensible. private descriptors (i.e., these not standardized by MHP) may be included in the AIT provided that they are in the scope of a DVB-SI private data specifier descriptor. Whereas a descriptor in the application loop is applicable to the application itself, a derscriptor in the common descriptor loop is applicable to all applications specified in the AIT.

13.2.2.2 MHP Interactive Channel Protocols

Figure 13.6 illustrates the set of protocols included in the DVB standard for the support of a return channel. The full details of the APIs that provide access to these interaction protocols are in MHP Chapter 11, "DVB-J Platform" on page 244. MHP requires support for HTTP 1.0 as specified in RFC 1845 and support for HTTPS as specified in RFC 2818. HTTP 1.1 (RFC 2616) support is optional provided that it is backward compatible with HTTP 1.0 persistent connections. Without support for persistent connections, a separate TCP connection has to be established to fetch each URL, increasing the load on HTTP servers and causing congestion. The common use of multiple separate image files and other associated data often require a client to make multiple requests to the same server in a short amount of time.

Figure 13.6. Broadcast Channel Protocol Stack.

The original form of HTTP 1.0 persistent connections is defined as informational text in RFC 2068, that MHP is intended to be compatible. When connecting to a server, an MHP terminal sends the keep-alive connection-token: An HTTP server (1.0 or 1.1) would then respond with the keep-alive connection token and the client may proceed with an HTTP 1.0 (keep- alive ) persistent connection.

When the keep-alive connection-token has been transmitted with a request or a response, a keep-alive header field may also be included. The keep-alive header field takes the following form:

 keep-alive-header = "keep-alive" ":" 0# keepalive-param keepalive-param = param-name "=" value 

where the 0# notation means that the keepalive-param field may be repeated zero or more times and separated by a commas. The keep-alive header itself is optional, and is used only if a parameter is being sent. The MHP speci.cation does not define any parameters. If the keep-alive header is sent, the corresponding connection token is transmitted; the keep-alive header is ignored if received without the connection token.

An MHP terminal does not send the keep-alive connection token to a HTTP 1.0 proxy server, as HTTP 1.0 proxy servers do not obey the rules of HTTP 1.1 for parsing the Connection header field. If an MHP terminal sends keep-alive to a proxy server that does not understand Connection, which would then erroneously forward it to the next inbound server, which would establish the keep-alive connection and result in a hung HTTP 1.0 proxy waiting for the close on the response.

An HTTP 1.1 server may also establish persistent connections with an MHP terminal on receipt of a keep-alive connection token. However, a persistent connection with an MHP terminal cannot make use of the chunked transfer coding, and therefore use a content-length for marking the ending boundary of each message. For servers used for MHP applications, it is recommended that if HTTP 1.1 servers are used, they should support the HTTP 1.0 persistent connections when initiated by an HTTP 1.0 client using the keep-alive connection token.

13.2.3 Loading MHP Application

The MHP specification addresses three possible scenarios: (a) the file system is completely implemented in the broadcast channel (the basic profile), (b) the file system implemented only via the interaction channel, and (c) an hybrid of a and b.

In all these scenarios, a search path, containing a list of search locations, is delivered and used to locate files specified by an incomplete (relative) file name. The items in the search path list are either be references to .zip (or .jar which is essentially a zip file type) files or base URLs ending in /' onto which the path of the requested file is concatenated . Any items in the list which are not one of these two types is ignored. Although the uniform MHP file system semantics apply to the all files fetched , special processing is required for the files dvb.fontindex , dvb.hashfile , dvb.signature.x and dvb.certificate.x .

The MHP terminal attempts to fetch a file from each of the items in that search path in the order in which they are found in the list until the file is found or the list is exhausted. As an example, consider retrieving the image.gif file for an application for which the item list is as specified in Table 13.5.

Table 13.5. Example Item List

Base	Path
http://www.dvb.org	application/application1.zip
	graphics/
	shared/ utils .zip
http://www.ebu.ch	general/misc.zip
http://www.xyz.org	misc/special.zip

For the example in Table 13.5, the search order would be the following:

1. http://www.xyz.com/applications/application1.zip

2. http://www.dvb.org/graphics/dvb.fontindex

3. http://www.dvb.org/shared/utils.zip

4. http://www.ebu.ch/general/misc.zip

5. http://www.xyz.com/misc/special.zip

Under some conditions, carousels carrying files may be lost or inaccessible. When this happens, implementations may continue to provide the cached data. The extent of this is clearly implementation dependent. It is also implementation dependent how this changes with time. Clearly if data from the lost file system is flushed from a cache, it cannot be replaced . Lost carousels are never restored automatically. Data not in such a cache is unavailable to applications. When applications attempt to access data from lost carousels, this fails. The failure mode is appropriate to the content format and the mechanism being used to access the data.

In the hybrid case all directories are delivered using the broadcast, but some (or all) of the files are delivered via the interaction channel. The following delivery modes are supported:

• Broadcast file delivery : This mode supports both files and streams. The contents are carried as an object within a DSM-CC object carousel. The Interoperable Object Reference (IOR) binding a directory entry to the file contents uses either local or remote reference.

• Interaction channel delivery : This mode supports only files (as opposed to streams). The IOR binding a directory entry to identify the location of the file contents on the interaction channel.

13.2.4 MHP Content Types

The MIME Types supported by an MHP terminal are listed in Table 13.6. .Support is provided for image formats, nonstreaming (i.e., file) video and audio formats, subtitles, teletext and both resident and downloadable font formats.

Table 13.6. Content Type Supported by MHP

MIME Type	Extension	MIME Type	Extension
image/jpeg	*.jpg	text/plain	*.txt
image/png	*.png	text/javascript	*.js
image/gif	*.gif	image/dvb. subtitle	*.sub
image/mpeg	*.mpg	text/dvb.subtitle	*.sub
video/mpeg	*.mpg	text/dvb.teletext	*.tlx
video/dvb.mpeg.drip	*.drip	application/dvp.pfr	*.pfr
audio/mpeg	*.mp2	application/dvbj	*.class
text/dvb.utf8	*.txt	application/xml	*.xml
text/xml	*.xml	multipart/dvb.service	*.svc
text/css	*.css

13.2.4.1 Image File Formats

An MHP terminal ignores any indications in the transmitted image with respect to pixel scaling, color space or gamma. One image pixel is mapped to one graphics pixel of the active graphics configuration, unless otherwise scaled by the application directly.

JPEG is supported as defined in ISO/IEC 10918-1 using the JFIF file exchange format. Only coding using sequential or progressive DCT-based mode is required to be supported by implementations. Specifically, lossless and hierarchical modes need not be supported.

Although GIF is supported, it is highly recommended to use PNG instead. PNG is fully supported as defined in PNG. All of the PNG color types are supported and mapped those used by the hardware. Any combination of PNGs with different color types may be active at any one time. Further, MHP terminals are responsible for mapping RGB16 direct color specifications to colors that the hardware can support. However, all PNG graphics should be gamma corrected, and receivers should ignore gamma and chromaticity chunks .

13.2.4.2 Audio File Formats

MHP requires support for a constrained version of the MPEG-1 ISO/IEC 11172-3 Audio Layer 1 & 2 elementary stream (i.e., does not require to support MP3 which is Layer 3); receiver manufacturers are nevertheless encouraged to offer MP3 support. Each file of audio content is a binary data file carrying audio elementary stream data. Each audio file delivers an integer number of audio access units and the first byte of each file is the first byte of an audio access unit. Implementations decoding audio clips often assume that they have an approximately constant number of bytes per second. For non-constant rates the behavior is unpredictable.

13.2.4.3 Video File Formats

MPEG video or images may only be displayable full- or quarter-screen. MPEG-2 I-Frames are supported as defined as in ISO/IEC 13818-2. The payload of a file (as opposed to a transport stream) delivering an MPEG-2 I- frames are a valid video sequence including a sequence extension, and contain one only I-frame.

Video drips are supported, but require the decoder to be in the low delay mode as defined in ISO/IEC 13818-2. The drip feed mode consists of letting an application progressively feed the MPEG-2 video decoder with chunks of an MPEG-2 video stream. In this mode, it is only required for the decoder to handle I and P frames (i.e., not B frame). Each chunk contains one frame and a certain number of syntactic elements (as described in ISO/IEC 13818-2). In addition, the overall concatenation of chunks over time respects the authorized combinations of syntactic elements described in ISO/IEC 13818-2 to build a valid MPEG-2 video stream.

When invalid content is fed to the MPEG-2 video decoder, that content is discarded and there are no guarantees when the subsequent valid chunk of byte fed to the decoder is displayed (unless the decoder is restarted).

13.2.4.4 Audio and Video Streaming Formats

MPEG Audio and Standard Definition (SD) 25 Hz MPEG Video are supported with restrictions, and support for High Definition (HD) formats is optional.

13.2.4.5 Data Streaming Formats

DVB Subtitles and Teletext formats are supported. In the event that both DVB Subtitles and DVB Teletext are available then DVB Subtitles take precedence. Teletext is only supported as an alternative content format for delivery of subtitles. The application has no standard means to discover the delivery of subtitles. The MHP specification does not address the possible use of Teletext as a navigable content format. No standard APIs are provided to access Teletext data packets and no timing model is provided. Nevertheless, broadcasters may use MHP applications to deliver navigable text services.

13.2.4.6 Fonts

Minimally, the "Tiresias" is provided by all MHP compliant terminals, and is minimally able to present at least the sizes of 36 (Heading), 31 (Subtitle), 26 (Body) and 24 (Footnote). Beyond resident fonts, support is provided for PFR as defined as in DAVIC 1.4.1 as the coding format for fonts. Receivers are only required to provide support for the outline version of the font, and only UCS-2 ISO 10646-1 glyph encoding is supported.

13.2.5 Color Representation

The method of color encoding is critical to how consistently the colors in an image can be reproduced across different systems. The description is cast in a way that is independent of the mechanisms by which it is finally reproduced for the viewer.

The International Color Consortium (ICC) has developed a thorough solution to the precise communication of color in open systems. However, MHP did not adopt this standard due to being too constraining for the members of the DVB consortiums. The ICC mechanism for ensuring that a color is correctly mapped from an input to the output color space is attaching a profile for the input color space to the image in question. This is appropriate for high end systems, especially those in the print media. However, a primarily CRT-based home platform neither needs, nor has the processing power and available bandwidth, to handle an embedded profile mechanism. ICC also require some sophistication on the part of the consumer to set up properly.

MHP adopted RGB as its single color space which can be processed as an implicit ICC profile. This approach achieves simplicity, leverages the advantages of the ICC approach, and renders the system scalable to full ICC support. Specifically, imagery uses the sRGB as defined in IEC 61966-2-1. This is suitable for a wide range of presentation environments including TV's and has become widely adopted in the computer environment and the Web. It is, for example, compatible with CCIR Recommendation ITU-R BT.709 standard for color encoding in HDTV. This format provides device independence without a great deal of additional overhead.

For sRGB, the goal is to communicate the appearance of colors as displayed on a reference monitor in terms of 8-bit digital code values for each coordinate. sRGB color values represent color appearance with respect to a defined reference viewing environment. For color stimuli viewed in the reference viewing environment, sRGB values are defined by a series of simple mathematical operations from standard CIE colorimetric values. The sRGB format is a good match for 24 bit (e.g., 8R+8G+8B) color on most CRT's. In devices where a great deal of damage is done to the color space it may not give consistent results. For example dithering to a 4-bit per primary color map violates the gamma assumptions.

To avoid transcoding the input color format into sRGB, all images transmitted are specified using sRGB color space. However, in some cases transcoding may be needed, For example, MHP requires supports for transformations from sRGB to the color spaces allowed by the MPEG-2 and vice versa. Further, JFIF and JPEG support requires transformation from the YCrCb color space to the sRGB color space. To obtain predictable behavior, improve efficiency and maintain consistency with JFIF, JPEG images should use the region of the YCrCb color space that overlaps with the sRGB gamut .

13.2.6 MHP Applications

The unit for the presentation and execution of content in the MHP specification is the service. A service in MHP represents a group of content files or streams intended to be presented together to the TV viewer. A service may consist broadcast DVB service which includes audio and video streams, data streams and all the service information, applications and application signaling that is being broadcast. Other forms of service are possible, including stored services.

Every application running on an MHP terminal is associated, and lives within, a data service, and is presented within a service context, represented by the JavaTV ServiceContext interface. A service context is an "environment" in which a service is presented. It is used as a handle of the service and defines the boundaries of the service. It enables the use of a single handle collectively reference all content components that define a given service.

MHP supports both Java applications, called DVB-J applications, and HTML application, called DVB-HTML applications. Java class files, as well as the set of all files defining a DVB-HTML application, are carried using the Object Carousel. The BIOP::FileMessage doesn't include any HTTP headers (as opposed to the ATVEF approach), neither for HTML files nor for class files.

13.2.6.1 DVB-HTML Application

A key MHP application area is the support of a hypertext or "super teletext" for the presentation of information alongside broadcast. The MHP specification reduces the bar on the minimum requirements for manufacturers by requiring implementers to support only a subset of HTML 4.0; this subset is referred to as DVB-HTML. The DVB MHP specification provides the basic definitions needed for integration of DVB HTML applications into the MHP. Beyond introducing the HTML subset and content restrictions, it defines the application lifecycle, the signaling and transport of a DVB-HTML application.

An MHP DVB-HTML application is similar in form to a Web application. It is a set of files (possibly including references to streams), referred to as resources, selected from the DVB-HTML family of content formats, forming a directed graph. The the nodes of the graph are the physical representation of the resources (i.e., the files or streams) and the arcs are references, e.g., hyperlinks . The interpretation of a DVB-HTML application is performed by a Web-browser support application (commonly called a user agent in W3C terminology).

13.2.6.2 Application Boundary

The set of files within an application is defined by an application boundary descriptor, signaled in the transport using the AIT. The boundary is defined by restricting the namespace of the application; all content documents within this namespace are considered part of the application, and content documents outside the namespace are considered part of other applications. This namespace boundary is used to determine to which application each cached data item belongs, and enables efficient pre-fetching and storing of applications.

13.2.6.3 DVB-J Applications

DVB-J application are Java applications whose entry class file represents a class implementing the JavaTV Xlet interface. DVB-J application may rely on PersonalJava, JavaTV, JMF, and HAVi L2 GUI APIs. The JVM running DVB-J application is required to support Java class files with version number is in the range 45.3 through 45.65535. DVB-J applications are restricted in the use of finalizers, synchronization, and security exceptions.

• Finalizers : A DVB-J application is considered to logically run in its own virtual machine instance. For this reason, it cannot rely on finalizers that are defined in application classes being run when the application terminates. When the application manager terminates the entity that represents the virtual machine in which the application is run, a conformant implementation is permitted to not run application finalizers.

• Synchronization Constraints : DVB-J applications may not synchronize on system classes or other exposed system static objects. SecurityExceptions is only thrown for those referenced packages that do not include any SecurityExceptions .

Subsetting

To reduce footprint and simplify implementation, the MHP DVB-J specification avoided a requirement the complete Java API be supported, and instead, took the approach of subsetting the Java API specification. Where the MHP specification subsets a package, inclusion of the complete package is allowed but clearly not required, and the behavior of these additional features is standardized. Where a class included in the MHP specification has methods with signature dependencies on classes not included in the implemented profile, these methods are not required to be present in an implementation; An implementation may choose to render those dependent methods private, or implement the APIs using proprietary methods .

Class Loading

The DVB-J application environment may be written such that each application appears to run within its own ClassLoader (or ClassLoader hierarchy) for all classes that are not a part of the platform. As a consequence, two applications are never able to access the same copy of any application-defined static variable. Signed applications may only load classes signed by the same leaf certificate.

Class Unloading

Class unloading as defined by the Java language specification.

Event Model

The event model is as defined in the DAVIC APIs that extend java.util.EventObject , and event listeners extend java.util.EventListener . The org.dvb and org.davic APIs, inheriting from java.util.EventObject , provide all methods to manage event listeners. The platform implementation only constructs these events with the appropriate information passed in.

Tuning as a Side-Effect

No MHP API causes tuning unless explicitly specified as such. For example, if a locator that requires tuning is received by the DVBClassLoader it behaves as if the specified file is not available.

Intra Application Media Resource Management

Where an application makes conflicting requests for limited media decoding resources, the media decoding resources that are requested most recently are presumed to be the ones that are most wanted. This applies between MPEG-2 I-frames, MPEG-2 video drips and streaming video. Similarly, this applies between streaming audio and audio from memory.

When a nonbroadcast media presentation (audio or video from memory or still image) is interrupted by a resource loss within the same application, the first presentation is cancelled and not restored. If a broadcast media presentation is interrupted by a resource loss within the same application, the broadcast presentation is restored when the interrupting presentation ends.

Application Thread Priority

The ThreadGroup of application threads has a Max-Priority of 5. As a consequence applications are not able to create threads at priorities greater than 5 since they don't have java.lang.RuntimePermission("modifyThread") . Applications may perform compute intensive tasks within application created threads without being considered unresponsive .

Application Interfaces

The MHP standard contains a detailed API specification of the interface between the MHP middleware and the downloaded MHP application. These APIs could be classified into Personal Java APIs, iTV APIs and DVB APIs (see Table 13.7).

Table 13.7. MHP Java Packages

Personal Java Packages	iTV Packages	DVB Packages
java.lang with constraints	javax.media with constraints	org.dvb.media
java.lang.reflect	javax.tv.carousel	org.dvb.event
java.util	javax.tv.graphics	org.dvb.lang
java.util.zip with constraints	javax.tv.locator	org.dvb.io
java.io with constraints	javax.tv.media.protocol	org.dvb.io.ixc
java.io.file with constraints	javax.tv.net	org.dvb.io.persistent
java.net with constraints	javax.tv.service	org.dvb.user
java.net.URL with constraints	javax.tv.service.guide	org.dvb.si
java.net.InetAddress	javax.tv.service.navigation	org.dvb.dsmcc
java.net.DatagramSocket	javax.tv.service.selection	org.dvb.net
java.beans	javax.tv.service.transport	org.dvb.net.ca
java.math	javax.tv.util	org.dvb.net.rc
java.text with constraints	javax.tv.xlet	org.dvb.net.tuning
java.awt with constraints	javax.media	org.dvb.application
java.security with constraints	javax.media.bean.playerbean	org.dvb.application .plugins
java.security.spec	javax.media.control	org.dvb.application .storage
java.security.cert	javax.media.datasink	org.dvb.ui
	javax.media.format	org.dvb.test
	javax.media.protocol	org.dvb.internet
	javax.media.renderer	org.dvb. smartcard
	javax.media.util	org.havi.ui
		org.havi.ui.event
		org.davic.resources
		org.davic.media

13.2.6.4 Broadcast Service- related Stored Applications

These are applications designed to operate in the context of one or more broadcast services. As a consequence even when stored at the receiver they are not able to run unless suitably signaled in the AIT of a currently selected broadcast service. This includes all applications listed in the AIT whether launchable or externally authorized. These applications include the following:

• applications that have been proactively cached by the MHP terminal implementation

• applications that were explicitly stored as part of the current selected broadcast service

• applications that have been explicitly stored and form part of a stored service and happen to also be present in the signaling of the currently selected broadcast service

This class of application may have dependencies and therefore may not operate correctly unless the MHP terminal is also decoding one of the required broadcast services. For example, an EPG application might be stored to enable it to load more quickly once selected but requires access to the broadcast stream to provide it with data to present.

Stored broadcast related applications have the same lifecycle model as that of broadcast applications. For example, following a service change the application behavior depends on the AIT signaling in the newly selected broadcast service.

13.2.6.5 Supporting Multiple Service Contexts

MHP allows all applications that are signaled within a service to be executed concurrently. However, a service context can present only one service (e.g., channel) at any one time and there is a tight limit on the number of broadcast ServiceContext s that can be presented simultaneously . Selecting a service to be presented within an existing ServiceContext causes the existing service being presented in that service context to stop being presented and to be replaced by the newly selected service. Any content part of the previous service that is not part of the new service stops being presented.

13.2.6.6 Service Selection

In a DVB-J application, selecting a service corresponds to calling the select() method on such an instance. In a DVB-HTML, selecting a service either corresponds to activating a link to a dvb: locator representing a service, or by calling the select() method on a the Java object representing a service context.

13.2.7 MHP Application Lifecycle

The basic control of the lifecycle of broadcast MHP applications is through the selection of broadcast services. Selection of a broadcast service can be initiated by the user of the MHP terminal using the Navigator as well as by MHP applications offering EPG functionality. During the lifecycle of an application, it performs content decoding and presentation, as well as interaction with the viewer. The lifecycle is defined in terms of an actor, which is the locus of activity or process involved in running the specific set of documents for some application, plus any instantiated context for that data. The actor runs inside a Web browser which could be either native, plug-in or downloaded. More than one such locus of activity may be present in any given user agent. Although there is a single actor for each running application, each application can consist of multiple documents, several of which could be simultaneously displayed.

13.2.7.1 Application Control

The AIT broadcast signaling provides a mechanism for broadcasters to control the life cycle of standard application types. The domain of an application is defined as the set of services where the application is listed in the AIT. This can be either as applications listed in the application (inner) loop of the AIT or as applications listed in the External application authorization descriptor. Services where the application is not listed in either of these two-ways are outside of the domain of the application.

The dynamic control of the application life cycle is signaled through a control code (see Tables 13.8 and 13.9) that allows the broadcaster to signal to the receiver what to do with the application with regard to its lifecycle. The set of codes have some differences between application types and so are defined on an application type specific basis. If the receiver receives a code that it does not recognize the application continues in its current state.

Only a single instance of an application with a specific application identifier is allowed to execute at any time. If an application is already running, another instance of the same application, or any other application with the same identifier, cannot be launched. This affects the application autostart behavior applications after service selection.

13.2.7.2 Application States

The application manager can be requested to start an application either because it is signaled as pre-fetch or auto start in the AIT or using the application launching API. The application lifecycle comprises the states of loading, active, paused , destroyed , and killed (see Figure 13.7).

• Loading : During the time an application's actor is in this state, the entry state, the application manager decodes the signaling of the application and loads resources into cache; at this time, the application manager is not yet required to allocate the resources that the application requires for execution. This implies the actor can prefetch content and receive triggering events for transition to the Active state, but is not presented to the viewer.

• Active : Prior to transition of the actor into the active state, the application manager is expected to allocate all the resources that the application requires, allocate an actor, and render the resources accessible to that actor. On entry into the Active state, the actor would be assumed to have full access to the content of the current document and all resources of the MHP, subject to resource management and security issues.

• Paused : The paused state is a reduced operational state. It is entered based on the viewer's action or when the user agent needs resources that the application requires for being active (e.g., display area). When an actor of an application is in this state it may no longer have full (or even any) access to resources it had when it entered the active state. When the actor is reactivated and returns to its previous state, it regains access to these resources.

  Table 13.8. Control Codes for DVB-J (JavaTV) Applications

  Code	Name	Description
  0x00	Reserved
  0x01	AUTOSTART	The file system element(s) (e.g., an Object Carousel module) containing the class implementing the Xlet interface is loaded, The class implementing the Xlet is loaded into the VM and an Xlet object is instantiated, and the application is started.
  0x02	PRESENT	Indicates that the application is present but is not autostarted.
  0x03	DESTROY	When the control code changes from AUTOSTART or PRESENT to DESTROY, the destroy method of the Xlet is called (with the unconditional parameter set to false) by the application manager and the application is allowed to destroy itself gracefully.
  0x04	KILL	When the control code changes from AUTOSTART or PRESENT to KILL, the destroy method of the Xlet is called (with the unconditional parameter set to true) by the application manager.
  0x05	Reserved
  0x06	REMOTE	Identifies a remote application that is only launchable after tuning.
  0x07 0xFF	Reserved

  Table 13.9. Control Codes for DVB-HTML Applications

  Code	Name	Description
  0x00	Reserved
  0x01	AUTOSTART	The Application Entry Point of the DVB-HTML application is loaded. This is loaded into the user agent, and the DVB-HTML actor is created (in the Loading state) and the DVB-HTML application is started. When these steps are complete the DVB-HTML actor is in the Active state.
  0x02	PRESENT	Indicates that the DVB-HTML application is present in the service, but is not autostarted.
  0x03	DESTROY	When the control code changes from AUTOSTART or PRESENT to DESTROY, the DVB-HTML actor goes to the Killed state.
  0x04	KILL	When the control code changes from AUTOSTART or PRESENT to KILL the DVB-HTML actor is terminated.
  0x05	PREFETCH	As for AUTOSTART except that the DVB-HTML actor holds on entry to the Active state and waits for a trigger before completely transitioning to the Active state.
  0x06	REMOTE	Identifies a remote application that is only launchable after tuning.
  0x07 0xFF	Reserved

• Destroyed : An actor is in the destroyed state when it loses the resources or content it needs. The actor may still be able to run the application due to caching or other mechanisms but it is expected that loading of some or all of the application files (i.e., content documents) may fail. It is implementation dependent how such failure is handled.

• Killed : The killed state is characterized by the loss of all resources, and this is the signal for actions concerned with cleanup of the actor. As an actor is killed, the MHP reclaims whatever resources it deems necessary. It is implementation dependent whether cached material is disposed of. If the AIT signal is KILL, an actor is forcibly terminated (and all resources associated with it reclaimed) regardless of state.

Figure 13.7. The Application Lifecycle State Diagram.

13.2.8 Service Selection

13.2.8.1 Viewer Initiated Service Selection

Applications may be persistent across service boundaries. When a running application is signaled in both the new service and the former service it may continue to run and need not be restarted or interrupted by the service change event. In this case, the running application becomes controlled by the application signaling of the new service where it is signaled and not the signaling of the former service. There are a number of situations in which a restart occurs, including situations when the application is bound to the former service or signaled as autostart in the new service. When the application survives a service selection operation it runs in the new service context without automatically getting any access to the broadcast file system of the new service. The broadcast file system of the former service is lost.

13.2.8.2 Application Initiated Service Selection

When a broadcast service is selected, application listed in the AIT of the service and identified as autostart is launched without explicit intervention of the TV viewer. Applications that are started after the selection of a service are controlled by signaling associated with that service. The MHP terminal monitors that signaling for changes made by the broadcaster. These changes may include the termination of particular applications as well as the addition of new autostart applications.

Applications that are not identified as autostart in the AIT are not automatically launched by the MHP terminal, but require explicit launching. This explicit launching can be done by the resident navigator (e.g., menu bar) on the MHP terminal or by an MHP application.

When the currently selected service in a service context includes multiple MHP applications, any running applications may be able to launch other applications from that set as follows:

• A DVB-J application may use the application listing and launching API.

• A DVB-HTML application may either activate a link or use the bridge APIs.

MHP applications may stop themselves voluntarily using the MHP APIs or they may be stopped by the MHP terminal in a number of situations. Examples of situations where this is allowed include the following:

• Replacement by a New Service : When a new service is selected, applications from the former service may continue to execute only if they are signaled in the new service. If an application is not signaled then it is stopped by the MHP terminal. Where an application is known to be bound to a single service, the broadcaster can identify that application as service bound using the service_bound_flag in the application descriptor. Such applications are stopped as soon as possible, allowing the autostart application of the new service to be started.

• Termination by Another Service : Subject to the security policy of an MHP terminal, one application may request to stop another application. In such a case, the resident Application Manager, after a successful security check, kills the application otherwise that application continues running, without interruption.

• Change in Signaling : The broadcaster may request an MHP terminal to stop an application using the control codes in the AIT.

• Shortage of Resources : When an MHP terminal has insufficient resources to continue the execution of an application, it is allowed to stop it intervention.

The MHP terminal continues monitoring the AIT of the logically selected service where this is available on the target transport stream. Where the AIT of the selected service is not available, the application continues executing. The service being presented in the service context is not changed using these mechanisms:

• DVB-J : Service selection API or streamed media APIs

• DVB-HTML : Accessing a link (e.g., in <object> or <img>) or using the API bridge.

Where one MHP application uses the application listing and launching API to successfully start a second MHP application, the second MHP application is executing inside the service context of the first MHP application. The service being presented in the service context is changed by use of these APIs. The number of ServiceContext objects representing a service context is implementation dependant, but each application sees only one such instance. Changes made by one application to the ServiceContext object that it has are visible to the ServiceContext objects representing the same service context in other applications.

MHP applications started in response to a service selection operation are considered to be executing inside a service context. They may obtain a reference to the service context within which they are executing through using the method getServiceContext(XletContext) on javax.tv.service.selection.ServiceContextFactory .

MHP applications may cause tuning to another transport stream directly using the tuning API or, in the case of DVB-HTML, indirectly by reference to a media stream. Such tuning does not constitute service selection and therefore no applications from the target transport stream or service are started either by the MHP terminal or by MHP applications.