These are some of the more common questions that appear in my inbox, or in the JavaTV and MHP forums.
The various open standards can be used in almost every interactive TV system, within reason. There are some obvious restrictions that apply, however:
This means that the type of network you're running on will affect your choice of middleware. However, the three standards have enough similarities that choosing one over the other may not be a big deal: South Korea, for instance, uses all three middleware standards on different types of network.
Of course, there are proprietary middleware systems out there as well, and it may well make business sense to choose one of those instead. The availability of open standards for iTV doesn't mean that proprietary solutions are going to go away.
If the current crop of open standards are not designed for your network (e.g. an IP-based network) then you may want to consider using another middleware solution. Specifying all the details needed may take too long and be too high-risk. Similarly, don't choose MHP or OCAP if you're not planning on deploying interactive applications. Adding middleware for the sake of it is not a sensible move.
Finally, you may not want to deploy one of these middleware standards when you have a large number of low-end receivers already deployed. The Motorola DCT2500 receiver, for instance, will not run MHP or OCAP, and so JSR 242 ('On Ramp to OCAP') may be a better choice. This may be a slightly risky approach, though, because the danger is that you'll move to a partial solution but then fail to move all the way to MHP or OCAP. JSR 242 is designed as an interim solution, but we all know that interim solutions have a nasty habit of becoming permanent.
JavaTV is a set of APIs for building digital TV applications, and so it can only be used with digital TV signals that include JavaTV applications. It's not designed to be used with an analog TV tuner, and so the answer is probably 'no'. It may be possible to build a JavaTV implementation that works with a TV tuner card that supports digital TV services, but to date no company provides a JavaTV implementation with such a card .
The simplest way to do this at the moment is to use an MHEG engine written in Java. Strategy & Technology sell an MHEG engine that can run as as MHP application, and so this allows an MHP receiver to run legacy MHEG applications.
It is possible for a receiver to run native MHEG and MHP middleware stacks simultaneously, but the complexity of this approach is much higher and I've yet to see a good justification for doing it.
OpenTV and MediaHighway middleware both have support for MHP available as optional modules, as does the NDS Core middleware. This is the easiest migration path, although licensing costs may be significant.
PCF isn't complete yet, and so there is no formal specification available for it. It will use XML as the basic file format. The specification will offer a super-set of features available on any individual platform. True content portability will require content creators to know the capabilities of the platforms they are targetting and to limit themselves accordingly. DVB will define some profiles of PCF to give structure to this.
There are several options that you could look at:
Each of these tools have their own limitations, and as far as I know none of them are complete. They will each support a different subset of the MHP specification, and so which if these is most valuable to you will depend on what you're doing.
This is not necessarily a complete list, and if you have any more information about companies selling developer STBs please let us know.
Many electronics retailers in countries that have deployed MHP will be able to sell you a normal STB. Right now, German retailers are probably the most likely to support on-line ordering for international customers.
Retail MHP boxes may not be suitable for software development, and so you should make sure that a receiver will do what you need.
Osmosys and Zentek both have PC-based solutions for MHP. The free implementations we mentioned above will also run on a PC, but many of them are not complete MHP or OCAP implementations.
Not really. I do most of my MHP development using a text editor and javac, which seems to be a fairly common approach among developers. The tools may be useful, but they are not essential.
Some of the tools are aimed at building specific types of applications based around predefined templates, and you may find a given tool too limiting if you want to do something out of the scope of those templates. The best advice I can offer is to try a number of the tools and see which one works for you.
Up to now, there has been no freely-available file containing the stub classes for MHP that developers can compile against. Licensing restrictions from Sun have prevented this, and other companies aren't willing to give this away. Luckily, for you, we will soon have a set of stub classes that we have placed in the public domain. These do not include any intellectual property from other companies, and so they are free to use for whatever purposes you see fit.
These are only stub classes, however, and so you can't use them to run you MHP application. For that, you need an emulator such as XleTView or a real MHP receiver.
There has been no formal specification about how MHP should work with DVB-IP, MPEG-4 or other transport or video formats. This doesn't mean it can't be used, just that different systems are unlikely to be interoperable. A telco may choose to use MHP for interactivity of IP-based DTV networks, but they had better make sure that they specify everything that needs specifying.
MPEG-4 defines the MPEGlet concept for using Java applications - this is not MHP, and network operators and developers nee dot be aware of this. The basic lifecycle is similar, but there are a lot of differences as well.
GEM defines some mechanisms where MHP can work with non-DVB or non-MPEG systems, but this still leaves a lot to be specified.
GEM is a subset of MHP that removes any of the DVB-specific elements. This allows it to be used as the basis of other interactive TV standards such as OCAP, ACAP, or ARIB B.23. There are two main parts to GEM: the list of components from MHP that are part of GEM, and a mechanism for replacing or extending GEM components in order to meet the needs of a particular market. These replacements could be made for technical reasons (e.g. the use of DSM-C data carousels in ARIB B.23 instead of object carousels) or they could be make for business reasons, such as replacing the MHP navigator with the OCAP monitor application.
Yes, but you may need to define some extra details that are not covered by GEM or JavaTV. In particular, JavaTV doesn't define many details about the type of broadcast filesystem that should be used, or how the receiver knows that an application is available to be started. These elements, and others, need to be specified either by the implementer or as part of a standard that uses JavaTV.
Yes, if the receiver supports it. MHP only requires the locale for Western Europe, but other locales may optionally be added. The same applies to fonts, and if a font is not build in to the receiver then it could always be downloaded as part of the application.
Like every other Java system, MHP uses UTF-8 for string representation, and so there should be no major problems. MHP systems have already been deployed in Korea and parts of China, and several other Asian countries are considering MHP.
Typically there isn't one, although they do share a very similar lifecycle. The differences between Xlets and other types of -let are too complex to go into here, but the biggest difference is that each of them have different APIs available and are aimed at different purposes.
It may be possible to build an application that is both an Xlet and an applet (or an MPEGLet), but it's not easy and generally there aren't many good reasons for doing so.
No. That's what video elementary streams are for. Including a video file in the object carousel would cause big problems for caching and for loading other files. If you used enough bandwidth for the carousel to avoid these problems, then you may as well broadcast the video as an elementary stream. Even if object carousel performance wasn't a problem, the receiver may still not have enough free memory to hold all of the video.
You can fake animation using a dripfeed data source, but this may not be very smooth or very fast and it's really only suitable for very short clips. The format of an MPEG file used for video drips must comply with the file format specified in section 7.1.3 of the MHP specification. Anything that does not meet this will probably not work, especially if it's just some random piece of MPEG. Long clips will probably run into problems because they may use B frames, which are not supported for video drips.
If you're testing from inside your company's network, then it's most likely that you're running in to problems with a firewall or other access control software. Testing tools on an MHP receiver are pretty basic, so check the obvious things first.
It's theoretically possible for receivers that have a broadband return channel, but not easy. There is no way that the server can guarantee that an application will be listening for connections. Generally, there isn't much need for a server to do this, but if you have a specific example where you think it is necessary then I'd like to hear more.
You can't. There is no way for an application to get a unique ID for a specific set-top box because of possible privacy issues. Some receivers may define a proprietary API for doing this, but this is obviously not interoperable.
MHP and OCAP make no guarantees about how long a file will remain in persistent storage. It may stay there for years, it may get deleted within a few minutes, or anything in between. The main reason for this is to give the receiver a way of managing storage, so that one application can't use all of the space in the persistent storage and prevent other applications from storing anything..
For this reason, applications can't assume that a file they stored in persistent storage will still be there. Some receivers are known to delete files in persistent storage when the power is cycled, and so it's best not to rely on persistent files for storing personal information or information about customizing an application.
Typically, stored applications will stay in the receiver for a little longer than other persistent files. At the same time, they may be removed automatically after a certain amount of time or if the application storage area is full. Again, network operators should not assume that a stored application will remain stored.
An MHP or OCAP implementation may include an XML parser, but applications will not have access to it. Any application that wants to parse an XML file must do it itself, either by writing your own parser or by using an open-source parser such as NanoXML.
MHP 1.1 includes support for access to non-CA smart cards via the embedded version of the Open Card Framework. However, this will be replaced in future versions of MHP 1.1.x with a subset of the Security and Trust Services API from JSR 177.
MHP 1.0.x does not include an API for communicating with smart cards, but some bodies such as the DGTVi in Italy do specify that MHP receivers in those markets should include smart card support. Italy has specified that receivers should support the same subset of JSR 177 that will be adopted in MHP 1.1.x, and it's likely that other markets that need smart card access will follow suit. Again, this API is for use with non-CA smart cards only. The
org.dvb.net.ca packages provide access to the smart cards in the CA system.
Just like you would use any other classes. There are no special requirements for using other components, although you will obviously need to check the licenses that apply to those components and you'll need to make sure that the application can load them. The easiest way of doing this is to make them part of your application and include them below your application's root directory, but this may not be the best approach if you want to share them with other applications
You should not use any components that are not part of the MHP/OCAP specification unless they are broadcast as part of your application or in a carousel that you can use. A component may be present on one platform, but that's no guarantee that it will be there on other platforms.
There are three options for doing this:
DVBClassLoader. This may reduce carousel sizes and make applications quicker to load, at the expense of some extra complexity in the application. This approach does allow you to load files from a carousel in another transport stream, provided you tune to that transport stream first.
It's possible to combine the second and third approaches, depending on how your applications are organized and which components you want to share.
With great difficulty. MHP supports a limited number of content formats because those are the ones that receivers typically support and adding a whole load of optional formats is next to useless because you can't guarantee that they will ever be supported.
For some graphics formats, it's possible to decode them in Java and display them. For audio and video formats this is extremely hard, and so we suggest that you don't even try. By using the standard formats, you are avoiding any possible performance problems caused by slow decoding of the content, and you're generally making life easier for yourself.
Both MHP 1.1 and OCAP 2.0 include support for HTML applications. Unfortunately neither of these are deployed at the moment, and the versions of HTML that is defined by these standards will probably undergo some fairly major changes in the near future to harmonize with ACAP.
For MHP 1.0.x and OCAP 1.0 systems, supporting HTML involves downloading a microbrowser to the receiver as a normal interactive application. This approach is used in Finland and Germany for Teletext services, and it seems to be pretty successful. Most of the browsers in use support XHTML and CSS 2.0, so they offer a pretty good solution for companies that want HTML.
OCAP-HTML is basically DVB-HTML with a different name.
Many people are claiming to support DVB-HTML or a subset of it, but this subset may not be very different from normal XHTML and CSS. If you're looking at using DVB-HTML, make sure the browser that you choose supports the features that you need. Most users of HTML today in MHP are mostly sticking with standard XHTML rather than using the DVB-HTML extensions. Doing this means fewer changes when DVB finally gets round to updating the DVB-HTML chapter in MHP 1.1.
I'm a guy who's been working with MHP since the very early days and who enjoys working with digital TV. There are a few more details on my personal pages.
Partly because it's a way of giving something back to the industry, and partly because the more people who are using MHP, the easier it is for me to find work. Mostly, though, this whole site is one giant advertisement for my skills. If you think that your company has an interesting job available for an MHP/OCAP/JavaTV expert, please let me know.
This is not my day job. Sometimes, I will be too busy at my normal job to reply to email or update the site for a while. I will try to reply to every email that I receive, so please be patient. Repeatedly mailing me to ask why I haven't replied to your email is more likely to annoy me than to make me respond to your question.
Not without paying me. All of the material on this site is copyrighted, and must not be reproduced without my permission. If you want to do this, please email me and we can reach an agreement. By the way, I do look at my website logs, and I do know who is downloading copies of the entire website.
Possibly. If you are looking at buying in bulk, please email me and I can put you in contact with someone at the publisher to discuss bulk rates.
Any source code is in the public domain. All I ask is that you let me know if you find any bugs in it.
I'm happy to answer questions, but please don't expect me to do your homework for you. This applies to everyone equally, but students need to be especially careful. If you found this site, it probably means that your tutors and lecturers know about it as well :)
The answers you get may be more or less detailed, depending on how busy I am and what other sources of information are out there on the subject in question. If your question is answered in the MHP or OCAP spec, then you'll probably just get a link to the appropriate document.
There isn't one. This website is not affiliated with any standards body or company. I have a personal relationship with some of the folks who are working on the standards, but I do not speak for them and have no special knowledge about what's going on in the standardization process. I only have access to the publicly-available information that is released by standards groups and companies working with DTV.
I work full-time for another company, which means that my time to work on MHP/OCAP is limited. I may be able to provide some consultancy services, but this depends on a number of factors. If you are interested, please email me.
The best way is to buy a copy of the book. The money from that will help to keep the site going. If you want to donate money more directly, please let me know.
Job offers are always welcome, but depending on the timing and the exact position, I may not be able to take you up on it. it's worth asking, though.
We're happy to publish additional example code, but we do have a few guidelines for any code that is submitted:
We may add extra items to this list in the future if we think they're necessary.
If you have an article that you think would be useful for the digital TV community and that would be suitable for inclusion on the site, please contact email@example.com to discuss submission. As for example code, we have a few guidelines for submitted articles:
Again, this is not necessarily a complete list and more items may be added at any time.
None of the contents of this site may be translated. The pain of checking translations for correctness and factual accuracy is simply too high for us to cope with.
First, thanks for asking. We're usually happy to grant permission for using quotes or images from the site in other articles, but please check with us first. It's important that you identify exactly which images or text you would like to use, so that we can make sure we are the copyright holder and that we grant you rights to use the correct content.
Please note that you are not allowed to reproduce the entire site or entire articles.
Please email a short description of your company and your website URL to firstname.lastname@example.org.
Again, please email the press release/news story and a URL for the story to email@example.com. The full text isn't so important as long as you include a URL, but it's useful.