So, you’ve finished reading all these tutorials, and you’ve taken a look at the specification, and you’ve decided that you like this MHP stuff. The only trouble is, you’ve got a big installed base of current receivers and broadcast equipment out there that don’t support MHP. What can you do?
There are several approaches to this, depending on your current middleware and the limitations of your network. In general, migration scenarios fall into three broad categories:
- No existing middleware deployed. Receivers that are powerful enough to support MHP may be able to receive an updated version of their firmware that includes MHP support. Other receivers will not be able to run MHP applications, but deploying MHP applications will not affect these receivers. This allows new receivers to be deployed while retaining backwards compatibility.
- Declarative middleware deployed. Systems where interactivity is provided using HTML and JavaScript, or other declarative solutions such as MHEG-5 may be able to migrate to MHP by providing an MHP-based method for running the applications. HTML-based systems could use an HTML browser written as an Xlet, for instance. Another approach is to use the MHP 1.1 plugin mechanism (described in more detail in the MHP 1.1. tutorial) to run non-MHP applications. While this approach can theoretically work with most types of application, in practice it is only really suitable for declarative applications because of the processing overhead.
- Other middleware installed (e.g. OpenTV). This is probably the most complex case for migration. The simplest solution is to upgrade all receivers to support MHP via an over-the-air software download, and then broadcast only MHP applications. This type of ‘big bang’ migration is both risky and expensive, and so not many people will take this approach. An incremental migration is more complex, but is generally less likely to cause major problems. There are two possible approaches to an incremental migration, both of which have different advantages and disadvantages.
The first of approach is simulcasting. In this case, all applications are transmitted in both MHP and non-MHP versions. This requires a more bandwidth, although we can limit this by designing our applications share data files. MHP applications can be designed to read data from proprietary stream formats using the MPEG section filtering API, and I have even seen this used to implement support for proprietary broadcast filesystems. When this is combined with MHP’s support for various common iTV data formats and the way MHP builds on existing standards (especially at the lower levels), switching to MHP starts to look less like an insurmountable obstacle. This approach offers a lot of flexibility when it comes to sharing content and assets, but it does mean that the broadcaster must maintain and manage two sets of applications during the changeover period.
The second approach is to upgrade the existing receivers to support both MHP and their current middleware. Most of the major middleware vendors such as OpenTV, Canal+, and NDS offer MHP support for their middleware, usually as an additional module. Receivers can be upgraded with this new functionality using an over-the-air download, and so these receivers can run either MHP or non-MHP applications following the upgrade. The big disadvantage of this approach is the cost: MHP support may cost an additional $5 per receiver or even more, and so this is not a cost-effective solution for migrating all receivers to MHP. It may be cheaper than recalling all of the old receivers and replacing them, however, so there may be cases where this approach makes sense.
Content developers and migration to MHP
Of course, there is a lot more to moving to MHP than this. You have to have content developed, and that means finding content developers – either hiring your own or contracting to an external company. If you are a content development company then this obviously means hiring your own or retraining existing staff. What does MHP mean to content developers?
Since all MHP applications are written in either Java or HTML, there’s a temptation to think that if you can write web applications then you can write MHP applications. This is simply not true. MHP is not the web. There are some major differences between the philosophy of web applications and the philosophy of MHP applications, not least the importance of cooperating nicely with other applications and with the receiver, the importance of bullet-proof reliability and the need to run on many different sets of hardware and software.
In many cases, existing digital TV developers who have a knowledge of Java are probably more suited to MHP development than web developers trying to get into digital TV. Why? Well, at the end of the day, Java and HTML are just languages. Learning them isn’t that complex. Learning what happens when you build an object carousel that is not well-optimized, or learning why your application really should catch all exceptions, check all return values and handle all possible cases takes time – it’s about experience and attitude and domain knowledge. I’m not going to claim that it’s impossible to learn this quickly, but usually it takes time because there’s no fixed set of guidelines that you can apply and so you have to learn from experience.