As with MHP, there are two main types of OCAP application. Most applications are written in Java, although the OCAP 2.0 profile adds support for applications written in HTML.
In both cases, OCAP defines a number of extensions and imposes a number of restrictions on what applications can do, and so an OCAP application may not be completely compatible with either standard Java or HTML. To distinguish OCAP applications from their pure Java and HTML counterparts (and from MHP applications), OCAP uses the terms OCAP-J application and OCAP-HTML application to refer to Java and HTML applications respectively. WHile OCAP applications share many features and APIs with MHP applications, they are not identical and so developers should take care when moving applications from one platform to the other.
The lifecycle of an OCAP application
Every application is associated with a service – there is no such thing as a completely standalone OCAP application. This means that the lifecycle of an application is intimately connected with its parent service, and so when the viewer changes channel any applications that are associated with the previous channel will probably be killed. By saying this, OCAP restricts the applications that can run at any one time to those that the broadcaster has decided are relevant to what the viewer is currently watching and makes it easier for broadcasters to test that applications will work well together. In the consumer world, this is an important step to making things as reliable as possible.
Although OCAP applications are usually associated with a broadcast service, it is possible to download OCAP applications and store them in the receiver for use later. Even these applications are part of a service, albeit an abstract service that is only used for grouping applications.
Typically, all of the information about an application (even one that will be downloaded and stored for later use) will be carried within the MPEG-2 stream that carries the audio and video for the parent service. This information consists of two parts:
- The files that make up the application, its assets, and its data are carried in a DSM-CC object carousel. This acts as a broadcast filesystem from which the receiver can read any files that it needs to run the application.
- Just broadcasting the files for an application is not enough: the receiver has to know that those files make up an application and it must be told how to start that application. OCAP uses a new service information table called the Application Information Table (AIT), which is taken from MHP. This table tells a receiver what applications are currently available and how to start them, as well as some additional information for both the receiver and the viewer. More information about the AIT and the information it contains can be found in the tutorial on the lifecycle of OCAP applications.
Java applications
As we have already mentioned, OCAP-J applications are not like normal Java applications. Besides the differences in the APIs and the restrictions on what they can do, OCAP-J applications do not follow the usually lifecycle of a Java application. Instead, they have a lifecycle closer to that of a Java applet – their lifecycle is controlled by the OCAP middleware rather than by the user, and this lifecycle may be different from that of the Java VM that runs them.
Each Java application runs in its own virtual machine, which is started when the application is loaded and which terminates when the application quits. DVB-J applications and applets may be loaded into a JVM that is already running, and that JVM may continue running well after they are killed. There is also no restriction on the number of applets or OCAP-J applications that can run inside the same JVM – all of the applets on the same web page will share a single JVM, and all of the OCAP-J applications in a service may also share the same JVM (although this is not required).
Because of the similarities between OCAP-J applications and applets, a OCAP-J application is also known as an Xlet. This name is taken from the JavaTV specification that forms part of the MHP and OCAP APIs, and which defines the basic application model used by OCAP, MHP, and related standards.
As well as the JavaTV APIs, OCAP adds a number of other APIs for controlling specific STB functions. These include providing access to PSIP information and other data about the MPEG stream, decoding and displaying broadcast media, displaying graphics and user interfaces in a TV-friendly way, and many more that we will see in other tutorials on this site. On top of this, application developers can also use many of the usual Java APIs and so it’s fairly easy for a developer who is familiar with Java to begin producing OCAP content.
HTML applications
The OCAP 2.0 profile specification adds support for DVB-HTML applications (although some elements are present in MHP 1.0.x). The specification for DVB-HTML includes a modularized version of XHTML 1.1, CSS level 2, DOM level 2, ECMAScript and a number of extensions that DVB have defined to allow the receiver to mix HTML and broadcast media in a more flexible way. As you can imagine, the result is a sophisticated but very complex set of technologies for content authors to use.
OCAP 2.0 is largely a political statement designed to mirror MHP 1.1’s support for HTML applications, and like MHP 1.1 it’s not very widely supported at the moment. Partly this is due to the complexity of the specification: support for all of those W3C recommendations is pretty hard to fit in a DTV receiver, and there are a number of interoperability issues that need to be addressed since there’s no good test suite for the W3C recommendations.
The second reason why OCAP 2.0 is less popular is also found in MHP. Like MHP 1.1 and 1.0.x, OCAP produced the OCAP 2.0 profile and then went back to concentrating on OCAP 1.0 – as a result of this, OCAP 1.0 has had many changes made to it, and it’s not always clear how these are reflected in OCAP 2.0.
Since OCAP-J applications are overwhelmingly the most popular type, we wont look too deeply at OCAP-HTML applications for now.
OCAP and GEM
Since version I09 of the OCAP 1.0 standard, there has been a move to harmonize the OCAP and MHP standards in order to make it easier for developers, receiver manufacturers and broadcasters to re-use their products in different markets. It’s not just OCAP that is doing this – the Japanese ARIB B23 standard and ATSC’s ACAP standard are both taking the same approach, resulting in a worldwide set of interactive TV standards that are built from a common base.
The GEM (Globally Executable MHP) specification from DVB forms the base of this harmonization effort. As we will see in other tutorials, this consists of those parts of MHP that are not specific to DVB systems, together with a mechanism that allows the specifications that use GEM to replace elements defined in GEM with their own equivalents. These replacements may happen for technical reasons or commercial ones, and OCAP takes advantage of this to define an approach that works best in the context of US cable networks.
Although OCAP refers to GEM, it also borrows elements from the MHP specification that are not included in GEM. While the OCAP-HTML support in the OCAP 2.0 profile is the most obvious example of this, there are others. Developers may occasionally need to check carefully whether an element of MHP is incorporated directly in OCAP, or whether it is incorporated via GEM. GEM can define its own restrictions on the MHP APIs, and so this may affect how applications will behave relative to their MHP equivalents.