mheg y java

8/6/2019 mheg y java

1/7

APPLICATIONPROGRAMMINGINTERFACE

EBU Technical Review -Spring 1998 1A. Mornington-West

MHEG-5 and Java the basis for a common European API?

A. Mornington-West

ITVA UK

The use of different proprietary APIs in digital television receivers is leading toa fragmented market in which the consumers are losing out, while the

broadcasters battle to achieve exclusive ownership of a primary gateway to theviewer.

The Author stresses the need for an open universal API and describes how thiscould be achieved using the MHEG-5 content decoder in conjunction with a

Java-based Virtual Machine layer. He also describes a way forward to enable apractical migration from the use of existing proprietary APIs to the use of a sin-gle universal API.

Introduction

The digital television receiver can produce more than just sound and pictures provided thereis some w ay in w hich it can be sent ad ditional instructions. These instructions m ay either bein a form which the receiver can execute, or in the form of content which the receiver canpresent to the viewer (or listener). App lication instructions are written in the language of thespecific application programming interface (API) wh ich is installed in th e receiver.

The use of different proprietary AP I products has flourished in the short lifetime of digital TVbroadcasting (where the AP I has to satisfy somewhat differing requirements to those found in

th e PC environment). This has led to a situation wh ere applications1

that have been devisedfor one group of receivers cannot be executed by another group . It has also prevented thosereceivers associated with a particular service provider from being fully useful when using theservices from a comp eting service provider.

While proprietary APIs have und oubtedly helped the laun ch of digital TV services, they h aveallowed private broadcasters to determine th e features of the receivers wh ich they su bsidise,in order to gain a strong if not monopolistic share of the market for digital television broad-casting. Such a strategy w ill inevitably p rodu ce a fragmented m arket in w hich th e consum er

1. In this article, application is used in the same sense as in the computer environment. It is taken to mean thetotal package of executable content (or instructions) and visual/audible contentwhich together make up the

multimedia programme.Orig

inallanguage:English

Man

uscriptreceived:17/3/98.


2/7



will be the loser as the broadcasters battle to win ownership of a primary gateway to theviewer.

A more beneficial approach would be to use a universal A PI. In this scenario, man ufacturerswould be able to concentrate on developing the market for receivers which implement a rangeof enhanced features for which the consumer would be willing to pay, whilst the broadcastersw ould be able to focus on the d elivery of attractively-priced services wh ich ap pealed to all the

consumers.

Why do we need an API?

The comp osition of software-oriented prod ucts can be viewed in terms of layers. Each layerprovides a suite of functions and provides a service to the layers above and below it. In awell-organized software environment, there should be no reason for processes in any onelayer to bypass another layer in order to carry out a function. The m ost commonly-quoted

mod el is that of the Open Sy stems Int erconn ection (OSI) seven layer model. Although not all soft-ware-oriented p rodu cts can be m app ed on to this mod el, the concept does help u s to visualisethe structure of m any software-oriented prod ucts.

Using this mod el, the AP I in adigital TV receiver provides ap red ict able b uffer lay erbetween the ha rdwa re a ndthe user-oriented executableapplications (Fig. 1).

The hardware drivers for thedecoder chips in receiver areusually provided by the semi-conductor manu facturers, asde ta iled spe cia list knowl-edge is frequently required inthis domain. In some designsth ere is a Virtual Machine(VM) layer w hich can p rovideisolation from the detail ofthe core processor used in thereceiver d esign.

Applications which can be written include the basic man-machine interface (MM I) to thereceiver and its remote control. The EPG is the most common example of an applicationwhich has been written for receivers and it can, in principle, be implemented as a fixed appli-cation, or as an ap plication w hich is provided by or u pd ated by the broadcast signal. Somereceivers have access to a modem and this can be used to provide a return channel for the con-sum er to interact w ith remote sources of information. At the p resent time, the pr incipal use ofthe modem has been in conjunction with the conditional access (CA ) control system whichmany receivers use.

The use of a VM layer offers a way in which the AP I can become independ ent of the h ost proc-essor. The featur es offered by a VM differ from one design to the next. Some d esigns includ e

Fixedapplication

A

Fixedapplication

B

EPGapplication

Downloadedapplication

Downloadeddata

Conventional proprietary API layer

Virtual Machine layer (if present)

Real-time operating system (RTOS) kernel

Hardware drivers

Hardware(e.g. demux

chip)

Hardware(e.g. decoder)

Hardware(e.g. VCRcontrol)

Hardware(e.g. remotecontrol I/F)

Hardware(other silicon)

Figure 1Layered software model of a digital TV receiver employinga proprietary API.


3/7



full checking of the add ress range to w hich an ap plication shou ld h ave access; they w ill reportan error if this boundary is exceeded.

Some diagrams of the OSI model om it the real-time operating system (RTOS), although thisprocess is always required.

The AP I can provide a reliable interface: applications can be written for it without the pro-gramm er having to kn ow precise details of the hardw are design of a particular receiver. As aconsequence, it should be possible to state confidently that an application which executesfaultlessly on one model of receiver should execute as reliably on a different model, providedthat the AP I is the same.

In pr actice there app ear to be tw o reasons wh y ap plication dow nload is often associated w ithth e CA system. The first is simply that it is not u sually in the commercial interests of onebroadcaster to allow a competing broadcaster to have unbounded access to receivers which hemay have subsidised. The second relates to the fear that a rogue application could modify thebehaviour of receivers in an unwanted manner and that this, in turn, could result in dissatis-

fied viewers or expensive service calls.

Both of these reasons need to be ad dressed if an open market for u nsubsidised receivers is tobe established. There should be no requirement w hich d emand s that sp ecific propr ietary fea-tures are imp lemented. Thu s, there should be no need to rely on the u se of a CA system. Anopen AP I could offer the consumer a wider choice of receivers, provided that all servicesw hich could be received w ere interoperable. To assist in th e target of protecting the receiverfrom the effects of a rogue application, a robust and arguably secure VM need s to be sp ecified.

We can d raw a d istinction between t w o classes ofAP I. The first, which we call declarativeAPIs,focus on processing th e content of data for th e consum er. Obvious examp les include HTMLbrowsers, MHEG and even the w orld standard teletext system. They are characterized bytheir emphasis on the decoding and presentation of data content in a uniform and consistent

Abbreviations

ADSL Asynchronous digital subscriber line

API Application programming interface

CA Conditional access

DAVIC Digital Audio-Visual CouncilDVB Digital Video Broadcasting

EPG Electronic programme guide

ESG Event schedule guide

HDTV High-definition television

HTML Hyper-text markup language

I/F Interface

IEC International Electrotechnical Com-mission

IHDN In-home digital networkIPR Intellectual property rights

IRD Integrated receiver/decoder

ISO International Organization forStandardization

JAVA Programming language for theWWW (developed by Sun Microsys-

tems)

LMDS Local multipoint distribution system

MHEG (ISO/IEC) Multi- and Hyper-mediacoding Experts Group

MMDS Multipoint microwave distributionsystem

MMI Man-machine interface

OSI Open systems interconnection

RTOS Real-time operating system

SI Service informationSTB Set-top box

VM Virtual machine


4/7



man ner. One feature of content d ecoders is their robustness, and this reliability is certainlyvaluable if viewers are to be saved the problem of learning where the reset button is located!

The second group comp rises the more conventional procedural A PIs. These AP Is m ake availa-ble to the program mer the full panoply of conventional comp uter language constructs. Oneproblem area here is to ensure that all models of receivers from a wide range of manufacturersimplement the AP I in exactly the same mann er, in order to ensure th at any app lication wh ich

is executed will behave in a predictable m anner. This can lead to the expensive practice ofhaving to forward the receiver to the owner of the AP I for conforman ce testing. It can alsoslow dow n the d evelopm ent of applications.

MHEG-5 content decoder

The origins of the MHEG philosophy started within work initiated by DAVIC. The target wasto create a content decoder which would intrinsically be aware of the principal characteristicsof the digital television system. It wou ld th erefore offer:

aw areness of all digital television systems;

awareness of the pixellations that are available in the DVB bitstream;

awareness of the video and aud io content;

the ability to link textual and graphical data with specifically timed events;

a deterministic method of presenting the text blocks and text flow, using a subset of thesuite ofHTML tags to control the text formatting.

a suite ofMM I tools which could be used to provide the viewer with selection buttons andslider s for actions su ch as level control, char acter entry an d screen na vigation.

MHEG-5 was d eveloped in order to supp ort the d istribution of interactive multimedia ap plica-tions to executing platform s of different typ es and of different br and s. The bulk of the code isdeclarative but there are p rovisions for calling p rocedu ral code as required. N aturally, thereceiver w ill need to have a r un-time interpreter wh ich can p rocess the comm and s as they aredelivered over the air.

DAVIC has produced a suite of specifications which incorporate the MHEG standard. Each ofthem builds on th e previous versions in a comp atible man ner.

DAVIC 1.0 was published in January 1996. It provided a set of tools to supp ort basic

applications such as TV distribution, near-video-on-demand , video-on-demand and sim-ple forms of tele-shopping.

DAVIC 1.1 was produced in September 1996. It ad ded tools to supp ort basic Internetcompatibility, the addition of microwave broadcast networks (MMDS an d LMDS), set-topun its that are network-ind ependent and set-top u nits that can behave as virtual machines.

DAVIC 1.2 wa s released in Decem ber 1996. It includ ed som e tools to enable TV networksto provide Internet services at high speed to television and PC users, and also defined theHDTV formats and systems for conditional access.

DAVIC 1.3 is the current version, dating from September 1997. It has ad ded : comp rehen-sive Service an d Netw ork Management; mu ltiple broad cast servers; mobile reception;scalable audio; content and meta-data packaging; Java AP Is for DVB service information,


5/7



and a new concept ofcontours the first instances are the Enhanced Digital Broadcast con-tour and the Int eractive Digital Broadcast contour.

Work on DAVIC 1.4 contin-ues and a DAVIC 1.5 versionis expected to be released inDecember 1998. Among the

features wh ich are expectedto be add ed in versions 1.4and 1.5 w ill be: the additionof the Java AP I; MHEG5-resi-dent programs to access theDVB Service Information(DVB-SI), and further integra-tion of the DAVIC and Inter-net content. The size of theDAVIC specifications mean sthat use will be made of the

contours concept; featureswill be carefully selectedfrom the full feature set, inorde r to suit the requiredfunctionality of the receiverand the cost of d evelopingthe software.

The combination of the MHEG-5 content decoder and the Java AP I is represented in Fig. 2.

This diagram suggests that the propr ietary AP I layer can be removed and this may be the casefor receivers marketed in some regions. There is obviously scope for both MHEG and Java to

be either resident in the receiver or transmitted over the air (so-called airware). One use of aresident MHEG-5 app lication wou ld be to provide the essential features of an event scheduleguide (ESG). This is a guide wh ich is based on the u se of pu blished DVB-SI data tables.

MHEG is an object-oriented environm ent in w hich successive scenes can be joined together t oconstruct the overall application. Objects in a scene may includ e graph ics, sound or video, aswell as the ability to respond to local actions such as key presses. MHEG does not specifyexactly wh at form a rem ote control or other inpu t d evice should take; it simply sp ecifies thefunctions which shall be provided, irrespective of the approach taken.

Only one application may be active at any one time although the ingredients w hich are referredto in a scene will be available to other active scenes. The ingredients includ e:

links;

procedures;

palette;

font;

variable.

The ingred ients are fairly self-explanatory; for exam ple, a linkprovides a facility for handlingthe choices which a viewer might make, while variable indicates some storage space th at canbe used to pass values to and from procedures and other MHEG objects. These objects aregrouped into classes and an imp ortant one is the visible class. It implements th e presentationof displayable objects such as line art, vid eo, text, sliders and but tons on a screen.

Fixedapplication

A

Fixedapplication

B

EPGapplication


Downloadeddata

Personal Java + broadcast extensions


Hardware drivers

Hardware(e.g. demux

chip)





MHEG content decoder Java STB

Figure 2A layered model of a digital television receiver with DAVIC 1.5components.


6/7



The route to migration

The inclusion of the Java VM into the specification is significant. It provides digital TV receiversw ith two key benefits. The first is a d efinition of a processing engine which, as far as any applicationneed be aware, can be independ ent of the actual hard ware processor which has been chosen by theman ufacturer, i.e. receivers from different manu facturers shou ld p erform in the sam e w ay. The

second benefit provides reliability, because the VM has been defined in order to protect applicationsfrom interfering with each oth er or w ith the background operating system p rocesses.

The DAVIC standard s set out to use existing pu blic stand ards w here possible. A pu blic stand-ard is not necessarily free of the costs of paying for any associated intellectual property rights(IPRs). DAVIC includes such standards as required, provided that any IPR is agreed to bemad e available on fair and non-discriminatory terms. The Author believes that the currentstatus ofMHEG-5 is such that there are no IPR fees which need to be p aid and this is part of itsattraction to digital television receiver manufacturers (the licence royalties for proprietaryAP Is can be significant). Of course, the other attraction is that a single AP I means that thedevelopment work can be amortised over a much larger market and this too will help toreduce the costs.

Interoperability of digital STBs has been elusive sufficient at least to p revent an y service opera -tor from having the confidence to place orders for an integrated receiver/ decoder (IRD). Itseems likely that the next major growth phase in the market for digital television requires theimplementation of standards such that the consumer can rely on true interoperability, not onlyof the primary video and aud io signals but also of all the furth er signal comp onents wh ich m aybe present. The most heralded of these are the signals for d ata services, as these provide d igitalreceivers w ith t heir full scope for interactivity.

Expansion of this m arket, andof the whole gamut of prod-

ucts which could be producedfor the in-home digital net-work (IHDN ) environment, isunlikely to take place untilthere is a u niform AP I. This isp erhap s the last step toremoving all the individualproprietary technologies thata re fou n d w ith in t od aysreceivers. These technologiesresult in design implementa-

tions which do not enable fullinteroperability, even withinthe same country!

Fig. 3 shows one of the manyscenarios in wh ich current pro-prietary APIs may still be usedwithin receivers in the futu re. One u se for the legacy AP I wou ld be to provide an interpreter forthe MHEG content. This may provide a slower p erformance but it m ay still provide a reliableproduct which can be delivered relatively quickly to the marketplace.

Some legacy applications could be supported for the full lifetime of the STB and this mayinvolve the service providers in sending application content for both the legacy receivers and

Fixedapplication

A

Fixedapplication

B

EPGapplication


Downloadeddata

Personal Java + broadcast extensions

MHEG content decoder


Hardware drivers

Hardware(e.g. demux

chip)





Java STBLegacyproprietary

API

Figure 3An intermediate state in which a legacy proprietary API may co-exist with MHEG-5 and Java.


7/7



the new receivers for a nu mber of years. This w ould only be feasible where the cost of suchdou ble illum ination w ith airware w as cost-effective.

These concerns have formed the background for the work of the DVB multimedia home plat-form (DVB-MHP) group [1]. The key requirement is to chart a m igration p ath so that receiverswhich are due to be introduced to the market and perhaps those which may already be on themarket can be ad apted to conform to an agreed un iform API.

At the p resent time th is work is still in p rogress although it should be n oted that the emp hasisnow is on a solution based on MHEG with a Java VM. This approach is strongly sup ported bya number of receiver manufacturers and by many broadcasters particularly those planningto intr odu ce terrestrial digital television services.

Bibliography

[1] J.-P. Evain: Multimedia Home Platform an overviewEBU Technical Review, No. 275, Spring 1998.

Allen Mornington-Westgraduated from Durham Universityin north-east England many years ago and spent his formative years designing audio mixing desks, audio effects units andaudio power amplifiers for a number of manufacturers. Aperiod of some 8 years was spent at the Independent Broad-casting Association, working in the areas of quality controland measurement practice within the independent television

companies.

More recently Mr Mornington-West held the post of Engineer-ing Director, Quad Electroacoustics, until the challenge aroseto assist the Independent Television Association to enter thedigital television era.

Allen Mornington-West is a Chartered Engineer, an MIEE and aFellow of the Institute of Acoustics. He has been active instandards work, including assisting the professional audio and

video product-family EMC standards, and the AES 24 communication standard. He is currentlyworking in various ITU-R, EBU, DVB, DigiTAG and UK DTG working groups, some of which he

chairs. He is a regular presenter of papers at UK and European conferences and he frequentlylectures and writes articles.
http://trev_275-evain.pdf/http://trev_275-evain.pdf/http://trev_275-evain.pdf/http://trev_275-evain.pdf/

Documents

mheg y java