Developing Applications

Important note: References to any products in this tutorial should not be taken as recommendations for or against those products. There are a lot of suitable products in this area, and you should choose the ones that suit you best.

There are two ways to start developing MHP or OCAP applications. The first of these is to buy a development system from one of the OCAP or MHP vendors. Companies like ADB, Osmosys, Panasonic, IRT, and others will sell you a developer version of their set-top boxes for around 1,000 euros. This is not very cheap, but if your company is looking seriously at MHP or OCAP then it’s worth the investment

The second way is to use an emulator. These will let you run MHP or OCAP applications on your PC, and may make it easier to start development because you can ignore some of the more complex issues that you will face. Some commercial emulators are available, at similar prices to a development STB. Alternatively, there are a couple of open-source implementations that are available for free. These are usually missing quite a lot of functionality, however. While they are a good way to start developing for MHP (especially if you are on a tight budget), they are not suitable for developing applications to be deployed on a real network and may be missing functionality that you need for your project. If you need functionality that’s not included in the free implementations, you will have to buy a commercial emulator or a development STB.

It’s important to realize that you can’t just buy a commercial set-top box and use it for application development. This approach is much harder (and often more expensive in the long run) than buying a developer STB in the first place.

What to I get with a commercial development system?

Usually, a commercial development system will consist of two things:

  • a set of class libraries that will let you compile your application
  • a platform that lets you run your application. This could be an emulator or a developer version of an STB.

Some development systems may also include an authoring tool, but these are not strictly necessary and many developers prefer not to use MHP-specific authoring tools.

Developer STBs usually have two main differences from the commercial versions. The first of these is some type of debugging output to a console that lets your application print messages to tell you what it’s doing. This may be over a serial line, for instance, or over an Ethernet connection. The second thing is some way of downloading an application that doesn’t use a transport stream. Some developer STBs will do this over the serial connection, others may use TFTP over an Ethernet
connection, still others may use NFS, and others may let you download applications to a hard disk in the STB. The one thing that all of these approaches have in common is that they don’t require lots of expensive
equipment to download applications to the STB.

For many people, an emulator is a good way to get started with application development. It avoids many of the complexities that come with developing digital TV applications, and is a good alternative to a developer STB. While a commercial emulator is not usually a lot cheaper, having your entire development platform on a single PC may be useful for demos and suchlike and may shorten the compile-test-debug cycle. Many of the commercial emulators that are available (such as MHP4Win or OCAP4Win from Osmosys) are built from the same source code as real MHP middleware, and are therefore accurate guides to how your application will behave.

Free emulators such as XleTView and OpenMHP are also available, and these are a good way
to get started with simple MHP applications on a limited budget. However, we do not recommend
them for serious application development – both XleTView and OpenMHP are incomplete implementations
of MHP. This means that they are missing some very important functionality (e.g. most of
the MPEG related APIs) and that they do not always work in the same way as a full MHP implementation.
Using a commercial emulator is more expensive, but it guarantees that your application will
behave as it would on a real receiver.

One thing that no emulator can do is to emulate the performance of a real STB. Partly this is due to hardware differences, but the nature of the product also pays a part: until you actually put your application into a transport stream and load it that way, it’s very difficult to tell how quickly it will load, or what will cause any delays in loading the application or its data files. Similarly, emulators make it hard to test applications that rely on features from the MPEG stream such as stream events, service information and private data streams. Because of this, I still believe that a real development STB has the advantage over an emulator, but emulators are a valuable addition to the application developer’s toolkit.

Whatever platform you use, however, you need to be aware that applications will behave differently on different receivers. If you are developing applications to be deployed on a real network, it’s worth getting several different receivers with different middleware to test interoperability. Not all of these need to be developer STBs, but it is occasionally helpful for debugging purposes to have several different developer STBs or emulators if your budget can stretch that far.

Building your applications

Once you’ve got everything set up with your developer STB, developing MHP or OCAP applications is fairly similar to developing software for other embedded systems. You’re working in Java instead of C or C++, but the build-download-run-debug cycle will be fairly familiar to anyone who has done embedded software development in the past. Many developer systems may limit you to the most basic debugging tools (e.g. System.out.println), but this is less of a problem than you may imagine since you’re working in a relatively high-level system.

To build an application, you can either use an MHP authoring tool, or you can use a normal
text editor and the Java compiler. Some people prefer to use an authoring tool because it
makes some tasks easier, while others dislike them because they are not flexible enough or
because of the quality of code they generate.

Authoring tools will typically include all of the classes you need to compile your MHP application.
If you want to try some of the authoring tools on the market for MHP, the list below includes
some of the more well-known tools. Some of these tools offer trial versions, and so it’s
a good way to see if these tools suit your needs.

For those people who prefer to use a text editor and the Java compiler to build your MHP applications, you will need a set of classes that you can compile against. Some commercial MHP implementations may come with a JAR file of classes that you can compile against, and if your implementation does then it’s best to use these. Other implementations may not do, in which case the stub classes below will provide a way of compiling your application.

If you are using XleTView, your first thought may be to use the classes from the XleTView JAR file. This is not a good idea, for three reasons:

  • You can’t be sure that you are only using classes that are part of the MHP specification, and not classes that are part of the implementation.
  • Some of the classes in the XleTView implementation are not located in the same package as they are in the specification. There are good reasons for this, but they are too complex to explain here and all you need to know is that this means that your Xlets may not compile.
  • XleTView is not a complete MHP implementation, and so it’s missing some classes. Using external stub classes means that you get the full set of MHP APIs.

Stub classes

If you don’t have a copy of the MHP classes, you can download a set of stub classes that will enable you to compile your MHP applications. These are not a full MHP implementation – they only include enough to compile your applications. To avoid any potential licensing problems, this does not include the javadoc comments, but these are available from other places. Once you have added the JAR file to your classpath, you’re ready to start compiling.