MHP isn’t just a single, monolithic standard where there is absolutely no variation between compliant receivers. Some parts of the standard are optional, as we’ll see later, but most importantly the MHP specification defines three profiles that applications can use to define what features they need. These profiles allow application developers and broadcasters to be sure that receivers will support a common set of functionality, while allowing receiver manufacturers to produce different prueducts at different price points. Profiles are not always an ideal solution, but when chosen well they offer a good compromise between flexibility and interoperability.
The three profiles in MHP are:
- the Enhanced Broadcast Profile
- the Interactive Broadcast Profile
- the Internet Access Profile (added in MHP 1.1)
Of these three profiles, the Enhanced Broadcast Profile is the most basic, and provides no mandatory support for an IP connection over a return channel. It also imposes some restrictions on the type of JPEG images that may be used.
The Interactive Broadcast Profile adds support for IP networking to the Enhanced Broadcast Profile, although support for DSM-CC over an IP connection and HTTP 1.1 is still only optional. It also adds mandatory support for communicating over the return channel and recommended support for IP multicast. Finally, it removes the restrictions placed on JPEG images in the Enhanced Broadcast Profile.
Finally, we have the Internet Access Profile that is added in MHP 1.1. This adds mandatory support for Web, email and Usenet news client applications and an API to access these clients, as well as making the support for IP multicast mandatory.
Each of these three profiles may have multiple versions, indicated by a number after the profile name. For instance, Enhanced Broadcast Profile 1 is version 1 of the Enhanced Broadcast Profile (defined by MHP 1.0.x – MHP 1.1.x defines Enhanced Broadcast Profile 2). Each version must be a proper superset of the previous version, so that any functionality present in the current version must be present in the next version. This is further divided by the actual version number, which corresponds to the version number of the MHP specification.
More detailed profile information is as as follows:
| Enhanced Broadcast | Interactive Broadcast | Internet Access | |
|---|---|---|---|
| Core APIs | Mantadory | ||
| Basic application lifecycle support (javax.tv.xlet package) | Mantadory | ||
| Application listing & launching API | Mantadory | ||
| Inter-application communication API | Mantadory | ||
| HAVi Graphics API | Mantadory | ||
| Java Media Framework and extensions | Mantadory | ||
| Service selection API | Mantadory | ||
| Tuning API | Mantadory | ||
| Basic MPEG concepts (org.davic.mpeg) | Mantadory | ||
| Resource notification API | Mandatory | ||
| MPEG section filter API | Mantadory | ||
| DVB service information API | Mantadory | ||
| JavaTV service information API | Mantadory | ||
| Conditional access API | Mantadory | ||
| Persistent storage API | Mantadory | ||
| Non-CA smart card API | Mandatory (note that the smart card API in MHP 1.1.2 is different from that in other versions of MHP) | ||
| Security classes and extra permissions classes | Mantadory | ||
| Return channel connection management API | Mandatory in MHP 1.1.2, not required otherwise |
Mantadory | |
| DSM-CC over the broadcast channel | Mandatory | ||
| IP over the return channel | Optional | Mantadory | |
| DSM-CC over the return channel | Optional | ||
| Filesystem over the return channel (non-DSM-CC) | Mandatory (MHP 1.1.x only) | ||
| IP multicast support (using any encapsulation mechanism) | Optional | Recommended | Mandatory (version 1.1.x only) |
| HTTP 1.1 support | Optional | Mantadory (version 1.1.x only) | |
| Support for stored services | Mandatory (MHP 1.1.x only) | ||
| Plugin support | Mandatory (MHP 1.1.x only) | ||
| XML parsing API | Mandatory (MHP 1.1.2 only) | ||
| Cryptographic API | Mandatory (MHP 1.1.2 only) | ||
| DVB-HTML support | Optional (MHP 1.1.x only) | ||
DVB-HTML applications typically have higher platform requirements than DVB-J applications, and so they typically won’t be usable on platforms that don’t meet the Internet Access Profile. Most platforms that have all the needed support will likely have a full-blown web browser, and so these platforms probably comply with the Internet Access Profile.
Profiles and application signalling
The AIT will contain an Application Descriptor that contains information about which profile (and which version of the profile) the application needs to run. This allows a receiver to know in advance whether an application will run, and not attempt to start applications that don’t match the profile. When a reciver gets a new AIT, as part of processing the AIT (detailed in the section on the application lifecycle) it will check the profile and version number to check whether that application is applicable to that receiver. If not, it will ignore that AIT entry.
Applications can find out which profile a receiver supports using system properties. MHP defines a number fo new system proprties for identifying the profiles (and profile versions) supported by a receiver, as well as for discovering which optional features are supported by a given receiver.