APPLICATION PROGRAMMING INTERFACE The Multimedia Home Platform – an overview J.-P. Evain EBU Technical Department The Multimedia Home Platform (MHP) encompasses the peripherals and the inter- connection of multimedia equipment via the in-home digital network. The MHP solu- tion covers the whole set of technologies that are necessary to implement digital inter- active multimedia in the home – including protocols, common API languages, interfaces and recommendations. This article offers an introduction to the design and harmonization of MHP receivers, starting with a reference model which has been derived from the DVB and UNITEL reference models. Introduction ➩ A commercially-oriented group, compatibility in a multi-CA environ- DVB-MHP, to define the user and ment. At the beginning of 1996, the UNITEL – market requirements for enhanced universal set-top box project was and interactive broadcasting in the launched by the ISIS Programme of the local cluster (including Internet access). Reference model European Commission. The main aim of this project was to raise awareness of ➩ A technical group, DVB-TAM Different reference models have been the benefits of developing a common (Technical issues Associated with defined for each MHP system currently platform for user-transparent access to MHP), to work on the specification in use. UNITEL used object-modelling the widest range of multimedia serv- of the DVB Application Program- tools to define the application classes ices. Promising progress has since ming Interface (API). and functionalities that would ulti- been achieved towards the harmoniza- mately identify the hardware and soft- tion of what is now widely called the DVB-TAM is currently considering ware resources required by an MHP Multimedia Home Platform (MHP). several API candidates: system. With this system, users would ➩ MHEG-5/Java; be able to access: The MHP Launching Group was born from the UNITEL initiative in order to ➩ Mediahighway +; ➩ enhanced broadcasting services; open the project to external parties via ➩ JavaTV; ➩ interactive broadcasting services; joint meetings. Key representatives of the High Level Strategy Group took ➩ HTML/Java. ➩ Internet services. part in this group, and this collabora- tion eventually led to the transfer of The API chosen by DVB will have to be Fig. 1 shows just a part of the UNITEL these activities to the DVB Project. Two open, in order to suit the requirements reference model which was submitted DVB working groups were subse- of a horizontal market. It will have to to the DVB-TAM ad-hoc group that is quently set up: be CA-independent but will support working on the system modelling. Original language: English English language: Original 29/5/98. received: Manuscript 4 EBU Technical Review - Spring 1998 J.-P. Evain APPLICATION PROGRAMMING INTERFACE DVB-TAM succeeded in defining a The reference model shown in Fig. 3 – both in terms of hardware and soft- common generic reference model, allows the development of high-level ware. Backward compatibility will be which is shown in Fig. 2. The reference APIs and applications, independent of supported to the largest possible extent, model shown in Fig. 3 is a combination the MHP system infrastructure. e.g. by using scalable applications. of the models shown in Figs. 1 and 2. This model offers system modularity Each application that is developed will through the use of key interfaces. These need to comply sufficienly with the ref- Abbreviations interfaces will be able to maintain the erence model to ensure cross-platform stability of MHP systems as they evolve interoperability in a competitive envi- API Application program- ming interface A/V Audio / video (visual) CA Conditional access CCETT (France Telecom's) Cen- tre Commun d'Etudes de Télédiffusion et de Télécommunications CPU Central processing unit DAVIC Digital Audio-Visual Council DRAM Dynamic random access memory DSM-CC (ISO) Digital storage media - command control DSM-CC UU (DSM-CC, user-to-user DVB Digital Video Broad- casting DVB-SI DVB - Service Informa- tion EEPROM Electrically-erasable programmable read-only memory I/O Input/output ISO International Organiz- Basic OS ation for Standardiz- layer ation (Windows NT, Windows 95, JAVA Programming language Mac, OS9) for the WWW (devel- oped by Sun Micro- systems) Figure 1 UNITEL: MHP hardware and software resources MHEG (ISO/IEC) Multi- and Hyper-media coding Experts Group MHP Multimedia home plat- form mips Million instructions per second MPEG (ISO) Moving Picture Experts Group NIU Network interface unit ROM Read-only memory RTE Run-time engine TAM (DVB) Technical issues Figure 2 Associated with MHP DVB-TAM reference model: system layers. EBU Technical Review - Spring 1998 5 J.-P. Evain APPLICATION PROGRAMMING INTERFACE Figure 3 Reference model: a possible API and middleware for pipes and streams. ronment. This should result in host ➩ security and access; Applications platforms where the integrity of the ➩ content loading; application is protected, and its behav- ➩ The predictable environment described iour is stable and predictable (thus navigation and selection; by the reference model will readily resulting in a high quality of service). ➩ declarative content and streams allow applications to be authored and The reference model must also define presentation control; tested. Compliance with the reference modes for data delivery, memory han- model will ensure that applications ➩ communication and I/O control; dling, object handling and instruction execute properly, independent of the execution. ➩ signalling, bit transport, driver and precise MHP implementation. The management functions. integrity of the look, feel and function- The reference model consists of five layers: ➩ application (content, script) and media (audio, video, subtitle) com- ponents; ➩ pipes and streams (see Fig. 4); ➩ the API and native navigation/ selection functions; ➩ platform/system software or mid- dleware, including the interactive engine, the run-time engine (RTE) or virtual machine, the application manager, etc.; ➩ hardware and software resources, and associated software. The main system functions are: ➩ application launch and control, ses- Figure 4 sion/event management; Reference model: application “pipes” and MPEG streams. 6 EBU Technical Review - Spring 1998 J.-P. Evain APPLICATION PROGRAMMING INTERFACE alities of each application will have to us to define a platform-independent been adopted by DVB. DSM-CC UU is be ensured; the design of the original reference model which can verify the interface that allows us to extract application provider must be pre- whether such applications comply in DSM-CC carousel objects from the served – irrespective of the platform terms of cross-platform compatibility broadcast stream, or via an interactive implementation. It should be possible and performance accuracy. access to a remote server. to design scalable applications that maintain compatibility across a range In reality, applications are neither fully DSM-CC carousel objects allow one or of receiver implementations. declarative nor fully procedural. As an more application objects to be carried example, declarative applications can in one module of the data carousel. DVB-TAM defines an application as a make use of procedural enhancements Objects can be arranged in modules, in functional implementation of an inter- to improve their performance. This order to optimize the performance and active service which is realized as soft- allows us to reduce the size of the appli- use of memory. DSM-CC also includes ware modules. An application can also cation and to reduce its execution time compression tools to format the appli- be seen as a set of organized functions by using routines written in executable cation objects and carousel modules, that request activation of MHP hard- code. Platform-independence is en- and mechanisms to ensure the secure ware and software resources (see Fig. 5). sured by relying on embedded RTEs, downloading of the carousel objects. virtual machines or other interactive An interactive application is basically engines. It is more difficult to achieve built around: compliance of the compiled code rou- Definition of the API ➩ tine libraries for different platforms, if application script (which can be they are not taken into account at the declarative and/or procedural) DVB-TAM has defined an API as a set time of the platform design. of high-level functions, data structures ➩ content/scenes (declarative interface and protocols which represent a stand- and media streams). Applications are identified and sig- ard interface for platform-independent nalled to indicate their availability, and application software. It uses object- The declarative interface is the repre- an appropriate mode of access is pre- oriented languages and it enhances the sentation of the man-machine inter- sented to the user. Applications are flexibility and re-usability of the plat- face. It can consist of graphics such as launched automatically or by request. form functionalities. a background design, selection but- The application presentation can be tons, still pictures, text etc. Each scene nominal or down-sized (if scalable), An application describes a set of can comprise a set of other scenes, thus maximizing the use of the availa- objects according to the definition of application objects and attributes. The ble resources. Application manage- high-level APIs. It defines the interface pipes implement the interconnections ment encompasses: interruptions, (via the interactive